IIS Application Pool: Settings, Recycling & Crashes

Our IIS troubleshooting support team works on application pools in most IIS cases, because the application pool is where crashes, 503 errors, and permission failures actually happen. This page documents what an application pool is, the settings that matter, how recycling works, and the diagnosis sequence for a pool that keeps stopping.

What an application pool is

An application pool is a group of one or more IIS applications served by a dedicated worker process, w3wp.exe. Each pool gets its own worker process (or processes, in a web garden), its own identity, and its own recycling and failure settings. The point is isolation: an application that leaks memory, crashes, or hangs takes down only its own worker process, not every site on the server. The Windows Process Activation Service (WAS) starts and stops worker processes; the pool configuration lives in applicationHost.config under the applicationPools section.

Practical consequences of the model: two applications in the same pool share a process, so one can crash the other; two applications in different pools cannot. A pool that is stopped serves nothing — every request to its applications returns HTTP 503. For background on how the pool fits into the rest of the server, see what IIS is.

Key settings

The settings below are the ones that decide behavior in practice. Defaults are per the processModel reference.

Recycling: what it does and when

A recycle starts a new worker process and shuts down the old one. It is not a restart of the pool: by default the recycle is overlapping — the new w3wp.exe starts and begins taking requests before the old one finishes its in-flight requests and exits, so no requests are dropped. Stopping and starting the pool, by contrast, kills the process outright and drops everything in flight.

What a recycle costs: everything held in the worker process is gone — in-process session state, in-memory caches, JIT-compiled code. The first requests after a recycle are slow while the application warms up.

Default recycling conditions, per the periodicRestart reference:

• Regular Time Interval: 1740 minutes (29 hours). Every pool recycles on this rolling interval by default. The odd number is deliberate — a fixed 24 hours would recycle at the same time every day, always in someone's business hours somewhere.
• Fixed schedule: empty. Setting Specific Times (e.g. 03:00) and setting Regular Time Interval to 0 is the standard production pattern — one predictable recycle in the quiet window instead of a rolling one.
• Memory limits: Private Memory Limit and Virtual Memory Limit, both 0 (disabled) by default on modern IIS. A private memory limit is the standard containment for a slow leak: the pool recycles when the process crosses the threshold instead of consuming the server.

Recycle events can be logged to the System event log; which conditions are logged is controlled by the logEventOnRecycle attribute. Turning this on for all conditions costs nothing and answers the recurring question of why a pool recycled at 2 p.m.

Identities and permissions

Under the default ApplicationPoolIdentity, the worker process runs as a virtual account named after the pool. To grant it NTFS permissions, ACL the resource for the principal IIS AppPoolPoolName — for example IIS AppPoolDefaultAppPool. In the permissions dialog, set the location to the local machine (the account is not in the domain), or from the command line:

icacls C:inetpubwwwrootapp /grant "IIS AppPoolMyAppPool":(OI)(CI)RX

Per the application pool identities documentation, this account accesses network resources as the machine account (DOMAINMACHINE$), which is what you ACL on file shares. Use a custom domain account only when the application needs specific network permissions or Kerberos delegation — and put a reminder on its password expiry date, for reasons covered below.

App pool keeps stopping: rapid-fail protection

A pool that starts, runs briefly, and flips back to Stopped is almost always being stopped by rapid-fail protection. Per the failure settings reference, when the worker process crashes 5 times within 5 minutes (both defaults), WAS disables the pool. From that moment every request to it returns 503 Service Unavailable, served by HTTP.sys before any application code runs.

The design intent: a process that crashes on startup would otherwise crash-loop forever, burning CPU. Rapid-fail protection stops the loop. The consequence for diagnosis: the pool being stopped is the symptom; the 5 crashes that preceded it are the problem. Starting the pool again without finding the crash cause produces the same stopped pool a few minutes later.

Diagnosis sequence

1. Read the System event log first. Filter on source WAS. Event 5002 is the pool being disabled by rapid-fail protection; 5011 is the worker process failing with a fatal communication error (one crash); 5021 reports invalid identity credentials; 5059 confirms the pool was disabled. The 5011 entries carry the failing process ID and time — match them against the Application log.
2. Read the Application event log at the same timestamps. .NET crashes log Event 1026 (.NET Runtime) with the exception type, and Event 1000 (Application Error) with the faulting module. This usually names the failing assembly or a startup exception outright.
3. Check identity password expiry. If the pool runs as a custom account and WAS logs 5021, the password is wrong or expired. This is the classic Monday-morning cause: the domain password policy expired the service account over the weekend. Re-enter the credentials in Advanced Settings → Identity.
4. Check the .NET CLR version and bitness. A pool set to v4.0 hosting a .NET Core app that expects No Managed Code, or a 64-bit pool loading a 32-bit DLL, crashes on startup every time — which is exactly the pattern that trips rapid-fail protection.
5. Enable Failed Request Tracing (FREB) for the 500–503 range on the site. FREB captures the request path through the pipeline and names the failing module. Pair it with the site's request logs — see IIS logs for where they live and how to read them.
6. Capture a crash dump if the event logs are not enough. Microsoft's crash troubleshooting guidance uses DebugDiag: set a crash rule on w3wp.exe, reproduce the crash, and read the analysis report for the faulting stack.

503 Service Unavailable: causes

Advanced settings worth changing

• Idle Time-out → 0 for any application where a cold start is noticeable. Default 20 minutes is tuned for shared hosting, not for a line-of-business app.
• Start Mode → AlwaysRunning, plus Preload Enabled → True on the site, with the Application Initialization feature installed. Per the Application Initialization documentation, IIS then starts the worker process without waiting for a request and sends a warm-up request itself, so the first real user never pays the startup cost.
• Regular Time Interval → 0, Specific Times → one quiet-window slot, as covered above.
• logEventOnRecycle → all conditions, so every recycle is explained in the System log.
• Private Memory Limit on pools with known leaks, as containment until the leak is fixed.

Monitoring pools

To see which worker processes are running and which pool each belongs to: appcmd list wp (from %windir%system32inetsrv) lists each w3wp.exe PID with its pool name. In PowerShell, the IISAdministration module provides Get-IISAppPool, which returns each pool with its state and CLR settings; Get-IISAppPool | Select Name, State is the quick health check. In IIS Manager, the Worker Processes feature at the server level shows live CPU and memory per worker process, and drilling in shows currently executing requests — the fastest way to see what a hung pool is stuck on.

When crashes persist

If the pool keeps tripping rapid-fail protection after the identity, CLR version, and bitness checks, the remaining causes — heap corruption in a native module, a crashing third-party ISAPI filter, an exception thrown before logging initializes — need dump analysis, and the site is down while that happens. Our IIS support team handles crashing pools as an emergency case type: event-log triage, DebugDiag capture and stack analysis, and a containment configuration to keep the site serving while the root cause is fixed. An engineer is available on live chat 24/7.