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

**Tested on**

- Build: 26100.33650
- Edition: Standard / Datacenter
- Architecture: x64
- Evidence: E1
- Verified: 2026-10-29

## 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

Default path:

```text
C:\inetpub\logs\LogFiles\W3SVC<site-id>\
```

W3C fields worth keeping:

```text
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:

```powershell
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

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

```powershell
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

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

> **Caution: Logs can contain secrets**
>
> Query strings, auth tokens and POST bodies can end up in logs/traces. Restrict ACLs, avoid logging sensitive query strings, and set retention. Do not paste raw production logs into a public issue without redaction.

## 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

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

- [Microsoft Learn — IIS logging](https://learn.microsoft.com/en-us/iis/manage/provisioning-and-managing-iis/configure-logging-in-iis)
- [Microsoft Learn — Failed request tracing](https://learn.microsoft.com/en-us/iis/troubleshoot/using-failed-request-tracing/troubleshooting-failed-requests-using-tracing-in-iis)

---

Source: https://winbook.fyi/en/server/web/iis-logs/