How to stop a zombie IIS application pool

Have you ever stopped an IIS application pool, just to find it running later? This a quick post to explain why this happens, and how to correctly stop the app pool so it stays down.

(check our Reset, Restart and Recycle IIS guide for more on effectively restarting your application pools and avoiding the problematic side effects).

Why stop an application pool in the first place?

You may choose to stop one of your app pools if:

  • It’s having an excessive impact on your server.
  • It is hosting applications that you don’t want running (unused, broken, or for security reasons).
  • It’s a copy of another application that’s already running (and you don’t want it conflicting or running twice).
  • You are doing a performance test on another app, and you want everything else stopped.
  • You are updating the applications and you don’t want them restarting during the update.

Stopping apppools for security and performance reasons can actually be an effective strategy when dealing with many customers/apps on the server, or removing unused applications that can become a DOS target.

Why does the stopped application pool come back to life?

The reason for this is simple. The Windows Process Activation Service (WAS, WPAS) will start all application pools when it starts.

So, if WAS restarts for any reason, it will re-start your stopped application pools. 

This will happen in all of these cases:

  • IISRESET
  • Net stop was /yes && net start w3svc (restarting IIS services)
  • Rebooting your server VM

When someone makes a request to the application that’s mapped to your application pool, it will then start a worker process.

The application pool will also start a worker process when using the AlwaysRunning mode. Which we totally recommend for your important production sites, as you can see in our Maximize IIS Application pool availability guide.

How do I stop the pool so it stays stopped?

Easy.

You must also configure the application pool to set autoStart=false. This way, WAS knows not to start it unless you explicitly choose to start it.

Here is the compact command:

%windir%\system32\inetsrv\appcmd set apppool POOLNAME /autoStart:false
%windir%\system32\inetsrv\appcmd stop apppool POOLNAME 

This causes this applicationHost.config configuration to be written in your application pool’s definition:

<add name="TestApp" autoStart="false" ...>

To start the application pool back up

If and when you want to get the pool started back up:

%windir%\system32\inetsrv\appcmd set apppool POOLNAME /autoStart:true
%windir%\system32\inetsrv\appcmd start apppool POOLNAME 

You can skip the autoStart:true command if you want to continue manually managing the pool’s uptime, and just start/stop it when needed.

That’s it. No more zombie application pools.

P.S. If you haven’t already, check out our Reset, Restart, Recycle IIS guide for useful tips on how to correctly restart production apppools with minimum downtime.

Guide: IIS Thread pool optimization

We’ve just released our new IIS Threading guide, which explains how the IIS thread pool works and how it affects your website performance.

It turns out that many people don’t have a clear sense of how the IIS thread pool relates to hangs and slowdowns in their website.

So, we took the opportunity to clear things up, and explain how IIS thread pool exhaustion or thread starvation actually affects IIS site performance.

This includes:

  1. 503 Queue Full errors, or application pool queue buildup
  2. Reduced RPS, especially for high performance websites

We also explain how most traditional hangs and slow loads are NOT caused by IIS threadpool issues, but instead the application-specific thread pools like the CLR thread pool, or the Classic ASP thread pool.

Monitoring IIS thread performance

We also show a simple way to monitor IIS counters to detect IIS pool issues.

If you have LeanSentry installed on the server, you can get a lot deeper into actually diagnosing most thread pool issues down to code (part of our application pool failure diagnostics). We’ll cover this well.

LeanSentry diagnosing IIS thread pool issues causing 503 queue full errors
LeanSentry diagnosing an 503 queue full incident down to code causing CPU overload, which is then causing IIS thread delays.

Optimizing the thread pool

In the guide, we dig into the specific causes of threading issues, that actually happen. This is based on monitoring 30K+ IIS websites with LeanSentry in the last decade.

Surprisingly, there are only a couple causes of thread pool issues that matter.

We’ll cover each one, and how to configure the IIS threadpool to resolve them.

For the juicy details, head over to the thread pool guide.

Guide: Maximum IIS application pool availability

Building on our last week’s Reset, Restart, Recycle IIS guide, this week we are digging deeper into improving IIS application pool availability.

Head over to How to maximize IIS application pool availability to see how you can tweak your IIS websites to:

  1. Start in 100%-warm state, for best cold-start performance (even after a production restart or recycle)
  2. Have zero startup delay (despite the warmup we just mentioned)

Yes, basically you CAN have your cake and eat it too.

Meaning your website is always warm, and can recycle without the users feeling it. This requires getting a lot of pieces right, and guide shows you exactly how to do that.

Best of all, it requires ZERO code.

Configure it all instantly with the ConfigureWarmup tool

We have a tool that will automatically configure the warmup configuration for your website. We’ll be releasing this tool shortly, but if you want it now, be sure to sign up for the Guide newsletter early access. This will allow you to get all our guides, and tools, before they are publicly released online.