How to Troubleshoot Developer Web Apps on IIS

Some IIS errors never make it to your browser at all, the request fails internally and IIS just returns a blank response or a misleading generic page. Failed Request Tracing (also called FREB, Failed Request Event Buffering) captures everything: every module that touched the request, every status code, every timing measurement. It's the IIS equivalent of attaching a debugger.

First, make sure the FREB feature is installed. Open PowerShell as Administrator and run:

Enable-WindowsOptionalFeature -Online -FeatureName `
  IIS-HttpTracing -All

Or, through the GUI: Control Panel → Programs → Turn Windows features on or off → Internet Information Services → World Wide Web Services → Health and Diagnostics → check Tracing.

Now configure it in IIS Manager. Select your site in the left tree, then in the right Actions panel click Failed Request Tracing.... Check Enable, set the directory to somewhere you can easily access (like C:\inetpub\logs\FailedReqLogFiles), and set Max number of trace files to 50.

Then double-click Failed Request Tracing Rules from the site's Features view. Click Add... in the right panel. Select All content (*), set the status codes to 400-999, and set Verbosity to Verbose. Click OK.

Now reproduce your error. Navigate to the FREB log folder and open the newest fr######.xml file in Internet Explorer or Edge (the XSL stylesheet renders it properly in those browsers, it won't look right in Chrome). You'll see a color-coded waterfall of every IIS event. Red entries are where the failure occurred. The MODULE_SET_RESPONSE_ERROR_STATUS event will tell you exactly which module triggered the error and why.

If you see the failure in ManagedPipelineHandler, your ASP.NET app itself is throwing the error. If it's in StaticFileModule or ProtocolSupportModule, the problem is in IIS's own handling before your app even runs.

HTTP Error 500.19 with sub-status codes like 0x8007000d or 0x80070021 means IIS found your web.config but can't parse or apply it. The error page will show you the exact line number, that's your starting point.

The most common cause: you referenced an IIS module or handler that isn't installed on this machine. For example, if your web.config has:

<add name="RewriteModule" ... />

...but the URL Rewrite 2.1 module isn't installed, IIS refuses to load the entire config. You need to either install the missing module or remove the reference.

To check which modules are currently installed, run this in PowerShell:

Get-WebConfiguration system.webServer/globalModules | 
  Select-Object name

For the URL Rewrite module specifically, download it from the IIS official site and install it. Restart IIS after:

iisreset /restart

Another common 500.19 trigger: incorrect XML in web.config. Run this quick validation in PowerShell to catch malformed XML before IIS does:

[xml](Get-Content "C:\inetpub\wwwroot\YourApp\web.config")

If PowerShell throws a terminating error, it's bad XML. The error message will include the line and character position. Common culprits are unescaped ampersands in connection strings (& must be written as & in XML), unclosed tags, and copy-pasted smart quotes instead of straight quotes.

Sub-status 0x80070021 specifically means "This configuration section cannot be used at this path." That happens when a section is locked at the server level. Fix it by unlocking it in IIS Manager: navigate to the server root (not your site) → Configuration Editor → find the locked section → click Unlock Section in the right panel. Alternatively, at the server level in applicationHost.config, change overrideModeDefault="Deny" to overrideModeDefault="Allow" for the relevant section.

When the fix works, IIS will load your site normally. If you still see a 500.19, compare your web.config against a known-good minimal config and add sections back one at a time to isolate the problem element.

This is the single most common category of IIS problem for developers moving from IIS Express to full IIS. Your app pool runs as a built-in account, either ApplicationPoolIdentity (the default, and the right choice), NETWORK SERVICE, or LOCAL SERVICE. When the folders your app needs to read, write, or execute aren't accessible to that account, you get 500.0, 503.7, or, the most confusing one, a silent blank page.

First, confirm which identity your app pool is using. In IIS Manager, click Application Pools, select your pool, then Advanced Settings in the right panel. Look at Identity under Process Model.

If it's ApplicationPoolIdentity, the actual Windows account name is IIS AppPool\YourAppPoolName. To grant your app folder access, open a Command Prompt as Administrator and run:

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

That grants Read & Execute recursively. If your app writes files (logs, uploads, temp files), grant Modify on those specific subdirectories:

icacls "C:\inetpub\wwwroot\YourApp\logs" /grant "IIS AppPool\YourAppPoolName":(OI)(CI)M /T

Don't just give IIS_IUSRS full control on everything, that's the lazy fix and it creates a real security gap. Be specific about which folders need write access.

Also check the Load User Profile setting in your app pool's Advanced Settings. Some apps require the user profile to be loaded (it provides access to the TEMP and TMP environment variables). Set it to True if your app is crashing on startup trying to access a temp path.

To verify the fix worked: open Event Viewer (eventvwr.msc), navigate to Windows Logs → Security, and look for Event ID 4656 or 5145 with "Access Denied" in the description. If those are gone after your permission change, you've solved it.

If your app is built on .NET Core or .NET 5+, IIS doesn't run it natively, it uses the ASP.NET Core Module (ANCM) as a proxy. When ANCM can't start your app process, you get a 500.30 (ANCM In-Process Start Failure), 500.31 (ANCM Failed to Find Native Dependencies), or 500.32 (ANCM Failed to Load dll). These are among the most opaque IIS errors because the real error is happening in your app's startup code, not in IIS itself.

First, check whether the correct .NET runtime is installed on the server:

dotnet --list-runtimes

You need to see a runtime version that matches or exceeds what your app targets. If it's missing, download and install the correct .NET Hosting Bundle (not just the Runtime, the Hosting Bundle includes the ANCM module). After installation:

iisreset /restart

If the runtime is present but you're still getting 500.30, the failure is in your app's startup code. The fastest way to see the real error is to temporarily enable stdout logging. In your web.config, find the aspNetCore element and set:

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

Create the logs folder manually and grant the app pool identity write access on it. Then reproduce the error and check the stdout_xxxxxxxx.log file, it will contain the full exception from your app's Program.cs startup, including missing environment variables, failed database connections, or misconfigured services.

One specific gotcha: if you're using In-Process hosting (hostingModel="inprocess"), your app pool must be set to No Managed Code under the Managed Pipeline Mode. If it's set to an actual .NET CLR version, ANCM will conflict with it. Fix it in IIS Manager → Application Pools → your pool → Basic Settings → set .NET CLR Version to No Managed Code.

When everything's correct, your app will start and the 500.30 disappears. Remember to set stdoutLogEnabled="false" again, leaving it on fills your disk with log files surprisingly fast.

When IIS doesn't know what to do with a request, because no handler is mapped to that file extension or path, it returns a 404 even if the file physically exists. Or it returns 500.21 ("Handler 'PageHandlerFactory-Integrated' has a bad module 'ManagedPipelineHandler'"), which sounds alarming but usually means ASP.NET isn't registered properly with IIS.

To fix the classic ASP.NET registration issue, run this from an elevated Command Prompt. Find your ASP.NET version first:

dir /b C:\Windows\Microsoft.NET\Framework64\

Then register it with IIS:

C:\Windows\Microsoft.NET\Framework64\v4.0.30319\aspnet_regiis.exe -iru

Follow it with:

iisreset /restart

For handler mapping issues more broadly, go to IIS Manager, select your site, and double-click Handler Mappings. Check that there's an entry that covers your file type. For an ASP.NET MVC or Web API app with extensionless URLs, you need the ExtensionlessUrlHandler-Integrated-4.0 entry to be present and mapped to *. (asterisk dot). If it's missing, you can add it back via PowerShell:

Add-WebConfiguration -Filter "system.webServer/handlers" `
  -PSPath "IIS:\Sites\YourSiteName" `
  -Value @{
    name="ExtensionlessUrlHandler-Integrated-4.0"
    path="*."
    verb="GET,HEAD,POST,DEBUG"
    type="System.Web.Handlers.TransferRequestHandler"
    resourceType="Unspecified"
    requireAccess="Script"
    preCondition="integratedMode,runtimeVersionv4.0"
  }

For PHP apps, handler conflicts are common when both PHP and ASP.NET handlers are active. Open Handler Mappings, sort by Path, and look for duplicate entries matching *.php. Remove any that point to the wrong FastCGI executable. Check that your PHP handler points to the correct php-cgi.exe path for your installed PHP version.

After adjusting handler mappings, always do an iisreset /restart and test with a simple static file first to confirm IIS itself is responding, then test your dynamic content.