10

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?

Community
  • 1
  • 1
Yngve Hammersland
  • 1,634
  • 2
  • 14
  • 28
  • I realized that the terminate handler are not called since they are installed on a per-thread basis and I have no access to the crashing thread. – Yngve Hammersland Sep 27 '11 at 12:10
  • I'm having a situation similar to this, except in my case, TRACE messages are also not being delivered to the Output Window. When I attached with WinDebug instead, I discovered there was a `DebugBreak()` call that VS was ignoring, which caused the process to `terminate()` itself, resulting in `The program [0x2F74] 'OUTLOOK.EXE' has exited with code -1073740777 (0xc0000417).` Unfortunately, I can't figure out why Visual Studio is ignoring the program it's supposed to be debugging. – Mooing Duck Apr 04 '14 at 19:11

3 Answers3

2

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

Marc Sherman
  • 2,303
  • 14
  • 22
0

Run your application nuder debugger (or attach to a running process), press Ctrl+Alt+E and check the boxes to have debugger stop execution on exception for you.

Every time an exception takes place, debugger will break. You will be able to check thread states/call stack to possibly identify the problem.

Typical reasons for an app to unexpectedly terminate are:

  • something really posts WM_QUIT message and this instructs the app to close
  • an exception takes place, and it is not handled (esp. on background thread); the exception traverses call stack up to OS and it does not know what to do with all the stuff and just kills the process

As EEFileLoadException exception takes place and you don't knnow what it is about, you perhaps would want the first thing understand if it is handled or not, if it is actually a fatal thing for your application.

Roman R.
  • 68,205
  • 6
  • 94
  • 158
  • 1
    I already tried to instruct the debugger to stop on all thrown exceptions without luck. – Yngve Hammersland Sep 27 '11 at 11:44
  • Also, I don't think `WM_QUIT` is the problem since the app terminates while debugging the main thread. This would point to another thread being the culprit. – Yngve Hammersland Sep 27 '11 at 11:44
  • Does the debugger stop on exception? What type of debugger you are using, native and/or managed? – Roman R. Sep 27 '11 at 11:46
  • 1
    The debugger does not stop execution. I am using a pure native debugger. AFAIK, there is no managed code involved. (though, there may be managed code under the covers of the 3rd party library) – Yngve Hammersland Sep 27 '11 at 11:49
  • Your post contains quotes for exception taking place. Debugger just has to stop on these, or your exception settings under debugging are instructing it to continue. The only thing I can think of is that third party managed code is loaded, and it causes `automatic` debugger mode to start managed debugging. This will ignore native stuff. – Roman R. Sep 27 '11 at 11:53
  • The exception is unrelated. I have updated the question to reflect this. – Yngve Hammersland Sep 27 '11 at 12:02
-2

I faced with the same problem before. I just deleted obj file in C# project. And rebuild again and it project worked. Hope this will solve your problem.

Taryn
  • 242,637
  • 56
  • 362
  • 405
y.baris
  • 73
  • 9