Common ASP.NET Core IIS Deployment Issues and Fixes

Deploying an ASP.NET Core application to IIS is usually a straightforward process. However, when something goes wrong, the error messages can often be misleading. During one of my recent deployments of a .NET 10 Web API on Windows Server 2022, I encountered multiple issues that initially pointed towards a missing Hosting Bundle. After spending several hours troubleshooting, I realized the actual problem wasn't just one thing—it could have been any one of several configuration issues.

In this article, I'll walk you through the exact troubleshooting process I followed. Whether you're facing HTTP Error 500.19, AspNetCoreModuleV2 errors, Hosting Bundle issues, or your application refuses to load after deployment, this guide will help you identify the root cause step by step.

For reference, here's the environment I was working with:

Windows Server 2022
IIS 10
ASP.NET Core .NET 10 Web API
SQL Server
Visual Studio 2022

The Initial Problem

After publishing my application to IIS, opening the website immediately displayed the following error:

HTTP Error 500.19 - Internal Server Error
Error Code: 0x8007000d

At first, it looked like IIS couldn't read the application's web.config file. In many cases, this error also appears when the ASP.NET Core Hosting Bundle is missing or IIS cannot load the ASP.NET Core Module.

Instead of reinstalling everything immediately, I decided to troubleshoot the problem systematically.

Step 1: Verify the web.config File

The first thing I checked was the web.config file generated during publishing.

For an ASP.NET Core application hosted in IIS, it should look similar to this:

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

I carefully verified:

The DLL name matched the published application.
The XML structure was valid.
The hosting model was correct.
Stdout logging was enabled for troubleshooting.

Everything looked fine, so I moved to the next step.

Step 2: Check Whether the .NET Runtime Was Installed

The Hosting Bundle depends on the correct .NET runtime being installed.

To verify this, I opened Command Prompt and executed:

dotnet --list-runtimes

The output confirmed that both the ASP.NET Core Runtime and the .NET Runtime were installed.

Microsoft.AspNetCore.App 10.0.x
Microsoft.NETCore.App 10.0.x

If these runtimes are missing, your application will never start, regardless of IIS configuration.

Step 3: Verify the ASP.NET Core Hosting Bundle

Next, I checked whether the Hosting Bundle was installed.

Open:

Control Panel
→ Programs and Features

Look for something similar to:

Microsoft .NET 10.x Windows Server Hosting

If it isn't listed, download and install the correct Hosting Bundle for your .NET version from Microsoft.

If it is already installed, continue troubleshooting instead of reinstalling it immediately.

Step 4: Verify the ASP.NET Core Module

The Hosting Bundle installs the IIS module responsible for running ASP.NET Core applications.

Navigate to:

C:\Program Files\IIS\Asp.Net Core Module\V2

Make sure the following file exists:

aspnetcorev2.dll

If this file is missing, IIS won't be able to launch your application.

Step 5: Verify IIS Module Registration

Even if the DLL exists, IIS must register the module correctly.

Run the following command in PowerShell:

& "$env:windir\System32\inetsrv\appcmd.exe" list modules

Look for:

AspNetCoreModuleV2

If you don't see it, repairing or reinstalling the Hosting Bundle usually resolves the issue.

Step 6: Verify the Global Module Registration

Then verified that IIS had registered the module globally.

Open:

C:\Windows\System32\inetsrv\config\applicationHost.config

Search for:

<globalModules>

Inside the XML there will be section, you should find:

<add
    name="AspNetCoreModuleV2"
    image="%ProgramFiles%\IIS\Asp.Net Core Module\V2\aspnetcorev2.dll" />

If this entry is missing, IIS cannot load ASP.NET Core applications.

Step 7: Verify the IIS Website

Sometimes the simplest things are overlooked.

I checked whether my website was actually running.

Import-Module WebAdministration
Get-Website

The website status should be:

Started

If the site is stopped, start it before continuing.

Step 8: Verify the Application Pool

This turned out to be one of the most important checks.

I opened the Application Pool settings and found:

Managed Runtime Version : v4.0

For ASP.NET Core applications, this setting is incorrect.

The Application Pool should be configured as:

.NET CLR Version: No Managed Code
Managed Pipeline: Integrated
Enable 32-Bit Applications: False

Although ASP.NET Core doesn't use the .NET Framework runtime inside IIS, many deployments are still configured incorrectly with v4.0, which often causes confusion.

Step 9: Verify IIS Bindings

Next, I confirmed that the website bindings were correct.

I verified:

HTTP binding
HTTPS binding
Host name
SSL certificate

An incorrect host name or missing SSL certificate can prevent requests from reaching your application.

Step 10: Run the Application Outside IIS

This was probably the most useful step during the entire troubleshooting process.

Instead of relying on IIS, I ran the application directly.

