How to catch ALL exceptions/crashes in a .NET app

Question

I have a .NET console app app that is crashing and displaying a message to the user. All of my code is in a try{} catch(Exception e){} block, but still errors are occasionally displayed.

In a Win32 app, you can capture all possible exceptions/crashes by installing various exception handlers:

_set_se_translator SetUnhandledExceptionFilter _set_purecall_handler set_terminate set_unexpected _set_invalid_parameter_handler

What is the equivalent in the .NET world so I can handle/log/quiet all possible error cases?

Answer 1

You can add an event handler to AppDomain.UnhandledException event, and it'll be called when a exception is thrown and not caught.

Answer 2

You can use the AppDomain.CurrentDomain.UnhandledException to get an event.

Answer 3

The Global.asax class is your last line of defense. Look at:

protected void Application_Error(Object sender, EventArgs e)

method

Answer 4

You may also go with Application.ThreadException Event.

Once I was developing a .NET app running inside a COM based application; this event was the very useful, as AppDomain.CurrentDomain.UnhandledException didn't work in this case.

Answer 5

I think you should rather not even catch all Exception but better let them be shown to the user. The reason for this is that you should only catch Exceptions which you can actually handle. If you run into some Exception which causes the program to stop but still catch it, this might cause much more severe problems. Also read FAQ: Why does FxCop warn against catch(Exception)?.

Answer 6

Be aware that some exception are dangerous to catch - or mostly uncatchable,

• OutOfMemoryException: anything you do in the catch handler might allocate memory (in the managed or unmanaged side of the CLR) and thus trigger another OOM
• StackOverflowException: depending whether the CLR detected it sufficiently early, you might get notified. Worst case scenario, it simply kills the process.

Answer 7

Be aware that catching these unhandled exceptions can change the security requirements of your application. Your application may stop running correctly under certain contexts (when run from a network share, etc.). Be sure to test thoroughly.

Answer 8

This article in codeproject by our host Jeff Atwood is what you need. Includes the code to catch unhandled exceptions and best pratices for showing information about the crash to the user.

Answer 9

Although catching all exceptions without the plan to properly handle them is surely a bad practice, I think that an application should fail in some graceful way. A crash should not scare the user to death, and at least it should display a description of the error, some information to report to the tech support stuff, and ideally a button to close the application and restart it. In an ideal world, the application should be able to dump on disk the user data, and then try to recover it (but I see that this is asking too much).

Anyway, I usually use:

AppDomain.CurrentDomain.UnhandledException

Answer 10

Contrary to what some others have posted, there's nothing wrong catching all exceptions. The important thing is to handle them all appropriately. If you have a stack overflow or out of memory condition, the app should shut down for them. Also, keep in mind that OOM conditions can prevent your exception handler from running correctly. For example, if your exception handler displays a dialog with the exception message, if you're out of memory, there may not be enough left for the dialog display. Best to log it and shut down immediately.

As others mentioned, there are the UnhandledException and ThreadException events that you can handle to collection exceptions that might otherwise get missed. Then simply throw an exception handler around your main loop (assuming a winforms app).

Also, you should be aware that OutOfMemoryExceptions aren't always thrown for out of memory conditions. An OOM condition can trigger all sorts of exceptions, in your code, or in the framework, that don't necessarily have anything to do with the fact that the real underlying condition is out of memory. I've frequently seen InvalidOperationException or ArgumentException when the underlying cause is actually out of memory.

Answer 11

it doesn't hurt to use both AppDomain.CurrentDomain.UnhandledException Application.ThreadException

but keep in mind that exceptions on secondary threads are not caught by these handlers; use SafeThread for secondary threads if needed