Methods of .NET self-annihilation part 4: Background Thread Exceptions

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.
    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:

JIT debugger: w3wp background exception

This is what you will find in the event log:

w3wp background exception

  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:, 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
    P6: 56ebd4d1
    P7: 186c
    P8: 12
    P9: System.NullReferenceException
    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.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.