cd C:\inetpub\wwwroot\YourApplication
dotnet YourApplication.dll

The application started successfully.

Starting Application...
Application started successfully.

This immediately told me that the application itself was healthy and that the problem was somewhere in IIS rather than the application code.

Whenever you're troubleshooting deployment issues, this should be one of the first tests you perform.

Step 11: Enable Stdout Logging

If the application fails to start inside IIS, enable stdout logging temporarily.

stdoutLogEnabled="true"

After making a request, check the generated log files inside:

logs

These logs often contain the exact exception that caused the application to fail.

Remember to disable stdout logging once the issue has been resolved.

Step 12: Check Event Viewer

Windows Event Viewer provides valuable information when IIS fails to launch an application.

Navigate to:

Event Viewer
→ Windows Logs
→ Application

Look for errors related to:

IIS AspNetCore Module V2
IIS-W3SVC-WP
.NET Runtime

These events often reveal missing dependencies or startup exceptions.

Step 13: Test a Health Check Endpoint

Instead of opening the root URL, I tested my Health Check endpoint.

https://yourdomain.com/health

The response was:

Healthy

This single response confirmed that:

IIS was working correctly.
The Hosting Bundle was installed correctly.
ASP.NET Core Module was working.
HTTPS was configured properly.
The application had started successfully.

Health Check endpoints are extremely useful when validating deployments.

Step 14: Test the Application with cURL or PowerShell

You can also verify your deployment without opening a browser.

Using Command Prompt:

curl https://yourdomain.com/health

Or PowerShell:

Invoke-WebRequest https://yourdomain.com/health

Receiving a 200 OK response confirms that IIS is successfully forwarding requests to your application.

Step 15: Verify Swagger Configuration

One thing that often confuses developers is Swagger returning a 404 Not Found error.

In my case, Swagger was only enabled for Development and Staging environments.

if (app.Environment.IsDevelopment() || app.Environment.IsStaging())
{
    app.UseSwagger();
    app.UseSwaggerUI();
}

When deployed to Production, /swagger naturally returned 404.

This wasn't a deployment problem—it was simply how the application was configured.

Step 16: Verify the Root Endpoint

Another thing I discovered was that visiting the root URL returned 404 Not Found.

Initially, I thought the deployment had failed.

However, after reviewing my application, I realized I hadn't mapped an endpoint for /.

My application only exposed:

Controllers
Health Checks
SignalR Hub

Since there was no route for /, ASP.NET Core correctly returned 404.

Adding a simple root endpoint solved this.

app.MapGet("/", () =>
{
    return Results.Ok(new
    {
        Application = "My API",
        Status = "Running"
    });
});

Step 17: Verify the Published Files

Before blaming IIS, make sure the publish folder contains all required files.

A standard ASP.NET Core publish output should include:

Application DLL
.deps.json
.runtimeconfig.json
web.config
appsettings.json

Missing files can prevent the application from starting correctly.

Step 18: Verify Database Connectivity

Many applications execute database migrations or seed data during startup.

If the SQL Server is unavailable, the connection string is incorrect, or the credentials are invalid, the application may fail before it even starts serving requests.

Always verify your database connectivity as part of deployment troubleshooting.

Complete Troubleshooting Checklist

Before concluding that the Hosting Bundle is the problem, verify the following:

Check	Status
IIS Website Started	success
Application Pool Started	success
Application Pool uses No Managed Code	success
.NET Runtime Installed	success
ASP.NET Core Hosting Bundle Installed	success
AspNetCoreModuleV2 Installed	success
IIS Global Module Registered	success
web.config Valid	success
Published Files Complete	success
Application Starts with dotnet YourApplication.dll	success
Stdout Logs Checked	success
Event Viewer Checked	success
Database Connectivity Verified	success
Health Endpoint Working	success
HTTPS Binding Verified	success
SSL Certificate Valid	success

The biggest lesson I learned was not to jump straight to reinstalling the Hosting Bundle.

A deployment issue can originate from several different layers, including:

Missing .NET Runtime
Missing Hosting Bundle
Unregistered ASP.NET Core Module
Incorrect Application Pool configuration
Invalid IIS bindings
Startup exceptions
Database connection failures
Missing published files
Environment-specific configuration
Missing application routes

By troubleshooting each layer one at a time, it's much easier to identify the real cause without making unnecessary changes.

Conclusion

Deploying ASP.NET Core applications to IIS doesn't have to be frustrating. Most deployment failures can be resolved by following a structured troubleshooting process rather than guessing or repeatedly reinstalling software.

I hope this guide saves you time the next time you encounter an IIS deployment issue. If you're deploying ASP.NET Core applications regularly, consider bookmarking this checklist—it's a practical reference that can help diagnose almost every common IIS deployment problem before it becomes a lengthy debugging session.