How can I determine the cause of an IIS Crash on a 64-bit Server

Question

I have a .net 2.0 web application that is running on Windows server 2003 Standard x64, using IIS 6.

The application pool for our website started crashing recently and I can't determine why. It started happening on a weekend, and the latest release of the website was several days earlier. I have determined that no other changes were made to the server recently, including code and Microsoft updates.

The event log shows the following whenever a crash occurs with no additional information in the data block:

Faulting application w3wp.exe, version 6.0.3790.3959, stamp 45d691cc, faulting module kernel32.dll, version 5.2.3790.4062, stamp 462643a7, debug? 0, fault address 0x0000000000027d8d.

This is running on a x64 server so I can't use any of the standard Debug Diagnostic Tools because even though there is a 64 bit version of it, it only attaches to IIS running in 32 bit mode.

I have tried using the Debugging Tools for Windows (x64) and was able to attach to the w3wp process, and waited for another crash. However, this slowed the server down so much that it was unusable, so I had to stop it.

What other methods can I use to try to determine the cause of an IIS crash?

Answer 1

Read about ASP.NET 2.0 Crash case study: Unhandled exceptions.

Strategy #1 – logging the exception
The first way, and this is the way I would probably recommend, is to create an UnhandledExceptionHandler to log the exception along with its stack trace in the event log as shown in this article http://support.microsoft.com/?id=911816 You add the handler like this to the web.config:

<system.web>
  <httpModules>
    <add type="WebMonitor.UnhandledExceptionModule, <strong name>"
       name="UnhandledExceptionModule"/>
  </httpModules>
      …
</system.web>   

And it hooks an eventhandler up to the UnhandledException event of the current app domain. You don’t actually need to strong name it and add it to the GAC, however if you plan it in multiple applications you should to avoid for the dll being loaded multiple times. Now the next time you get one of these unhandled exceptions, the process will still exit (unless you change the unhandled exception policy), but you have a very good chance of fixing the issue.