On a production machine that I manage, the app pools periodically die. After they die, it seems impossible to stop or reset them without issuing an iisreset. In this case, I use the word "die" to mean that the sites hosted by the app pool no longer respond to requests.

There are 7 app pools; 4 never die, and the other 3 die irregularly. In the past, a pool has gone down just an hour after an iisreset. I am nearly certain that the problem in each pool is being caused by some app in the pool. Eventually I'll track down that problem.

Here's why I need your help. Once a pool dies, I can't seem to stop or recycle it. In the IIS Manager, trying to recycle a dead pool freezes the manager and I am forced to force kill it. Trying to stop a dead pool causes a hang which eventually ends with an error message that the pool did not respond to the stop or control request. The only way I have been able to bring the app pool(s) back up has been to do an iisreset.

After a pool dies, it does not appear in the iisapp.vbs output.

There are no signs of trouble in the Application Event Log.

The system is Windows Server 2003 R2 SP 2. The app pools which are having problems are populated by ASP.NET web applications.

What's going on here? Is there some command line way to cause an app pool to (re)start? Is there something wrong with my configuration that is keeping me from recycling one of these dead app pools?


Looks like those "dead" pools are more or less stuck somewhere, maybe in an infinite loop, so they're not answering stop/recycle requests from IIS.

What happens if you have a look at the Task Manager for "w3wp.exe" processes? You should have some of them, each one serving one application pool; if this is an infinite loop problem, the process servicing the "dead" pool will be heavily using CPU time (tipically maxing out a single CPU core); you can identify it from this and kill it from the Task Manager.

  • 1
    If you use Process Explorer from Sysinternals, you can find the w3wp.exe process that has your application pool name in the command line somewhere so that you know you're killing the right one. – mfinni Jun 3 '11 at 15:16
  • @mfinni: nice, didn't know that. – Massimo Jun 3 '11 at 15:30
  • Process Explorer (actually, all of the SysInternals tools) always go into c:\bin on any machine I work on, and that gets put into the %PATH% . Along with forfiles.exe , baretail.exe , robocopy.exe , and windirstat.exe – mfinni Jun 3 '11 at 16:13
  • I've looked in the task manager when a pool has died and haven't noticed any extraordinary w3wp.exe stats on any of the running instances. I'll be sure to check with Process Explorer next time to get an idea of the stats on the bad pool (and be sure I'm looking at the right one). – Eric Jun 3 '11 at 16:39
  • 1
    between procexp and procmon, you might even be able to get an idea of what the problem is. Not as well as stepping through the code or putting better logging/debugging into it, but it's something. Also - if you can, put each application into its own application pool. Slightly more overhead, but this way you only kill the troublesome one when you have to do that. – mfinni Jun 3 '11 at 17:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.