Troubleshooting .NET Application Startup Failures in IIS with Failed Request Tracing

“HTTP Error 500.30 – ANCM In-Process Start Failure.” “HTTP Error 502.5 – Process Failure.” If you host .NET or ASP.NET Core apps on IIS, you have seen one of these and spent an hour guessing. The good news: IIS has a built-in diagnostic that tells you exactly what happened during startup — Failed Request Tracing (FRT) — and once you know how to read it, startup failures stop being mysteries.

This walkthrough assumes a working IIS install; if you are still bringing the server up, the Windows VPS setup guides on the main site cover IIS installation and .NET hosting prerequisites end to end.

1. Understand Where Startup Fails

• ANCM In-Process — the app runs inside w3wp.exe; a startup exception produces 500.30.
• ANCM Out-of-Process — the app runs in a separate dotnet.exe; a crash to start produces 502.5.
• Classic ASP.NET (Framework 4.8) — a startup error usually surfaces as 500 with details suppressed by customErrors.

2. Read the Windows Event Log First

Before FRT, the fastest signal is the Application log. ANCM writes detailed errors there:

Get-WinEvent -LogName Application -MaxEvents 50 | Where-Object { $_.ProviderName -like '*IIS*' -or $_.Message -like '*ANCM*' } | Format-List TimeCreated,ProviderName,Message

Common messages: “The application failed to start” (missing runtime), “Failed to bind to address” (port conflict), or an unhandled exception with a stack trace (code/config issue).

3. Enable Failed Request Tracing

FRT is installed as an IIS feature. Enable it per site in IIS Manager → [site] → Failed Request Tracing → Edit Site Tracing → Enable. Set the directory (e.g. C:\inetpub\logs\FailedReqLogFiles) and a maximum number of trace files.

Then add a rule to capture 500-range statuses. In Failed Request Tracing Rules → Add Rule:

• Trace: All content (or a specific path like *.aspx / *.dll).
• Condition: Status code equals 500 (add 502, 503 separately if needed).
• Providers: leave all selected; the ASPNET, WWW Server, and ANCM providers carry the interesting events.

4. Enable ASP.NET Core Module stdout Logging

For .NET Core apps, ANCM can capture the app’s own stdout to a file — this is the single most useful diagnostic. Edit the site’s web.config:

<aspNetCore processPath="dotnet" arguments=".\MyApp.dll" stdoutLogEnabled="true" stdoutLogFile=".\logs\stdout" hostingModel="inprocess" />

Create the logs directory first — ANCM will not create it for you, and a missing folder is itself a frequent cause of “nothing in the log.” New-Item -ItemType Directory C:\inetpub\wwwroot\logs -Force. Then reproduce the failure and read the newest file:

Get-ChildItem C:\inetpub\wwwroot\logs | Sort LastWriteTime -Desc | Select -First 1 | Get-Content

5. Common Root Causes and Fixes

Symptom	Likely cause	Fix
500.30	.NET runtime missing	Install the matching ASP.NET Core Hosting Bundle, then net stop was /y && net start w3svc
502.5	App throws on startup	Read stdout log; fix config/DB connection
App pool crashes instantly	32-bit mismatch	Set enable32BitAppOnWin64 correctly
500.19	Config section locked	Unlock via appcmd unlock config
Permissions	App pool identity lacks rights	Grant IIS AppPool\MyPool read to the folder

Grant folder permissions over PowerShell:

icacls C:\inetpub\wwwroot /grant "IIS AppPool\MyAppPool:(OI)(CI)(RX)" /T

6. Analyze the FRT Log

Open the newest fr*.xml in the tracing directory in a browser. Walk the timeline: the GENERAL_REQUEST_START, then MODULE_SET_RESPONSE_ERROR_STATUS, then the ASPNET/ANCM notifications. The last event before the failure names the module or exception. Look for the ErrorCode and the Notification where the request died — that is your culprit line.

• Failure during Execute Request Handler → application-level exception, read stdout log.
• Failure during Authenticate Request → auth module / config or identity permissions.
• Failure at module load → missing native dependency or bitness mismatch.

7. Turn Tracing Off When Done

FRT writes a file per failed request and can fill a disk fast under attack. Disable it once resolved: Failed Request Tracing → Disable. Also set stdoutLogEnabled="false" again — leaving stdout logging on in production is a slow disk-space leak.

Pair this with a host that gives you clean logs and fast disk — the Windows VPS comparison lists options. And if you want a quick box to practice on, InterServer Windows VPS is a practical place to start (promo code TRYINTERSERVER).