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

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: 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 2

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 3

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.

Answer 4

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 5

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.