IiS server has frequent stoppage of App Pool

Determine which Windows event occurs when the pool stops, then apply the matching fix instead of scheduling another daily restart.

1. Identify the shutdown event

Administrator access is generally required for Event Viewer, IIS configuration, and dump collection.

1. Open Event Viewer (eventvwr).
2. Go to Windows Logs → System and filter by source Microsoft-Windows-WAS.
3. Record the event ID, timestamp, application-pool name, and process ID.
4. At the same timestamp, inspect Windows Logs → Application.

Use the resulting event as follows:

• WAS 5011: w3wp.exe crashed or terminated unexpectedly. Continue with the crash investigation below. Event 5011 identifies when the crash happened, not its underlying cause.^1^
• WAS 5013: the worker process exceeded its shutdown time limit. Continue with the shutdown-limit branch.
• HTTP 503 with the pool stopped: inspect rapid-fail protection and the pool identity.

2. If the event is WAS 5011

In Windows Logs → Application, find an event at the same timestamp:

• Application Error, Event ID 1000: record Faulting application, Faulting module, and Exception code.
• .NET Runtime, Event ID 1026: record the exception and call stack.

Common interpretations include:

• 0xC0000005: access violation.
• 0xe0434352: unhandled .NET exception; inspect Event 1026.
• 0xC00000fd: stack overflow, commonly caused by recursive application code.^1^

First check Windows Error Reporting events and their referenced directories for existing .mdmp or .hdmp files. If those already identify the failure, no additional dump is necessary.

If the logs are inconclusive, capture the next crash:

1. Install and open DebugDiag 2 Collection.
2. Select Add Rule → Crash → A specific IIS web application pool.
3. Select the affected pool.
4. Under Advanced Settings → Breakpoints, add Ntdll!ZwTerminateProcess.
5. Set Action Type to Full Userdump and Action Limit to 3–5.
6. Save dumps to a non-system drive with sufficient free space.
7. Activate the rule and wait for the failure.
8. Open DebugDiag2 Analysis → Add Data Files, select the dump, and run the analysis.^1^

If several applications share this pool, place each application in a separate pool. This isolates the application causing the worker-process crash and limits its impact.^1^

3. If the pool enters rapid-fail protection

IIS stops all applications in a pool when worker-process crashes reach the configured threshold. By default, rapid-fail protection is enabled, with 5 crashes within 5 minutes.^2^

Check it at:

IIS Manager → Application Pools → affected pool → Advanced Settings → Rapid-Fail Protection

Review Enabled, Failure Interval, and Maximum Failures. Do not simply disable protection; identify the crashes through Events 5011/1000/1026 and a dump. Disabling it can leave a repeatedly failing application active.

4. If the event is WAS 5013

Go to:

IIS Manager → Application Pools → affected pool → Advanced Settings → Process Model → Shutdown Time Limit

The documented default is 90 seconds. If it was reduced, restore it to 90 seconds or increase it enough for active requests to complete. If it is already adequate, capture a w3wp.exe dump while shutdown is hanging; incomplete HTTP requests or application shutdown code may be blocking termination.^3^

5. If the site returns 503 without crash evidence

Check IIS Manager → Application Pools → affected pool → Advanced Settings → Identity. If it uses a custom account, an invalid username or password can stop the pool and produce Service Unavailable. Update the application-pool identity credentials and start the pool again.^4^

References

1. Troubleshoot a process crash in an IIS application pool
2. Failure Settings for an Application Pool <failure>
3. An application pool exceeds time limits during shutdown in IIS
4. Troubleshooting Internet Information Services