using System;
using System.Collections.Generic;
using System.Text;
using System.Threading;
 
namespace CatchUnhandledThreadExceptions
{
   class Program
   {
      static void Main(string[] args)
      {
         AppDomain.CurrentDomain.UnhandledException += 
            new UnhandledExceptionEventHandler(MyHandler);
 
         new Thread(new ThreadStart(doWork)).Start();
 
         Console.WriteLine("Press ENTER to exit");
         Console.ReadLine();
      }
 
      static void MyHandler(object sender, UnhandledExceptionEventArgs args)
      {
         Console.WriteLine(((Exception)args.ExceptionObject).Message);
      }
 
      static void doWork()
      {
         throw new Exception("Secondary thread exception");
      }
   }
}

Da stackoverflow:  

"Registering an UnhandledExceptionEventHandler with AppDomain.UnhandledException does not mean that unhandled exceptions become handled. Instead, it is a mechanism to be able to log the exception and relevant program state to aid in later debugging. The exception will remain unhandled and Windows Error Reporting will be invoked. 

In reality, when this event is invoked it's "too late" for the the exception to be handled. Assuming you could tell the runtime to continue execution, where would execution unwind to? Not a single frame on the call stack wanted to handle the exception. At best, the executing thread could be terminated; but what if it's on the only foreground thread? Better to propagate the unhandled exception to the operating system's default unhandled exception filter and let it invoke Windows Error Reporting. 

Edit with some additional comments: Now, certain applications you want to design to be crash-resistant, such as long-running service processes. It may make sense to add "catch-all"* exception handlers in some cases, such as a job queue that executes jobs and it doesn't matter if an individual job fails with an unhandled exception; we log the problem and move on to the next job. However, a root catch-all handler in something like Main makes little sense: your entire application is now in an unknown state. You could log the exception and terminate, but you'd be missing out on the benefits of Windows Error Reporting: post-mortem minidumps and an easy button (the "Debug" button on that dialog) to invoke the registered JIT debugger that will take you directly to the problem. For most software, my advice is to simply let your software crash; in-your-face bugs with minidumps are usually some of the easiest to fix. 

*Some exceptions are inherently "uncatchable", such as a StackOverflowException. Others, such as an AccessViolationException are catchable, but are inherently indicative of a serious program state incongruity (couldn't read or write from an expected memory location). It is never a good idea to attempt recovery from such exceptions."