I recently hit this error after migrating an application from classic ASP.NET (.NET Framework) to ASP.NET Core on IIS.

Instead of loading the site, IIS displayed the dreaded:

HTTP Error 500.30 – ASP.NET Core app failed to start

The page listed the usual Microsoft suggestions:

• The app failed to start
• The app started but then stopped
• The app started but threw an exception during startup

Along with the standard troubleshooting advice:

• Check the Windows Event Log
• Enable stdout logging
• Attach a debugger

While all of these are valid, they can send you down a fairly deep rabbit hole.

In my case, the fix was incredibly simple.

---

The Fix

Open IIS Manager and check the Application Pool used by your site.

The settings should normally be:

Setting	Value
.NET CLR Version	No Managed Code
Managed Pipeline Mode	Integrated

That was it.

Because the website had previously been hosted as a classic ASP.NET application, the Application Pool was still configured for the .NET Framework.

ASP.NET Core works differently.

Although your application is written in C#, IIS is no longer hosting it inside the old .NET Framework CLR. Instead, IIS launches the application through the ASP.NET Core Module, which then starts the .NET runtime.

For that reason, No Managed Code is normally the correct setting.

---

What HTTP Error 500.30 Actually Means

This error generally means:

• IIS is working.
• IIS has located your website.
• The ASP.NET Core Module has attempted to launch the application.
• The application failed during startup.

So IIS itself isn’t necessarily broken—the application simply couldn’t start.

---

First Thing to Check: Application Pool Settings

Open:

IIS Manager → Application Pools

Locate the Application Pool used by your website.

Right-click it and choose:

Basic Settings

Verify the following:

.NET CLR Version:
    No Managed Code

Managed Pipeline Mode:
    Integrated

If you’ve spent years deploying ASP.NET MVC or Web Forms applications, this can feel counterintuitive because those applications typically used:

.NET CLR Version:
    v4.0

Managed Pipeline Mode:
    Integrated

ASP.NET Core is different.

---

Why This Often Happens During a Migration

When replacing an older ASP.NET Framework application with ASP.NET Core, IIS often reuses the existing Application Pool.

That old pool might still look like this:

.NET CLR Version:
    v4.0

Managed Pipeline Mode:
    Integrated

Once the application becomes ASP.NET Core, it should generally be:

.NET CLR Version:
    No Managed Code

Managed Pipeline Mode:
    Integrated

It is a tiny setting that is surprisingly easy to overlook.

---

Other Simple Things to Check

1. Is the .NET Hosting Bundle Installed?

Open PowerShell and run:

dotnet --list-runtimes

For a .NET 8 application you should see something similar to:

Microsoft.AspNetCore.App 8.0.x
Microsoft.NETCore.App 8.0.x

If Microsoft.AspNetCore.App is missing, install the correct ASP.NET Core Hosting Bundle for your application’s version.

---

2. Is AspNetCoreModuleV2 Installed?

Open:

IIS Manager → Server → Modules

Look for:

AspNetCoreModuleV2

If it isn’t present, the Hosting Bundle was either never installed or failed during installation.

---

3. Check web.config

Open the published site’s web.config.

For a framework-dependent deployment you’ll usually see something like:

<aspNetCore processPath="dotnet"
            arguments=".\YourApp.dll" />

Verify that:

• YourApp.dll actually exists
• The filename matches exactly
• web.config is in the published root folder

For self-contained deployments you’ll instead see an executable:

<aspNetCore processPath=".\YourApp.exe" />

Again, confirm the executable exists.

---

4. Run the Application Manually

This is one of the quickest ways to uncover the real error.

Open PowerShell:

cd C:\inetpub\wwwroot\YourApp

Then run:

dotnet .\YourApp.dll

or for a self-contained deployment:

.\YourApp.exe

If startup fails, you’ll often see the actual exception immediately.

Examples include:

• Missing runtime
• Invalid appsettings.json
• Database login failures
• Dependency Injection errors
• Missing certificates
• Azure Key Vault authentication failures
• Permission issues

This is usually far more useful than the browser’s generic 500.30 error.

---

5. Check Event Viewer

Open:

Event Viewer → Windows Logs → Application

Look for recent errors from:

• IIS AspNetCore Module V2
• .NET Runtime
• Application Error

You can also search using PowerShell:

Get-WinEvent -LogName Application -MaxEvents 100 |
Where-Object {
    $_.ProviderName -like "AspNetCore*" -or
    $_.ProviderName -like ".NET Runtime" -or
    $_.ProviderName -like "Application Error"
} |
Select TimeCreated, ProviderName, Id, LevelDisplayName, Message |
Format-List

---

6. Enable stdout Logging (Temporarily)

In web.config, change:

stdoutLogEnabled="false"

to

stdoutLogEnabled="true"

Create a logs folder:

mkdir C:\inetpub\wwwroot\YourApp\logs

Grant the Application Pool write permissions:

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

Recycle the Application Pool and browse to the site again.

A file such as:

stdout_*.log

should appear.

Don’t forget to disable stdout logging once you’re finished, otherwise the log files can grow quickly.

---

7. Check the Environment

ASP.NET Core loads configuration based on:

ASPNETCORE_ENVIRONMENT

For example:

appsettings.json
appsettings.Development.json
appsettings.UAT.json
appsettings.Production.json

If IIS is running under the wrong environment, your application may load:

• Incorrect connection strings
• Missing configuration values
• Wrong API endpoints
• Different Azure Key Vault settings

---

8. Check Database Permissions

One of the most common startup failures is a database authentication error.

For example:

Cannot open database requested by the login.

Login failed for user...

This often occurs because you’re testing the application under your own account:

DOMAIN\YourUser

while IIS runs as:

IIS AppPool\YourAppPool

or

DOMAIN\ServiceAccount

Your SQL Server may trust your personal account but not the Application Pool identity.

---

My HTTP Error 500.30 Checklist

Whenever I see this error, I now work through this list:

• ✅ Application Pool is using No Managed Code
• ✅ Pipeline mode is Integrated
• ✅ Correct .NET Hosting Bundle installed
• ✅ AspNetCoreModuleV2 exists
• ✅ web.config points to the correct DLL or EXE
• ✅ Application starts manually from PowerShell
• ✅ Event Viewer checked
• ✅ stdout logging enabled (temporarily)
• ✅ ASPNETCORE_ENVIRONMENT is correct
• ✅ Database, file system, certificate, and Key Vault permissions verified

---

Final Thoughts

The wording of HTTP Error 500.30 makes it sound like something catastrophic has happened deep inside your application.

Sometimes that’s true.

However, if you’ve recently migrated from classic ASP.NET to ASP.NET Core, I’d start by checking the Application Pool settings before diving into logs and debugging.

In my case, changing just two settings solved the problem:

.NET CLR Version:
    No Managed Code

Managed Pipeline Mode:
    Integrated

A simple fix—but one that can save hours of troubleshooting.