ASP.NET Core Module startup failure — which log source to trust first across hosting models

Diagnostic goal

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.

Constraints and uncertainty

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.

Questions

1. For a given hosting model, what is the minimal, reliable sequence of log sources to inspect before enabling additional logging?
2. How should the diagnostic order change when moving between IIS in-process, IIS out-of-process, and Kestrel-only deployments?
3. Are there version-specific ANCM behaviors (3.1 vs 5–8+) that alter where host startup errors appear?