How can I determine why my process terminates

Question

I have a problem where during a call to a 3rd party library routine my process terminates. I am completely unable to catch this in my debugger. This may be related to this question: How can I debug a win32 process that unexpectedly terminates silently?.

When I step over a call into this library, the process being debugged simply terminates. If this termination was due to an unhandled exception or memory access violation, the debugger would have caught it. So my best guess is that the process somehow terminates normally.

What I have tried:

• Setting breakpoints on ExitThread and ExitProcess
• Setting handlers for unhandled exceptions and invalid paramters ( set_terminate and _set_invalid_parameter_handler)
• Changing _set_abort_behavior and _set_error_mode.
• Instructing the debugger to stop execution on all thrown exceptions.

But to no avail, none of the handlers are called and none of the breakpoint are triggered.

What I have observed: When the process crashes, I see two things in the debug output window:

1. Not related (see update below) I see EEFileLoadException being thrown. A quick google of this exception doesn't give me a clear answer to whar this exception means.

   First-chance exception at 0x7656b9bc (KernelBase.dll) in Program.exe: Microsoft C++ exception: EEFileLoadException at memory location 0x0030b5ac..
   First-chance exception at 0x7656b9bc (KernelBase.dll) in Program.exe: Microsoft C++ exception: [rethrow] at memory location 0x00000000..
   First-chance exception at 0x7656b9bc (KernelBase.dll) in Program.exe: Microsoft C++ exception: [rethrow] at memory location 0x00000000..
   First-chance exception at 0x7656b9bc (KernelBase.dll) in Program.exe: 0xE0434352: 0xe0434352.
   

2. When terminating, all threads return the same error code (STATUS_INVALID_CRUNTIME_PARAMETER). This error code means, as far as I can tell, that one of the c runtime functions has received an invalid parameter and the application is terminated for security reasons.

   The thread 'Win32 Thread' (0x12c0) has exited with code -1073740777 (0xc0000417).
   The thread 'Win32 Thread' (0xe04) has exited with code -1073740777 (0xc0000417).
   The thread 'Win32 Thread' (0x53c) has exited with code -1073740777 (0xc0000417).
   The thread 'Win32 Thread' (0x116c) has exited with code -1073740777 (0xc0000417).
   The thread 'Win32 Thread' (0x16e0) has exited with code -1073740777 (0xc0000417).
   The thread 'Win32 Thread' (0x1420) has exited with code -1073740777 (0xc0000417).
   The thread 'Win32 Thread' (0x13c4) has exited with code -1073740777 (0xc0000417).
   The thread 'Win32 Thread' (0x40c) has exited with code -1073740777 (0xc0000417).
   The thread 'Win32 Thread' (0xc78) has exited with code -1073740777 (0xc0000417).
   The thread 'Win32 Thread' (0xd88) has exited with code -1073740777 (0xc0000417).
   The thread 'Win32 Thread' (0x16c8) has exited with code -1073740777 (0xc0000417).
   The thread 'Win32 Thread' (0xcb8) has exited with code -1073740777 (0xc0000417).
   The thread 'Win32 Thread' (0x584) has exited with code -1073740777 (0xc0000417).
   The thread 'Win32 Thread' (0x1164) has exited with code -1073740777 (0xc0000417).
   The thread 'Win32 Thread' (0x1550) has exited with code -1073740777 (0xc0000417).
   The thread 'Win32 Thread' (0x474) has exited with code -1073740777 (0xc0000417).
   The program '[5140] Program.exe: Native' has exited with code -1073740777 (0xc0000417).
   

What I really want to know is what causes this, and optionally; how can I catch this in the debugger?

Update Regarding the EEFileLoadException, it is in fact thrown before the program makes the call which causes it to terminate, so it is not related to the termination of the process.

Update I just read that set_terminate does not work in the debugger so that's out of the question. And as noted in my comment, the handlers are managed on a per-thread basis so I don't have access to the relevant handler.

Also, the program most likely crashes in a worker thread which I have no access to so it is difficult to set any breakpoints/handlers at all.

Is there a better way to figure out what goes wrong?

Answer 1

Configure procdump to generate a dump of your process at process termination time. Not sure if VS2010 can open dump files but windbg can. Then dump all the thread stacks and you should see the one causing termination. You will then be able to inspect the stack to find the offending argument.

If your app is foo.exe then run procdump from a command prompt like this: procdump -ma -t -w foo.exe

-ma indicates full memory dump

-t indicates write dump at process termination

-w indicates to wait for the process to be launched if not already running

Then run you app outside of any debugger. Once it terminates you should see output from procdump indicating that the process has terminates and that it is writing a dump file.

Here's the link to procdump: http://technet.microsoft.com/en-us/sysinternals/dd996900