Prevent Modal Dialog on win32 process crash

Question

We have a legacy build infrastructure for nightly builds (implemented in Perl) to compile, link and unit tests our applications/plugins. On Windows, if the unit testing process crashes, this pops up a Modal Dialog which "locks" our build farm.

Is there a way (win32 API call, system config, env var, something...) to disable this behavior to have the child process terminate immediately on crashes, with no Modal Dialog and a non-zero exit status instead?

Thanks, --DD

PS: We compile with SEC (Structured Exception Handling) on Windows, to be able to "catch" crashes using catch (...), therefore avoiding this issue most of the time, but sometime that's not enough, since of course some crashes are not recoverable (if they corrupted the stack for example).

Answer 1

1. Do not use the "catch(...)" statement because then you can miss the point of having unit tests.
2. What you need is a non-modal dialog, since the modal dialogs are for blocking the user from any further actions and the program execution (in your case the unit test runs) hangs up until the user makes his/her choice. Now the crash dialogs can't be avoided, but you need to see how your unit test framework handles these situations. I would say you missed something around the unit testing framework because if I have a crash in my applications I got just a log message about that from the Boost.Test stubs.

If you run your unit tests as a child process it shouldn't block your build bot, BUT: if a unit test case fails, you shouldn't continue the building process in my opinion.

Answer 2

Hi,

You can use WSH to "script" your windows.

With it you can "simulate" that somebody clicked on the "Accept" button of the modal window, or send the ESC key to close that.

Regards.

Answer 3

You need to add an 'unhandled exception handler' that catches all exceptions: put a call to SetUnhandledExceptionFilter(handler) in your initialisation code and it'll call the handler routine. Really simple.

I use sample code from an old article, include a file called minidumper, call the exposed function, and you're done.

Here's some more example code, this pops a different dialog, but you can change that to simply write a message to a log file or similar.

If you're writing a pure .NET app, then you'll be more interested in this article.

Answer 4

Depending on who's throwing the dialog, you may have to combine multiple approaches.

    SetErrorMode(SEM_FAILCRITICALERRORS);
    SetErrorMode(SEM_NOGPFAULTERRORBOX);

...will shut up one set of dialogs.

Answer 5

I still use an old program called RTVReco. It's just a button pushing app, and very easy to use. It hasn't been updated in a while, but it's still the easiest one I've seen.