Freigeben über

Why a process vanishes

  • Artikel

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

  • Anonymous
    March 16, 2004
    The comment has been removed
  • Anonymous
    March 16, 2004
    This behavior will also happen if an application or foreign(hook) dll in an application has called SetErrorMode(SEM_NOGPFAULTERRORBOX).
  • Anonymous
    March 27, 2004
    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 ?
  • Anonymous
    April 14, 2004
    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