Recover an IIS Application Pool That Stops and Returns HTTP 503

Before you begin

Applicable to supported Windows Server/client environments where the named role or feature is installed. Run read-only checks first from an elevated PowerShell or Command Prompt as appropriate. Replace example hostnames, domain names, addresses, ports and paths with values from the affected environment. Record the exact error, timestamp, OS build and scope of impact.

Production safety: obtain change approval and a verified backup before modifying AD DS, DNS, DHCP, firewall, IIS, storage or Hyper-V configuration. Ensure console/out-of-band access before network or remote-access changes.

Symptoms and likely root cause

IIS returns HTTP 503 because an application pool is stopped, disabled or repeatedly crashing.

WAS rapid-fail protection, worker crash, invalid identity/password, wrong bitness/runtime, missing dependency or bad deployment.

Diagnostic commands

%windir%\system32\inetsrv\appcmd list apppool
%windir%\system32\inetsrv\appcmd list wp
Get-WinEvent -LogName System -MaxEvents 100 | Where-Object ProviderName -Match 'WAS|W3SVC' | Select TimeCreated,Id,Message
Import-Module WebAdministration
Get-ItemProperty IIS:\AppPools\MyAppPool | Format-List *

Run the commands in order and save the complete output. The commands above are intended to establish the failing layer before a configuration change is attempted.

How to interpret the results

Identify site-to-pool mapping and first stop/crash event. Check identity, start mode, runtime, 32-bit setting, pipeline mode and folder ACL. Rapid-fail is a protection, not the root cause.

Practical correction

Fix application exception, missing dependency, invalid identity credentials or architecture mismatch. Start only the affected pool once: %windir%\system32\inetsrv\appcmd start apppool /apppool.name:MyAppPool.

Make one change at a time. Re-run the failed diagnostic after each change so the cause-and-effect relationship is clear.

Fallback and recovery

If deployment caused crash, restore previous application build/config. Do not switch all pools to LocalSystem or disable rapid-fail permanently. Preserve logs and failed request traces.

Verification checklist

Success: pool remains Started, site returns expected response and no new WAS worker crash occurs during monitored test.

• Repeat the original failing operation from the affected client/user or service.
• Test from a second approved endpoint or subnet where relevant.
• Review the relevant event log/IIS log after the fix.
• Record the change, actual result and any remaining limitation.

Frequently asked question

Should rapid-fail protection be disabled? No. Resolve the worker crash rather than hiding a restart loop.

Official technical reference

Microsoft Learn —

Use the official documentation for exact version support, prerequisites and any procedure that differs between Windows Server releases.

Technician field note

This runbook describes a controlled diagnostic path; it is not a universal guarantee that every environment has the same cause. If evidence does not match the expected result, stop and investigate rather than applying unrelated fixes. Do not mark the incident resolved until the original symptom is verified as cleared.