C++ Exception Handler problem

I written an exception handler routine that helps us catch problems with our software. I use

SetUnhandledExceptionFilter();

to catch any uncaught exceptions, and it works very well.

However my handler pop's up a dialog asking the user to detail what they were doing at the time of the crash. This is where the problem comes, because the dialog is in the same thread context as the crash, the dialog continues to pump the messages of application. This causes me a problem, as one of our crashes is in a WM_TIMER, which goes off every minute. As you can imagine if the dialog has been on the screen for over a minute, a WM_TIMER is dispatched and the app re-crashes. Re-entering the exception handler under this situation is bad news.

If I let Windows handle the crash, Windows displays a dialog that appears开发者_Python百科 to function, but stops the messages propagating to the rest of the application, hence the WM_TIMER does not get re-issued.

Does anyone know how I can achieve the same effect?

Thanks Rich

---

Perhaps you could launch a separate data collection process using CreateProcess() when you detect an unhandled exception. This separate process would prompt the user to enter information about what they were just doing, while your main application can continue to crash and terminate.

Alternatively, if you don't want to start another process, you could perhaps create another thread with a separate message queue, that blocks your main thread from doing anything at all while the dialog is on the screen. While your main thread is blocked it won't have the opportunity to handle WM_TIMER messages.

---

Show the dialog in a second thread. I had more or less the same problem (but had to show a message box rather than a dialog).

• Write a class in which you create two events using the Win32 CreateEvent function. One event (trigger) is used to trigger the dialog, one event (ready) is to signal that the dialog was handled.
• Add a method 'execute' to the class and start this method in a second thread
• Let the 'execute' method wait until the trigger event is set, and if it is set show the dialog
• After the dialog has been handled, set the 'ready' event.
• If your application crashes in the main thread, prepare some information for the dialog (via setters in the class) and set the 'trigger' event, then wait for the 'ready' event. The set'ting of the trigger event will activate the second thread, and the main thread will block until the second thread has set the 'ready' event