We have a web application hosted on IIS6 running on Windows Server 2003 with ASP.NET version 2.0.50727. The app has been running fine till last week. Since this week, we have been getting the below error at regular intervals causing recycle of the worker process.

Faulting application w3wp.exe, version 6.0.3790.3959, faulting module ntdll.dll, version 5.2.3790.3959, fault address 0x0001a3e1.

We have tried reinstalling .NET framework as well as IIS6, with no luck. The same web app is working fine on a different Windows Server 2003 machine.

Our OS is Windows Server 2003 SP2. No updates have been made in the recent 1-2 weeks. The surprising thing is that everything was fine as of last Thu and things went downhill this week.

  • This error is sometimes caused by an improperly patched OS. Is your operating system running the latest service pack + patches? Dec 30, 2009 at 19:41

2 Answers 2


Unfortuanely the IIS error messages are not terribly descriptive. I would suggest installing something like IIS Debug which will run and monitor IIS, and log detailed crash information when it does crash, so you can diagnose the problem.


There should be another message like this one in the system log that will give you an error code:

A process serving application pool 'MyAppPool' terminated unexpectedly. The process id was '3416'. The process exit code was '0xc0000005'.

You can look up the error code (the process exit code) with the Microsoft Exchange Error Lookup Tool. I know this problem isn't about Exchange, but the tool is good for looking up error codes from various Microsoft products.

So that should give you a start on looking for the source of the problem. If you haven't already, I'd suggest moving the application into its own application pool.

To get more information about the crash, you could use Debug Diagnostics. I've had problems with that tool occasionally, so you might instead need to use adplus, which is part of Debugging Tools for Windows. You can use adplus like this.

Find your application pool's PID:

H:>%windir%\system32\inetsrv\appcmd list wp WP "4072" (applicationPool:RDWebAccess)

Run adplus against that PID:

adplus –quiet –crash –p 4072 –o PATH_TO_DUMPFILE

Once you have a dump, you can load it in WinDbg (which is also part of Debugging Tools for Windows) and run the command "!analyze -v" to make it diagnose the crash.

I'd suggest disabling recycling for the application pool before you enable adplus or Debug Diagnostics so that the application pool doesn't disconnect the debugger to recycle.

Depending on the error code, it might also be a good idea to set up a counter log in Perfmon to see if you can correlate any resource contention (high CPU, low free memory, high number of waiting requests, etc) with the crashes.

You must log in to answer this question.