I recently posted a question about console apps and AppDomain.CurrentDomain.UnhandledException -- specifically, why doesn't it work as described in the MSDN documentation? I even filed an official bug report on this. I guess it worked, because Microsoft's Jonathan Keljo was kind enough to explain this behavior in the comments:
I wonder what happens in 2.0 with ThreadAbortExceptions. Since we can’t catch those, I hope they are a specical exception to the “unhandled exception on any thread will take down the application” rule.
" the CLR eats the exception and allows your app to keep going"
I’ve noticed this same behavior when using Timers. If an exception occurs in the code run by the System.Timers.Timer class, the timer just suddenly stops firing, and you never know what happenned, or that it’s not firing any more.
Good to know it’ll be fixed in 2.0 
Tim
So is there any way to actually build an unhandled exception “handler”? I have a situation where, if there’s an unhandled exception, I want the handler to log it properly, and then give the user a generic message that “the operation couldn’t be handled”, then return to the starting screen. Since I’m building a Kiosk app, having it crash to the desktop isn’t really an option, so I’m hoping there’s a workaround for this behavior.
Thanks!
Ok, so I have something called an Opc Client that spawns new threads to publish data changed events to our application. The OpcClient is a COM object.
As the exceptions that rise at threads started outside the CLR are ignored what happens is that most of my code does not rise exceptions as the code executes on that thread.
What I’m supposed to do apart of throwing the exceptions in a new Thread created inside the CLR?