Death by Background Thread Exception (including ThreadPool User Work Items)

If you use a thread or ThreadPool.QueueUserWorkItem to run code asynchronously and don’t catch your exceptions inside your WaitCallback, you will bring your entire application down when it breaks.

// This code snippet kills your web app process.
System.Threading.ThreadPool.QueueUserWorkItem(delegate
{
    var ctx = System.Web.HttpContext.Current;
    var u = ctx.User;
});

On the highlighted line, a NullReferenceException is thrown (because a background thread has no HttpContext).

If you have a JIT debugger such as Visual Studio installed on the machine, you may also see this:

This is what you will find in the event log:

1. One event with source ASP.NET 4.0.30319.0:

   An unhandled exception occurred and the process was terminated.
   
   Application ID: /LM/W3SVC/7/ROOT
   
   Process ID: 14232
   
   Exception: System.NullReferenceException
   
   Message: Object reference not set to an instance of an object.
   
   StackTrace:    at YourSite.Web.Controllers.Pages.StartPageController.<>c.<Index>b__2_0(Object <state>) in E:\Source\Repos\YourSite\src\YourSite.Web\wwwroot\Controllers\Pages\StartPageController.cs:line 37
      at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
      at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
      at System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem()
      at System.Threading.ThreadPoolWorkQueue.Dispatch()

    

2. Followed by a .NET Runtime log message:

   Application: w3wp.exe
   Framework Version: v4.0.30319
   Description: The process was terminated due to an unhandled exception.
   Exception Info: System.NullReferenceException
      at YourSite.Web.Controllers.Pages.StartPageController+<>c.<Index>b__2_0(System.Object)
      at System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
      at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
      at System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem()
      at System.Threading.ThreadPoolWorkQueue.Dispatch()
   

    

3. Followed by yet another one, this time from unmanaged error reporting having the source “Application Error”:

   Faulting application name: w3wp.exe, version: 8.5.9600.16384, time stamp: 0x5215df96
   Faulting module name: unknown, version: 0.0.0.0, time stamp: 0x00000000
   Exception code: 0xc0000005
   Fault offset: 0x00007ffbd9521b5c
   Faulting process id: 0x3798
   Faulting application start time: 0x01d180f9f39a4977
   Faulting application path: c:\windows\system32\inetsrv\w3wp.exe
   Faulting module path: unknown
   Report Id: 378450e1-ecf2-11e5-beda-10604b64d92d
   Faulting package full name: 
   Faulting package-relative application ID:

   When a managed exception is reported to Windows, it is translated into an unmanaged exception. The managed exception NullReferenceException is translated to Exception Code 0xc0000005  which is “Access Violation” (“Segmentation Fault” for you Unix hackers).

   If you read yesterday’s post, a StackOverflowException is 0xc00000fd  and virtually every other managed exception type goes under the CLR unmanaged exception code 0xe0434352 .

4. And last, a message on Information level from Windows Error Reporting:

   Fault bucket , type 0
   Event Name: CLR20r3
   Response: Not available
   Cab Id: 0
   
   Problem signature:
   P1: w3wp.exe
   P2: 8.5.9600.16384
   P3: 5215df96
   P4: YourSite.Web
   P5: 1.0.0.0
   P6: 56ebd4d1
   P7: 186c
   P8: 12
   P9: System.NullReferenceException
   P10: 
   
   Attached files:
   
   These files may be available here:
   
   
   Analysis symbol: 
   Rechecking for solution: 0
   Report Id: 378450e1-ecf2-11e5-beda-10604b64d92d
   Report Status: 0
   Hashed bucket:

    

Recognizing it

This one is relatively easy to spot, if you know to look in the Windows Event Viewer or monitor your w3wp.exe’s PIDs over time. You will experience a very poor performance as the web site is continuously restarting and dropping its caches, causing additional load on the database and increased wait times for your users while your application tries to start back up.