Skip to content
WinBookUnofficial

IIS logs and failed request tracing: find the 500 before you reinstall

Verified 2 min read

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.

Tested onStandard / Datacenter · Build 26100.33650 · x64
E1
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:

  1. IIS access log — which request, status, time taken.
  2. Failed request trace — which module/handler failed.
  3. 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-ip
cs(User-Agent) cs(Referer) sc-status sc-substatus sc-win32-status time-taken

Useful queries:

Terminal window
Get-Content 'C:\inetpub\logs\LogFiles\W3SVC2\*.log' -Tail 50
Select-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”
Terminal window
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,WAS

Also 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.

Sources