CTRL_BREAK_EVENT kills my program

[arbor324]

I am fairly new in writing windows programs, and seem to be encountering some problems which I can certainly use some help solving. For those of you who can help, thank you in advance.

Coming from unix/linux programming background, I use signals heavily as a means of interprocess communication.

I have a multithreaded windows application, which has some instrumentation to track a bug. The instrumentation gathers data for a long period of time, and upon an external request sorts and dumps the data to a prespecified file. The issue is with this external request.

When I ran a similar debugging method on Linux, I was able to send a SIGUSR2 signal, which is caught, for which the handler generates the requested report (and my application continues to run).

For similar results, I use the following code segment, in windows.

static Bool
CtrlHandler(DWORD fdwCtrlType)
{
switch (fdwCtrlType)
{
case CTRL_BREAK_EVENT:
GenerateAndPrintReport();
return TRUE;
default:
return FALSE;
}
}

Whenever I generate the Ctrl+Break event, I can see GenerateAndPrintReport being called (it prints a few statements), but always exits prematurely. The work of GenerateAndPrintReport() could take a minute (or even more). I wonder whether that has anything to do with it. Nevertheless, the application is killed in no more than 2 seconds after the ctrl+break is pressed.

Now Questions:

1. Is this related to the time it takes to run GenerateAndPrintReport(). If so, what is the default wait time of CTRL_BREAK_EVENT to complete, and is there a way of changing this wait time.

2. If I was to create a new thread to run GenerateAndPrintReport(), would that solve the problem. What if creation of the new thread takes longer than the default wait time.

Thanks,

 

[ArkM]

Ctrl-brk/Ctrl-C signals handling is slightly more complicated in Windows. You must use SetConsoleCtrlHandler to intercept all break events (not only CTRL_BREAK_EVENT).
Search MSDN with CTRL_BREAK_EVENTm for example. There are articles and example codes on your case in MSDN.
Don't depend upon any timing intervals etc.

 

[arbor324]

Thanks for the reply. It is true that "CtrlHandler" does not handle every event explicitly, though, doesn't returning FALSE from the "default:" label of the case statement essentially means that the default handler should be called, for anything not listed.

Just to be safe, I did try your suggestion as well.

Also I tried to just set a global variable to some value. In other words, instead of calling GenerateAndPrintReport(), I just had

case CTRL_BREAK_EVENT:
globalTestInt = -1;
return TRUE;

with exactly the same result. As it is easily seen, this does not depend on any timing at all.

Thanks again.