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.

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:

  2. Followed by a .NET Runtime log message:

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

    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:


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 *