Question

This is related to a previous question.

What I’m trying to understand now is how come UI thread exceptions can be prevented from terminating the application while non-UI exceptions can’t be.

For reference, see this example.

Most importantly, what I would like to be able to do in that case is “silently” terminate the process–without displaying the Windows dialog box that asks whether I’d like to send an error report or not.

This is my AppDomain UnhandledExceptionHandler:

private static void CurrentDomain_UnhandledException(object sender, UnhandledExceptionEventArgs e)
{            
    try
    {
        // Maybe do some logging here if allowed
    }
    catch
    {
    }

    // then just terminate the application
    Application.Exit();            
}

UPDATE
In light of comments in this answer, I’d like to clarify that most importantly I’d like to find out more about the mechanism that enables the UI thread to have an early opportunity to catch unhandled exceptions via the Application.ThreadException mechanism. And whether such behavior could be implemented on a non-UI thread.

Answer 1

After doing some more searches on Google I found this very interesting explanation that was given to the same problem as described by Jeff Atwood on his blog.

Hi all,
Sorry for the confusion. This behavior is actually the design, though the design can be a little convoluted at times.

The first thing to understand is that the UnhandledException event is not an unhandled exception “handler”. Registering for the event, contrary to what the documentation says :-(, does not cause unhandled exceptions to be handled. (Since then they wouldn’t be unhandled, but I’ll stop with the circular reasoning already…) The UnhandledException event simply notifies you that an exception has gone unhandled, in case you want to try to save state before your thread or application dies. FWIW, I have filed a bug to get the docs fixed.

Just to complicate things, in v1.0 and 1.1, an unhandled exception did not always mean that your application would die. If the unhandled exception occurred on anything other than the main thread or a thread that began its life in unmanaged code, the CLR ate the exception and allowed your app to keep going. This was generally evil, because what would often happen was, for example, that ThreadPool threads would silently die off, one by one, until your application wasn’t actually doing any work. Figuring out the cause of this kind of failure was nearly impossible. This may be why Jeff thought it worked before…he just always saw crashes on non-main threads.

In v2.0, an unhandled exception on any thread will take down the application. We’ve found that it’s tremendously easier to debug crashes than it is to debug hangs or the silent-stoppage-of-work problem described above.

BTW, on my 1.1 machine the example from MSDN does have the expected output; it’s just that the second line doesn’t show up until after you’ve attached a debugger (or not). In v2 we’ve flipped things around so that the UnhandledException event fires before the debugger attaches, which seems to be what most people expect.

Jonathan Keljo
CLR Exceptions PM
Jonathan Keljo on February 18, 2005 10:02 PM

However, I’m still interested in how the UI thread accomplishes the trick of allow you to have a catch-all handler for all UI thread exceptions.

Even more, I’m very interested in a way to disable the .NET JIT Debugging Dialog for my application only (without disabling it for the whole machine as seen here)