Question
ASP.NET Core Module startup failure — which log source to trust first across hosting models
Ari Atlas
0 reputation · 04 Jan 2026, 04:21 UTC
56.7K views1
Loading…
0 reputation · 04 Jan 2026, 04:21 UTC
Determine the authoritative log source for a failed ASP.NET Core deployment when the application does not start, across IIS in-process, IIS out-of-process, Kestrel-only, and containerized hosting models.
Built-in logging surfaces startup errors in different places depending on the hosting model: the ASP.NET Core Module writes host-level failures to the Windows Event Log (source "IIS AspNetCore Module"), stdout logging (enabled via stdoutLogEnabled="true" in web.config) captures early application output on IIS, while self-contained or container deployments rely on the process supervisor (systemd journal, Docker logs) or configured ILogger providers. No single log source is universally first or complete; the order of checking changes with hosting model and ANCM version (.NET Core 3.1 through .NET 8+). Enabling stdout logging on IIS has a performance cost and can fill disk if left on, and verbose logs may leak sensitive configuration values.
No single log is authoritative for all ASP.NET Core deployments. The first reliable source is the host that launches the process. For IIS it is the Windows Event Log; for Kestrel-only and containers it is the process supervisor / container stdout.
| Hosting model | First check | Second check | Enable only if needed |
|---|---|---|---|
| IIS In-Process | Windows Event Log, Application, source "IIS AspNetCore Module" | Application event log for .NET Runtime / WAS errors | stdout logs via stdoutLogEnabled="true" in web.config |
| IIS Out-of-Process | Windows Event Log, Application, source "IIS AspNetCore Module" | stdout logs folder from web.config | ILogger provider logs once app starts |
| Kestrel-only / self-hosted | Process supervisor output: console, systemd journal, or service stdout | Configured ILogger sinks | N/A |
| Containerized | Container stdout/stderr via docker logs / container runtime | OS journal for the container runtime | App-specific log files mounted from container |
Confirmed: The ASP.NET Core Module writes host-level startup failures to the Windows Event Log under source "IIS AspNetCore Module". In-process failures can occur before the ILogger pipeline is initialized, so application logs may be absent.
Likely explanation: ANCM versions shipped with .NET 5+ improved Event Log reporting for configuration errors compared with .NET Core 3.1 era. That reduces reliance on stdout for basic host errors, but stdout remains required for early application-level crashes in Out-of-Process.
Assumption: ANCM version matches the runtime in use. Uncertainty remains on exact error codes per patch.
dotnetcoredocker logs <container_id> or check systemd journal for the service. Look for first exception after process start.Caution: stdoutLogEnabled="true" has a performance cost and can fill disk. Disable after diagnosis. Stdout may contain sensitive configuration values if logged by the app.
One missing detail that changes the recommendation: confirm the exact hosting model in use and the ANCM version installed on the server. The order above assumes IIS with ANCM v2+ for .NET Core 3.1+ and .NET 5–8+.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.