HTTP Error 502.5 ANCM Process Failure (ASP.NET Core)

Problem

Your ASP.NET Core site is deployed behind IIS. You browse to it and get HTTP Error 502.5 - ANCM Out-Of-Process Startup Failure (or, on newer apps, HTTP Error 500.30 - ANCM In-Process Start Failure). IIS is clearly alive — it generated that page — but your application isn’t. The error is short, generic, and tells you nothing about why the app didn’t start, which is exactly the trap: the real cause is in a log you haven’t looked at yet, not on the screen in front of you.

Symptoms

• The site returns 502.5 (or 500.30/500.31) on every request; the app never serves a response.
• It appears immediately after a deploy, a server rebuild, or a .NET version bump.
• The browser page mentions ANCM — the ASP.NET Core Module — and either “Out-Of-Process Startup Failure” or “In-Process Start Failure.”
• The IIS worker process is running, but no dotnet process for your app is (out-of-process), or the worker recycles on each request (in-process).
• An external HTTP check shows a clean 5xx from the server — the network path, DNS, and TLS are all fine; only the app is down.

What 502.5 Actually Means

IIS doesn’t run ASP.NET Core apps directly. A native module — the ASP.NET Core Module (ANCM) — sits inside IIS and is responsible for getting your app’s Kestrel-based process running and forwarding requests to it. There are two hosting models. Out-of-process: ANCM launches dotnet.exe (or your published executable) as a separate process listening on a dynamically assigned port, and IIS reverse-proxies to it. In-process (the default since ASP.NET Core 3.0): the app is loaded and run inside the IIS worker process for lower latency.

502.5 is the out-of-process failure. A 502 is a gateway error — “I tried to proxy to a backend and there was nothing there” — and that’s literally what happened: ANCM tried to start the worker process, it didn’t come up (or came up and immediately exited), so IIS has no Kestrel to talk to. The in-process equivalent throws 500.30 instead, because there’s no separate backend to gateway to; the failure is inside IIS’s own process. Same disease, two error numbers, decided purely by the hostingModel your web.config selects.

The critical thing to internalize: neither number is the error. Both are IIS reporting that your process failed to start, not why. The “why” is a startup exception, a missing runtime, or a bad launch path — and it’s written down somewhere the browser never shows you. Every minute spent re-reading the 502.5 page is a minute not spent reading the stdout log that actually holds the answer.

Top 3 Causes

1. The .NET runtime is missing or the wrong version. A framework-dependent app needs the matching ASP.NET Core Runtime — installed via the Hosting Bundle, which also registers ANCM — present on the server. Fresh servers don’t have it; a server that has .NET 6 won’t start a .NET 8 app. The tell: it’s a brand-new or rebuilt box, and dotnet --list-runtimes doesn’t show Microsoft.AspNetCore.App at the version your app targets. Install the Hosting Bundle for the right major version and run iisreset.
2. The app throws during startup. A bad connection string, a missing environment variable, an exception in Program.cs/Startup, a failed DI registration, or a config file the app can’t read — anything that crashes before the host finishes building surfaces as 502.5/500.30. The tell: dotnet --list-runtimes is fine, and the stdout log (or Application event log) shows a real .NET exception with a stack trace. Read that exception; it is the bug.
3. A wrong launch path or a bad publish. The aspNetCore element in web.config points processPath/arguments at an executable or DLL that isn’t there — an incomplete publish, a missing <AppName>.dll, a mismatch between framework-dependent and self-contained output, or a corrupted deploy. The tell: the stdout log is empty or shows the process failing to even load, and the published folder is missing the entry-point DLL the web.config names. Re-publish cleanly and confirm the output matches the processPath.

Diagnose with DechoNet

• HTTP Check confirms the server answers with a real 5xx rather than timing out or refusing the connection — proof that IIS is up and the failure is your app process, not the network, the origin being down, or a firewall in the way.
• Port Check verifies that 80/443 are open and accepting connections, so you can separate “IIS is listening but the app won’t start” (502.5) from “nothing is listening at all” (a stopped site or blocked port).
• DNS Check confirms the hostname points at the server you’re actually deploying to — deceptively common when a fix “doesn’t take” because the edits landed on a different box than the one serving traffic.

Resolution Checklist

• On the server, run dotnet --list-runtimes and confirm Microsoft.AspNetCore.App includes the major version your app targets. If not, install the ASP.NET Core Hosting Bundle and run iisreset.
• Enable the stdout log: in web.config, set stdoutLogEnabled="true" and stdoutLogFile=".\logs\stdout", create the logs folder yourself, and give the app pool identity write access. Reproduce, then read the log.
• Check the Windows Application event log for ASP.NET Core Module entries — startup failures are recorded there even when stdout logging is off.
• Confirm the hostingModel and the entry point line up: the processPath/arguments in web.config must point at the executable or dotnet <AppName>.dll that actually exists in the published output.
• Try running the app directly on the server (dotnet YourApp.dll from the publish folder) — if it crashes in the console with the same exception, you’ve isolated the problem to the app, not IIS or ANCM.
• Turn stdout logging back off once fixed — it’s for diagnosis, not production, and the log file grows unbounded.

When to Escalate

• If dotnet --list-runtimes shows the right runtime and the stdout log is completely empty (no file created, nothing in the event log), the ASP.NET Core Module itself may be missing or mismatched — reinstall the Hosting Bundle, which re-registers ANCM, rather than editing web.config further.
• If the app starts fine from the console with dotnet YourApp.dll but only fails under IIS, the difference is environment or identity: the app pool runs as a different user with a different profile, environment variables, and file permissions. Compare the environment the app sees under IIS against the console before assuming the code is wrong.