How to Fix HTTP Error 500.30 in ASP.NET Core Applications

Fix HTTP Error 500.30 by finding why the ASP.NET Core process fails during startup. The IIS page is only the symptom. The real cause is almost always in the application logs, Windows Event Viewer, stdout logs, or the console output from running the app manually. Microsoft describes 500.30 as an error returned when the ASP.NET Core Module starts the worker process but the app fails to start properly [source: Microsoft].

What HTTP Error 500.30 Means

HTTP Error 500.30 – ASP.NET Core app failed to start appears when IIS can reach the app entry point, but the .NET application cannot complete startup. That means IIS may be working. Your site binding may be correct. The files may even be deployed. But the app crashes before it can serve a request.

This error often appears after a release, runtime upgrade, hosting change, configuration edit, or database migration. It is annoying because the browser page is vague. It does not tell you if the issue is a missing DLL, bad JSON, broken service registration, or a failed SQL login.

Image not found in postmeta

Start With the Fastest Checks

Before editing code, confirm the basics. Small hosting mistakes cause a surprising number of 500.30 errors.

• Confirm the correct .NET runtime is installed. If the app targets .NET 8, the server needs the correct .NET 8 runtime or Hosting Bundle.
• Check the app pool. For ASP.NET Core on IIS, the application pool should usually be set to No Managed Code.
• Restart the app pool. Old worker processes can hold stale files after deployment.
• Verify file permissions. The app pool identity must be able to read the app folder and write to any required log or upload folders.
• Check web.config. A wrong process path, missing handler, or bad hosting model can stop startup.

If the error started right after publishing, compare the deployed folder with the previous working release. Expect to waste time if you skip this. A missing appsettings.Production.json file can look exactly like a runtime failure from the browser.

Check Windows Event Viewer

On a Windows server, open Event Viewer and check:

• Windows Logs > Application
• Windows Logs > System
• Application and Services Logs, if your hosting setup writes there

Look for entries from IIS AspNetCore Module V2, .NET Runtime, or your application name. These records often show the real exception, such as:

• System.IO.FileNotFoundException
• System.InvalidOperationException
• System.FormatException from invalid JSON
• SqlException from a failed database connection
• Host terminated unexpectedly

The browser page gives you a dead end. Event Viewer usually gives you the first useful clue.

Enable stdout Logging Temporarily

If Event Viewer is not enough, enable stdout logging in web.config. Use this only for troubleshooting, then turn it off. Logs can grow quickly and may expose sensitive data.

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

Create the logs folder if it does not exist. Give the app pool identity write permission to it. Then restart the site and reproduce the error. A new log file should appear.

If no log appears, check folder permissions and the path in web.config. If a log appears, read the first exception carefully. The first exception is usually more useful than the last one.

Run the App Manually on the Server

This is one of the best ways to cut through the noise. Open a command prompt on the server, move to the published app folder, and run:

dotnet YourApp.dll

If the app crashes, the console often prints the exact startup error. That can reveal missing settings, invalid certificates, failed service registration, or bad connection strings.

For a self-contained deployment, run the executable instead:

YourApp.exe

If the app starts in the console but fails in IIS, compare the environments. IIS may use a different identity, different working directory, different environment variables, or different permissions.

Fix Missing Runtime or Hosting Bundle Issues

A common cause of 500.30 is a runtime mismatch. For framework-dependent deployments, the server must have the matching .NET runtime installed. IIS hosting also requires the ASP.NET Core Hosting Bundle.

Run this on the server:

dotnet --info
dotnet --list-runtimes

Compare the output with the target framework in your project file:

<TargetFramework>net8.0</TargetFramework>

If the required runtime is missing, install the correct Hosting Bundle from Microsoft [source: .NET downloads]. After installation, restart IIS:

iisreset

Do not assume the server is current because another .NET app works there. One app may target .NET 6 while the failing app targets .NET 8.

Inspect Configuration and Environment Variables

Bad configuration is a frequent startup killer. ASP.NET Core reads settings from several places, including JSON files, environment variables, user secrets in development, and command-line arguments. Production may not match your local machine.

Check these items:

• Invalid JSON in appsettings.json or appsettings.Production.json.
• Missing connection strings or renamed keys.
• Wrong ASPNETCORE_ENVIRONMENT value.
• Missing API keys needed during startup.
• Certificate paths that exist locally but not on the server.

A tiny JSON mistake can stop the whole app. For example, a trailing comma in the wrong place may work nowhere and fail before logging is fully ready.

Review Program.cs and Dependency Injection

Many 500.30 errors come from startup code. In modern ASP.NET Core apps, most of that code is in Program.cs. Look for services that run too early or fail while being registered.

Common examples include:

• Calling the database during service registration.
• Loading a missing file during startup.
• Registering a service with a missing dependency.
• Using BuildServiceProvider() in the wrong place.
• Throwing an exception inside custom middleware setup.

If you recently added a service, comment it out and redeploy to confirm. That is not a final fix, but it narrows the search fast.

Check Database Access and Migrations

Database failures are easy to miss. The app may start locally because your account has access, then fail on the server because the production identity does not. If your startup code applies migrations automatically, a failed migration can trigger 500.30 before the first request.

Verify:

• The server can reach the database host and port.
• The connection string points to the correct database.
• The SQL login is valid.
• The account has the required permissions.
• Migrations do not depend on missing tables, schemas, or extensions.

When Hosting in Azure App Service

For Azure App Service, use Log stream, Application logs, and Diagnose and solve problems. Also check configuration under Environment variables. A setting that exists in local development but not in Azure can break startup instantly.

If you deploy with GitHub Actions, Azure DevOps, or ZIP deploy, confirm that the final artifact contains the expected files. A publish profile change can silently alter the output folder. Honestly, it feels like the deployment succeeded just enough to mislead you.

A Practical Fix Order

1. Read Event Viewer or Azure logs.
2. Enable stdout logging briefly.
3. Run the app manually with dotnet YourApp.dll.
4. Check installed runtimes with dotnet --list-runtimes.
5. Validate configuration files and environment variables.
6. Review recent changes in Program.cs and service registration.
7. Test database connectivity from the server.
8. Restart IIS or the app service after fixes.

The reliable fix is not to guess. HTTP Error 500.30 means the app failed during startup, so the fastest path is to expose the startup exception. Once you have that exception, the repair is usually direct: install the right runtime, correct configuration, fix permissions, repair dependency injection, or restore database access.