StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

POSetUnhandledExceptionFilter and default exception handler when crash report dialog is disabled
text
Body
copied!<p>I have a situation where an application which uses SetUnhandledExceptionFilter (via <a href="http://code.google.com/p/google-breakpad/" rel="nofollow">google breakpad</a> ) to set up a custom exception handler is hanging after the breakpad exception handler has caught a crash, saved a minidump file and returned EXCEPTION_EXECUTE_HANDLER from the SetUnhandledExceptionFilter function, to execute the standard exception handler. The hang also happens if the filter function returns EXCEPTION_CONTINUE_SEARCH and the Windows Error Report dialog has been disabled via SetErrorMode(). If SetErrorMode() is not used to disable WER, the process closes once the user clicks the 'Close' button in the WER dialog.</p> <p>The hang happens under Windows XP but not Windows 7.</p> <p>The documentation for <a href="http://msdn.microsoft.com/en-us/library/windows/desktop/ms680634%28v=vs.85%29.aspx" rel="nofollow">SetUnhandledExceptionFilter</a> states that when 'EXECEPTION_EXECUTE_HANDLER' is returned, the associated exception handler will execute which "usually results in process termination," but I couldn't find documentation of the termination method used.</p> <p>A stack trace shows that the hang is occurring in a global destructor for an object in a 3rd party DLL, called from the DllMain() prelude.</p> <pre><code>ntdll.dll!_KiFastSystemCallRet@0() ntdll.dll!_NtWaitForSingleObject@12() + 0xc bytes kernel32.dll!_WaitForSingleObjectEx@12() + 0x8b bytes kernel32.dll!_WaitForSingleObject@8() + 0x12 bytes QtCore4.dll!QWaitCondition::wait(QMutex * mutex=0x03ad1b00, unsigned long time=4294967295) Line 175 + 0x15 bytes C++ QtCore4.dll!QThreadPoolPrivate::waitForDone() Line 295 + 0x10 bytes C++ QtCore4.dll!QThreadPool::~QThreadPool() Line 429 C++ QtCore4.dll!QThreadPool::`vector deleting destructor'() + 0x3d bytes C++ QtCore4.dll!`theInstance'::`8'::`dynamic atexit destructor for 'cleanup''() + 0x14 bytes C++ QtCore4.dll!_CRT_INIT(void * hDllHandle=0x02b2b2d0, unsigned long dwReason=45265416, void * lpreserved=0x02b2b208) Line 446 C QtCore4.dll!__DllMainCRTStartup(void * hDllHandle=0x67000000, unsigned long dwReason=0, void * lpreserved=0x00000000) Line 557 + 0x8 bytes C QtCore4.dll!_DllMainCRTStartup(void * hDllHandle=0x67000000, unsigned long dwReason=0, void * lpreserved=0x00000001) Line 507 + 0xe bytes C ntdll.dll!_LdrpCallInitRoutine@16() + 0x14 bytes ntdll.dll!_LdrShutdownProcess@0() - 0xfe bytes kernel32.dll!__ExitProcess@4() + 0x42 bytes kernel32.dll!7c81cb0e() kernel32.dll!_BaseThreadStart@8() + 0x2f479 bytes </code></pre> <p>I guess that the mutex was locked by a thread that has since been killed, but I can imagine other kinds of global ctors/dtors that might be executed in this way that would cause a similar problem. My questions are:</p> <ul> <li>Is it expected behavior that <code>ExitProcess()</code> is called in the event of a crash if WER is disabled via <code>SetErrorMode()</code>?</li> <li>Does anyone know of a change in behavior of the default exception handlers between Windows XP and Windows 7 which might be relevant?</li> <li>If <code>ExitProcess()</code> is expected behavior, what is the safest way to deal with this problem in third-party DLLs? Calling <code>TerminateProcess()</code> from the breakpad exception handler fixes the problem but are there any caveats I should be aware of?</li> </ul>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload