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 Windows, no crash dump from the Dr. Watson facility...

On the one occasion the crash occurred under the debugger, the debugger did not break---it showed the application still running. When I manually paused execution, I found that my process no longer had any threads.

How can I capture the reason this process is terminating?

Answer 1

You could try using the adplus utility in the windows debugging tool package.

adplus -crash -p yourprocessid

The auto dump tool provides mini dumps for exceptions and a full dump if the application crashes.

Answer 2

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

Answer 3

First of all I want to say that I've only a moderate experience on windows development. After that I think this is a typical case where a log may help.

Normally debugging and logging supply orthogonal info. If your debugger is useless probably the log will help you.

Answer 4

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 5

If you are using Visual Studio 2003 or later, you should enable the debuggers "First Chance Exception" handler feature by turning on ALL the Debug Exception Break options found under the Debug Menu | Exceptions Dialog. Turn on EVERY option before starting the debug build of the process within the debugger.

By default most of these First Chance Exception handlers in the debugger are turned off, so if Windows or your code throws an exception, the debugger expects your application to handle it.

The First Chance Exception system allows debuggers to intercept EVERY possible exception thrown by the Process and/or System.

http://support.microsoft.com/kb/105675

Answer 6

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 7

All the other ideas posted are good.

But it also sounds like the application is calling abort() or terminate().

If you run it in the debugger set a breakpoint on both these methods and exit() just for good measure.

Here is a list of situations that will cause terminate to be called because of exceptions going wrong.

See also: http://stackoverflow.com/questions/222175/why-destructor-is-not-called-on-exception

This shows that an application will terminate() if an exceptions is not caught. So stick a catch block in main() that reports the error (to a log file) then re-throw.

int main()
{
    try
    {
        // Do your code here.
    }
    catch(...)
    {
        // Log Error;
        throw;  // re-throw the error for the de-bugger.
    }
}

Answer 8

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

Answer 9

Have you tried PC Lint etc and run it over your code? Try compiling with maximum warnings If this is a .NET app - use FX Cop.