Unhandled exceptions

There are two kinds of threads executing inside managed code:  the ones we start in managed code and the ones that wander into the CLR. The ones that started in managed code include all calls to Thread.Start(), the managed threadpool threads, and the Finalizer thread(s).

For all the threads we start in managed code, the CLR has its own exception backstop and nothing will leak out to the OS unhandled exception filter.  We can call the AppDomain.UnhandledException event from this backstop.

For the ones that wander into managed code, we are registered on the OS unhandled exception filter so we can call the AppDomain.UnhandledException from there.  Of course, different unmanaged components are registered in a rather random order on the OS unhandled exception filter.  Some of them chain nicely. Others (like the VC6 filter) might decide to rip the process without chaining under certain circumstances.

So you are only completely assured of getting the AppDomain’s UnhandledException event on the managed threads.

Another subtlety is that you must register for this event in the Default AppDomain. That’s because – by the time the exception is unhandled – the thread has unwound out to the default AppDomain. That’s where all threads start executing and that’s where they eventually unwind to. This is an unfortunate restriction for some scenarios, but it’s not clear whether it will ever be relaxed.

Finally, the CLR has some default policy for which unhandled exceptions should terminate the process and which ones should be swallowed. Generally, unhandled exceptions on threadpool threads, the Finalizer thread(s) and similar “reusable” threads are swallowed. We simply terminate the current unit of work and proceed to the next one. Unhandled exceptions on the main thread of a managed executable will terminate the process.

Nobody particularly likes the defaults that were chosen. But everyone seems to have conflicting opinions on what would have made better defaults. And, at this point, nothing is likely to change. The UnhandledException event is there so that you can install your own policy. You can terminate the process, log the failure, trap to the debugger, swallow the exception or any other behavior.

Comments

• Anonymous
  June 22, 2003
  keep showing up on my pc when turn on
• Anonymous
  June 22, 2003
  keep showing up on my pc when turn on
• Anonymous
  January 26, 2004
  The comment has been removed
• Anonymous
  January 26, 2004
  It turns out that I'm the only person on our team who remembers the design I described in the above post. In other words, I must have imagined parts of it.
  
  You are correct that in V1 & V1.1, there is no way to swallow an exception via the UnhandledException event, if that exception is going to terminate the process. In that sense, the event is strictly a notification.
  
  You can still do the reverse. If an exception would be swallowed, you can use the UnhandledException event to terminate the process via System.Environment.Exit or some other technique.
  
  In a future version, we will give the host better control over how unhandled exceptions should be treated. But that's no excuse for my mistakes in the above post.
• Anonymous
  January 27, 2004
  The comment has been removed
• Anonymous
  January 27, 2004
  The comment has been removed