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.

  1. 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.

  2. 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.

Comments (4)

  1. Pavel Lebedinsky says:

    Another good way for a process to disappear is to corrupt the stack pointer (esp register on x86). This can happen for example when you jump (through a bad pointer) to some random place in memory and start executing it as if it were code.

    Usually this will cause an access violation or a privileged instruction exception very soon, but sometimes you can manage to execute several bytes that translate to something like "mov esp, 0" before that happens.

  2. Ian Hanschen says:

    This behavior will also happen if an application or foreign(hook) dll in an application has called SetErrorMode(SEM_NOGPFAULTERRORBOX).

  3. so how is one supposed to debug stuff like this. i have an example where a ‘privilejeged instruction’ exception is thrown. (this is a c# project that uses interop.) the exception is thrown – and i end up in the debugger right after application.run(). setting a breakpt on this exception doesn’t make a difference… so – now what ?

  4. Gregg Miskelly says:

    I would need a bit more context on where this is coming from to offer a suggestion. Make sure that you aren’t hiding external code from the callstack. If this is a pinvoke issue, you might try and useing custmore debug probes. See http://www.gotdotnet.com/Community/UserSamples/Details.aspx?SampleGuid=c7b955c7-231a-406c-9fa5-ad09ef3bb37f

Skip to main content