Why a process vanishes
Sometimes processes vanish without putting up the unhandled exception dialog first. Here are a few of the reasons why this can happen.
- Bad exception handling. Exception handling code is a bit tricky, and if you get it wrong, the OS may not get the chance to put up an unhandled exception dialog. Here are a few reasons for this:
- Exception thrown from inside the expression in an __except() clause. Throwing exceptions from the handler after the __except will not cause this behavior.
- Bad exception filter installed. This can happen with the SetUnhandledExceptionFilter, AddVectoredExceptionHandler, or _set_se_translator. This usually happens when an exception handler is installed by a dll, and then that dll unloads without removing itself. On Server 2003, this could also happen with code that tries to manually install an exception filter that isn’t in the SafeSEH list.
- Bad code to handle a stack overflow exception. If a stack overflow occurs, there is no longer a guard page at the end of the stack. If an exception filter catches the stack overflow exception, it must also reset the guard page. If it doesn’t, then the next time that your program runs out of stack space it will vanish.
- Infinite loop in exception handling. This can happen when the exception handler get blown away with garbage.
- Calls to TerminateProcess/ExitProcess or TeminateThread/ExitThread. If the debuggee asks to terminate itself, the OS will not have a problem.
As long as you have a consistent repro, debugging these problems is easy. For the first set, you just want to break on the 1st chance exception that is causing the problem. For the second set of problems, you just need to set some breakpoints. Download OS Symbols for kernel32.dll, and put breakpoints on {,,kernel32}_ExitProcess@4 and {,,kernel32}_TerminateProcess@8. You might also need to set breakpoints on {,,kernel32}_ExitThread@4 and {,,kernel32}_TerminateThread@8 if the process is exiting because it has run out of threads.
