8

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?

Matthew Xavier
  • 2,108
  • 1
  • 13
  • 18
  • How do you know the application is not exiting normally? – hova Dec 18 '08 at 16:45
  • Two reasons: 1. The application jumps through several hoops to correctly shut down some network-attached hardware when exiting normally. The hardware was still running after the crashes. 2. When an application exits normally, the debugging session ends. In this case, it did not. – Matthew Xavier Dec 18 '08 at 17:01
  • you say in your question that the application threads have terminated and the main process loop then exits. This sounds like the application is terminating normally- and that the 'bug' is probably a design problem. Check your thread loops to see why they are exiting (break points). – Klathzazt Feb 03 '09 at 14:57

11 Answers11

6

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.

chills42
  • 14,201
  • 3
  • 42
  • 77
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

Heston T. Holtmann
  • 218
  • 3
  • 13
3

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.
    }
}
Community
  • 1
  • 1
Martin York
  • 257,169
  • 86
  • 333
  • 562
  • You may want to add Kernel32!TerminateProcess() and kernel32!ExitProcess() to the set of breakpoints. Also a breakpoint on a DLL's DLL_PROCESS_DETACH message to DllMain() might be helpful. Breakpoints on the thread-oriented versions of these functions might also give a clue. – Michael Burr Dec 18 '08 at 19:41
2

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.

Community
  • 1
  • 1
Cory Foy
  • 7,202
  • 4
  • 31
  • 34
2

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?

Will Dean
  • 39,055
  • 11
  • 90
  • 118
  • This reminds me of that question about what stack overflow means, when an application was reporting stack overflow. Now what happens when an application doesn't report stack overflow, well the reason is because of stack overflow. How fortunate that all questions on this site are explained by stack o – Windows programmer Dec 19 '08 at 06:29
1

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

Filip Dupanović
  • 32,650
  • 13
  • 84
  • 114
1

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.

Salvatore Dario Minonne
  • 619
  • 5
  • 8
1

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

0

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.

Stephen Kellett
  • 3,078
  • 1
  • 22
  • 25
0

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.

Fortyrunner
  • 12,702
  • 4
  • 31
  • 54
0

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.

Ryan Armstrong
  • 381
  • 2
  • 9