IIS logs and failed request tracing: find the 500 before you reinstall
Read W3C IIS logs, enable failed request tracing, correlate 500/503 with app-pool and HTTP.sys events, and keep logs useful without leaking data.
- Build
- 26100.33650
- Edition
- Standard / Datacenter
- Architecture
- x64
- Support
- Documentation (E1)
- Evidence
- E1Official documentation
- Verified
- 2026-10-29
- Page type
- Troubleshoot
The short answer
Section titled “The short answer”For an IIS failure, collect three layers:
- IIS access log — which request, status, time taken.
- Failed request trace — which module/handler failed.
- Windows events / HTTP.sys — app-pool crash, port conflict, TLS.
Start with the status code; do not restart IIS before reading the log.
Access logs
Section titled “Access logs”Default path:
C:\inetpub\logs\LogFiles\W3SVC<site-id>\W3C fields worth keeping:
date time s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ipcs(User-Agent) cs(Referer) sc-status sc-substatus sc-win32-status time-takenUseful queries:
Get-Content 'C:\inetpub\logs\LogFiles\W3SVC2\*.log' -Tail 50Select-String -Path 'C:\inetpub\logs\LogFiles\W3SVC2\*.log' -Pattern ' 500 | 503 'sc-substatus and sc-win32-status often identify the real cause (e.g. 500.19 config, 500.30 ANCM start failure, 503 app pool down).
Enable failed request tracing
Section titled “Enable failed request tracing”In IIS Manager → site → Failed Request Tracing:
- enable for the site;
- set a path outside the web root;
- add a rule for status codes
500-599(and slow requests if needed); - reproduce once, then read the XML trace.
The trace shows the module/handler and the exact failure point. It is far more useful than “500 Internal Server Error”.
Correlate with Windows
Section titled “Correlate with Windows”Get-WinEvent -LogName System -MaxEvents 200 | Where-Object ProviderName -match 'HTTP|W3SVC|Application'Get-WinEvent -LogName Application -MaxEvents 200 | Where-Object ProviderName -match 'Application Error|.NET Runtime'Get-Service W3SVC,WASAlso check:
- app pool state (
Get-IISAppPool); - port conflict (
netsh http show servicestate); - disk full (logs stop, app fails);
- certificate binding (TLS handshake failures happen before IIS logging).
Status cheat sheet
Section titled “Status cheat sheet”| Status | First check |
|---|---|
| 400 | Host header/binding malformed |
| 401.3 | NTFS permission for app pool identity |
| 403.14 | Directory browsing disabled / no default doc |
| 404 | Binding/handler/route, not necessarily missing file |
| 500.19 | web.config invalid or module missing |
| 500.30 | ANCM/app failed to start |
| 502/503 | Upstream/HPH/app pool not running |
| 504 | Upstream timeout |
Retention and rotation
Section titled “Retention and rotation”- Keep logs on a dedicated volume, not the system drive.
- Set a size/age limit; compressed archives are fine.
- Centralize if you have multiple servers; local logs disappear with the host.
- Back up configuration separately; logs are evidence, not backup.
Lab note
Section titled “Lab note”This is E1. The lab has a real IIS site (Lab, W3SVC id 2) and default logging, but failed-request tracing was not enabled for this page. The paths/commands are the verification steps, not a claim that every status was reproduced.