Buried deep in the documentation is the fact that unhandled exceptions in threadpool threads close the process entirely. You may find that the debugger catches them during testing but that release code simply closes the app - ASP.NET or WCF apps closing may not be as noticeable.

"Unhandled exceptions on thread pool threads terminate the process." from http://msdn.microsoft.com/en-us/library/0ka9477y.aspx

You may be interested in the AppDomain.UnhandledException event which could be useful...

http://msdn.microsoft.com/en-us/library/system.appdomain.unhandledexception.aspx

Also, the compiler-generated BeginInvoke methods on delegates might be affected as rumour has it that these are spun up on ThreadPool threads. See http://msdn.microsoft.com/en-us/library/2e08f6yc.aspx

The WaitCallback is not necessary since Lambdas and delegates came along. Also note that this method is de-emphasised in CLR 4.0 in favor of Tasks.

System.Threading.ThreadPool.QueueUserWorkItem(state => {
    try
    {
        WorkerClass.PerformCostlyOp(state);
    }
    catch(Exception e)
    {
        // You could react or save the exception to an 'outside' variable // threadExc = e;
    }
    finally
    {
        resetEvent.Set(); // if you're firing and not forgetting ;)
    }

}, myState);
if (!ManualResetEvent.WaitOne(resetEvent, 1000)) { throw TimeoutException("Waited ages for a thread to come in."); }
if (threadExc != null) { throw threadExc; }