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.