5

My .net application has a global exception handler by subscribing to AppDomain.Current.Domain UnhandledException event. On a few occassions i have seen that my application crashes but this global exception handler never gets hit. Not sure if its help but application is doing some COM interop.

My understanding is that as long as I don't have any local catch blocks swallowing the exception, this global exception handler should always be hit. Any ideas on what I might be missing causing this handler never been invoked?

palm snow
  • 2,392
  • 4
  • 29
  • 49

4 Answers4

3

Is this the cause of your problem?

AppDomain.CurrentDomain.UnhandledException not firing without debugging

Community
  • 1
  • 1
Beaker
  • 2,804
  • 5
  • 33
  • 54
1

The CLR is not all-powerful to catch every exception that unmanaged code can cause. Typically an AccessViolationException btw. It can only catch them when the unmanaged code is called from managed code. The scenario that's not supported is the unmanaged code spinning up its own thread and this thread causing a crash. Not terribly unlikely when you work with a COM component.

Since .NET 4.0, a Fatal Execution Engine exception no longer causes the UnhandledException event to fire. The exception was deemed too nasty to allow any more managed code to run. It is. And traditionally, a StackOverflowException causes an immediate abort.

You can diagnose this somewhat from the ExitCode of the process. It contains the exception code of the exception that terminated the process. 0x8013yyyy is an exception caused by managed code. 0xc0000005 is an access violation. Etcetera. You can use adplus, available from the Debugging Tools For Windows download to capture a minidump of the process. Since this is likely to be caused by the COM component, working with the vendor is likely to be important to get this resolved.

David Heffernan
  • 601,492
  • 42
  • 1,072
  • 1,490
Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
1

Since you are doing COM interop I do strongly suspect that some unmanaged code was running in another thread which did cause an unhandled exception. This will lead to application exit without a call to your unhandled exception handler. Besides this with .NET 4.0 the policy did get stronger when the application is shut down without further notice. Under the following conditions your application is shut down without further notice (Environmnt.FailFast).

Pre .NET 4:

  • StackOverFlowException

.NET 4:

  • StackoverFlowException
  • AccessViolationException

You can override the behaviour in .NET 4 by decorating a method with the HandleProcessCorruptedStateExceptionsAttribute or you can add the legacyCorruptedStateExceptionsPolicy tag to your App.config.

If your problem is an uncatched exception in unmanaged code you can either run your application under a debugger or you let it crash und collect a memory dump for post mortem debugging. Debugging crash dumps is usualy done with WindDbg. After you have downloaded Windbg you have adplus (a vbs script located under Programm Files\Debugging Tools for Windows) which you can attach to your running process to trigger a crash dump when the process terminates due to an exception.

adplus -crash -p yourprocessid

Then you have a much better chance to find out what was going on when your process did terminate. Windows can also be configured to take a crash dump for you via DrWatson on older Windows Versions (Windows Error Reporting)

Crash Dump Generation

Hard core programmers will insist to create their own dump generation tool which basically uses the AEDebug registry key. When this key has a value which points to an existing executable it will be called when an application crashes which can e.g. show the Visual Studio Debugger Chooser Dialog or it can trigger the dump generation for your process.

Suspend Threads

An often overlooked thing is when you create a crash dump with an external tool (it is better to rely on external tools since you do not know how bad your process is corrupted and if it is out memory you are already in a bad situation) that you should suspend all threads from the crashed process before you take the dump. When you take a big full memory dump it can take several minutes depending on the allocated memory of the faulted process. During this time the application threads can continue to wreak havoc on your application state leaving you with a dump which contains an inconsistent process state which did change during dump generation.

Jonathon Reinhart
  • 132,704
  • 33
  • 254
  • 328
Alois Kraus
  • 13,229
  • 1
  • 38
  • 64
0

This would happen if your handler throws an exception.

It would also happen if you call Environment.FailFast or if you Abort the UI thread.

SLaks
  • 868,454
  • 176
  • 1,908
  • 1,964