How can I debug a win32 process that unexpectedly terminates silently?

Question

I have a Windows application written in C++ that occasionally evaporates. I use the word evaporate because there is nothing left behind: no \"we\'re sorry\" message from Window

Answer 1

Well, the problem is you are getting an access violation. You may want to attach with WinDBG and turn on all of the exception filters. It may still not help - my guess is you are getting memory corruption that isn't throwing an exception.

You may want to look at enabling full pageheap checking

You might also want to check out this older question about heap corruption for some ideas on tools.

Answer 2

You could check the Windows Logs in Event Viewer on Windows.

Answer 3

Possible causes come to mind.

• TerminateProcess()
• Stack overflow exception
• Exception while handling an exception

The last one in particular results in immediate failure of the application.
The stack overflow - you may get a notification of this, but unlikely.

Drop into the debugger, change all exception notifications to "stop always" rather than "stop if not handled" then do what you do to cause the program failure. The debugger will stop if you get an exception and you can decide if this is the exception you are looking for.

Answer 4

The most common cause for this kind of sudden disappearance is a stack overflow, usually caused by some kind of infinite recursion (which may, of course, involve a chain of several functions calling each other).

Is that a possibility in your app?

Answer 5

I spent a couple hours trying to dig into this on Visual Studio 2017 running a 64-bit application on Windows 7. I ended up having to set a breakpoint on the RtlReportSilentProcessExit function, which lives in the ntdll.dll file. Just the base function name was enough for Visual Studio to find it.

That said, after I let Visual Studio automatically download symbols for the C standard library, it also automatically stopped on the runtime exception that caused the problem.

Answer 6

This could be a call to _exit() or some Windows equivalent. Try setting a breakpoint on _exit...