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:
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.