{"id":909,"date":"2026-10-21T22:40:26","date_gmt":"2026-10-21T22:40:26","guid":{"rendered":"https:\/\/windows-vps.org\/blog\/?p=909"},"modified":"2026-10-21T22:40:26","modified_gmt":"2026-10-21T22:40:26","slug":"aspnet-core-iis-ancm-module-deployment-errors","status":"publish","type":"post","link":"https:\/\/windows-vps.org\/blog\/aspnet-core-iis-ancm-module-deployment-errors\/","title":{"rendered":"ASP.NET Core Behind IIS: ANCM Hosting Models and 500.30 \/ 502.5 \/ 500.19 Fixes"},"content":{"rendered":"\n

ASP.NET Core does not run inside IIS. It runs as a separate out-of-process dotnet<\/code> worker, and IIS sits in front of it as a reverse proxy using the ASP.NET Core Module (ANCM). Understanding that one sentence explains almost every deployment failure administrators hit on Windows: the 500.30, the 502.5, the app that works with dotnet run<\/code> but not through a site binding, and the HTTPS redirect loop. This article covers the install order, the module configuration that matters, and the diagnostic path for each of the common failures.<\/p>\n\n\n\n

The Two Hosting Models and Which One You Are Using<\/h2>\n\n\n\n

In-process hosting (<AspNetCoreHostingModel>InProcess<\/AspNetCoreHostingModel><\/code> in the project file, and the default since .NET Core 3.0) loads the application inside w3wp.exe<\/code> via a modified ANCM. Out-of-process hosting runs dotnet MyApp.dll<\/code> as a child process and proxies HTTP over a loopback port. In-process is faster \u2014 no extra hop, no port, less memory \u2014 and it is the right default on Windows Server. Out-of-process remains useful when you need a different runtime version than the server’s or when you want the worker isolated from IIS.<\/p>\n\n\n\n

The distinction matters for troubleshooting because the log locations and error codes differ. Both ultimately surface in the Windows Application event log under source IIS AspNetCore Module V2<\/code>, but in-process failures usually appear as a request-level 500 with a stack trace in the app’s own logging, while out-of-process failures often appear as a proxy error before the app has produced any output.<\/p>\n\n\n\n

Install Order: Runtime, Hosting Bundle, IIS Feature<\/h2>\n\n\n\n
Step<\/th>Component<\/th>Why order matters<\/th><\/tr><\/thead>
1<\/td>IIS role with Static Content, Request Filtering, WebSocket Protocol<\/td>ANCM installer registers handlers against an existing IIS<\/td><\/tr>
2<\/td>ASP.NET Core Hosting Bundle (.NET 8 or later)<\/td>Installs ANCM V2 plus the shared runtime and dotnet<\/code> CLI<\/td><\/tr>
3<\/td>Verify dotnet --list-runtimes<\/code><\/td>Confirms the runtime matches the app’s target framework<\/td><\/tr>
4<\/td>Publish output to the site folder<\/td>web.config is generated by the SDK at publish time<\/td><\/tr>
5<\/td>Restart IIS (iisreset<\/code>)<\/td>Picks up module registration changes<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

The most common install mistake is installing the runtime (the lightweight installer) rather than the Hosting Bundle. The runtime includes dotnet<\/code> and the shared frameworks but not ANCM, so IIS has no handler for the application and returns a static 404 or 500.19. If %ProgramFiles%\\IIS\\Asp.Net Core Module\\V2\\aspnetcorev2.dll<\/code> is missing, this is your problem.<\/p>\n\n\n\n

After installing the bundle, iisreset<\/code>. The ANCM installer registers the module at the server level, but a running worker process will not see the new module until it restarts. Skipping this step produces a “module handler not found” error on an otherwise correct installation.<\/p>\n\n\n\n

Reading the web.config the SDK Generates<\/h2>\n\n\n\n

Publishing an ASP.NET Core project emits a web.config<\/code> whose relevant section looks like this for in-process hosting:<\/p>\n\n\n\n

<aspNetCore processPath=\"dotnet\" arguments=\".\\MyApp.dll\" hostingModel=\"inprocess\" stdoutLogEnabled=\"false\" \/><\/code><\/p>\n\n\n\n

Three edits are worth making. First, set stdoutLogEnabled=\"true\"<\/code> and stdoutLogFile=\".\\logs\\stdout\"<\/code> during initial deployment \u2014 this is the only place startup exceptions are written before the app’s own logger is configured. Turn it back off once stable, or the log directory will fill. Second, add hostingModel=\"inprocess\"<\/code> explicitly if you are migrating from an older publish profile that assumes out-of-process. Third, for out-of-process, set the processPath<\/code> to the absolute path of dotnet.exe<\/code> if the PATH is ambiguous.<\/p>\n\n\n\n

Remember that web.config<\/code> in the publish folder is the effective one. Editing the project-level file does nothing at runtime, and editing the deployed copy gets overwritten on the next publish unless you have configured the build to preserve changes. Keep a transform or a post-publish step instead.<\/p>\n\n\n\n

Application Pool and Identity Settings<\/h2>\n\n\n\n

Two application pool settings cause more ASP.NET Core support tickets than any others. The first is “No Managed Code”: the pool’s .NET CLR Version must be set to No Managed Code, because IIS is only proxying \u2014 leaving it on v4.0 loads the legacy CLR for no reason and can cause odd module conflicts. The second is the identity: the default ApplicationPoolIdentity<\/code> works fine for reading the publish folder, but any file writes (logs, uploads, data protection keys) need an explicit ACL grant on those folders.<\/p>\n\n\n\n

Data protection keys deserve a specific mention. ASP.NET Core encrypts cookies and antiforgery tokens using keys stored under the user profile by default. Under ApplicationPoolIdentity<\/code> those keys live in a profile that may be recycled or recreated, which manifests as users being logged out at random. Persist the keys to a folder with an explicit ACL, or to a shared location if you run multiple nodes.<\/p>\n\n\n\n

Diagnosing 500.30, 502.5, and 500.19<\/h2>\n\n\n\n

HTTP Error 500.30 – ANCM In-Process Start Failure<\/code> means the app started and then exited. The app’s stdout log is the place to look. Typical causes: a missing appsettings section, a connection string the app cannot reach at startup, a Program.cs<\/code> exception in top-level statements, or a target framework mismatch between the publish output and the installed runtime.<\/p>\n\n\n\n

HTTP Error 502.5 – Process Failure<\/code> is the out-of-process analogue: ANCM launched dotnet app.dll<\/code> and the process exited before binding a port. Read the stdout log for the exception. If there is no log at all, the process failed before the app’s logger initialised \u2014 usually a missing runtime version or a bad path in processPath<\/code>.<\/p>\n\n\n\n

HTTP Error 500.19<\/code> with “cannot read configuration file because it contains invalid XML” or “this configuration section cannot be used at this path” is an IIS-level problem, not an app problem. It is usually a missing IIS feature (AspNetCoreModuleV2 section locked), a 32-bit\/64-bit mismatch in the handler, or a duplicated <aspNetCore><\/code> element from a copied web.config. Check the “Config Error” block on the error page \u2014 it names the exact file and line.<\/p>\n\n\n\n

For anything intermittent, enable Failed Request Tracing at the site level with a rule scoped to status codes 400–599. The trace will show how far the request got through the module chain, which cleanly separates an ANCM problem from an application problem. Our walkthrough on tracing .NET startup failures in IIS<\/a> has the step-by-step setup.<\/p>\n\n\n\n

HTTPS, Forwarded Headers, and the Redirect Loop<\/h2>\n\n\n\n

The classic symptom is an infinite redirect on an HTTPS site that works over HTTP. IIS terminates TLS and forwards a plain HTTP request to the app; the app sees HttpContext.Request.Scheme == \"http\"<\/code> and its UseHttpsRedirection<\/code> middleware redirects to HTTPS, which IIS terminates again, and the cycle repeats. The fix is the Forwarded Headers middleware, configured to trust the loopback proxy and to honour X-Forwarded-Proto<\/code>:<\/p>\n\n\n\n

app.UseForwardedHeaders(new ForwardedHeadersOptions { ForwardedHeaders = ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto });<\/code><\/p>\n\n\n\n

This must be registered before UseHttpsRedirection<\/code> and before authentication. In .NET 8 and later the default known-networks list excludes the loopback address, so you must either add KnownNetworks<\/code>\/KnownProxies<\/code> for 127.0.0.1<\/code> and ::1<\/code>, or clear the lists if IIS is the only ingress. Also configure ASPNETCORE_FORWARDEDHEADERS_ENABLED=true<\/code> on hosts where you cannot change code.<\/p>\n\n\n\n

A Deployment Checklist<\/h2>\n\n\n\n