HTTP Error 500.30 means an ASP.NET Core application failed during in-process startup under IIS. The browser page identifies the stage that failed, but usually does not show the exception that caused it. That exception might involve configuration, a dependency, file access or a service the app contacts while starting.
I would first capture the startup error on the server, then apply the fix it supports. Repeatedly recycling the application pool or clearing browser cache will not correct a missing connection string or a failing service constructor.
This guide covers IIS on Windows and Windows-based Azure App Service. A visitor without server access should report the error and affected URL to the site owner; the meaningful checks require access to the application or its hosting environment.
Find the exception behind the 500.30 page
Before changing configuration, note when the problem began and preserve the current deployment and settings. A failure immediately after publishing deserves comparison with the last working deployment.
On an IIS server, open Event Viewer > Windows Logs > Application. Reproduce the failure once, then inspect events at that time, particularly ASP.NET Core Module and .NET Runtime entries. Read the exception and any inner exception rather than stopping at “failed to start.”
A message about resolving a service, opening a file or reaching a database gives you a more specific direction. Keep full logs private: they can contain paths, account details and configuration information.
Temporarily capture stdout output
If the event entry is incomplete, back up the deployed web.config. Within its existing aspNetCore element, temporarily set these attributes:
stdoutLogEnabled="true"
stdoutLogFile=".\logs\stdout"These are attributes, not a complete replacement configuration file. Preserve the existing processPath, arguments, hostingModel and other deployment settings. Create or select a dedicated log directory that the application pool identity can write to.
Request the application once, then inspect the newest stdout log and its first meaningful exception. If no file appears, check the configured path, write permissions and Event Viewer. The absence of a log is not proof that the application has no startup exception.
After collecting the error, set stdoutLogEnabled="false" again. These diagnostic files do not provide normal log rotation and can consume disk space. Microsoft explains the attributes and logging permissions in its ASP.NET Core Module logging guide.
Run the published app on the server as a comparison
For a framework-dependent deployment, open a command prompt in the published application directory and run the actual application DLL:
cd /d C:\Sites\MyApp
dotnet MyApp.dllReplace both example names. For a deployment published with an executable, use the executable appropriate to that deployment instead. Do this in an appropriate maintenance or test context: starting the app can run startup migrations, scheduled work or other application code.
If an exception appears, capture it before changing anything. If the app starts, stop the test process normally when finished.
A successful console launch does not prove IIS is configured correctly. Your interactive account can have different permissions, environment variables, certificate access and network credentials from the application pool identity. Compare those differences rather than declaring the error solved.
Match the message to the repair
The examples below are illustrative exception patterns, not logs captured from your server.
“Unable to resolve service for type…”
This points toward dependency injection. Check the service registration and constructor named in the exception. A registration might be missing, conditionally excluded in Production, or dependent on another service that was never registered.
Inspect the startup code in Program.cs and the relevant registration extension methods. Fix the missing or invalid registration, publish again and verify startup. Installing another runtime is not a targeted repair for a clearly identified dependency-registration error.
Microsoft’s dependency injection documentation describes how services are registered and resolved.
A missing setting, invalid JSON or connection-string exception
Compare the effective server configuration with the working environment. Check that required configuration files were published, JSON is valid, the intended environment is selected and production secrets are supplied through the configured provider.
Settings stored in your development machine’s user secrets are not automatically deployed as production secrets. Under the default configuration, environment variables can override JSON settings. Hierarchical keys commonly use a double underscore, such as ConnectionStrings__MainDatabase.
Verify the key name and value in the server’s approved configuration system. Do not paste secrets into public error pages or switch a public deployment to Development just to expose an exception. See Microsoft’s configuration provider guidance.
Database login failure, timeout or unavailable external service
A database problem can produce a startup failure when your startup code opens a connection, applies migrations or requires database-backed configuration. It does not follow that every 500.30 is database-related.
Check the named dependency using the deployed identity and network path. Investigate credentials, DNS, firewall access and service availability as indicated by the exception. If startup migrations failed, inspect the migration error and deployment process before rerunning them.
“Access denied” or a file/certificate cannot be opened
Identify the exact resource and the account IIS uses. Grant only the access that resource requires. For a local application pool identity, the account name typically follows IIS AppPool\YourPoolName.
The app generally needs read and execute access to its files, with write access limited to locations it actually writes to. A certificate may require private-key permission, not merely access to a folder.
Do not grant Everyone Full Control across the site or run the pool as an administrator to suppress the error. If the console test worked only under an administrator account, that difference is useful diagnostic evidence.
Check the runtime and Hosting Bundle when the error points there
For framework-dependent publishing, inspect the deployed MyApp.runtimeconfig.json and list the server’s installed shared frameworks:
dotnet --list-runtimesCompare the required framework and version with what is installed. An ASP.NET Core application can need the ASP.NET Core shared framework as well as the base .NET runtime. Installing an SDK on your development PC does not install the server prerequisites.
For IIS, check the appropriate .NET Hosting Bundle. If it was installed before IIS, Microsoft says to repair the bundle after IIS installation. Follow the installer’s restart instructions during a suitable maintenance window.
A self-contained deployment carries its .NET runtime but still needs the IIS hosting integration. Also compare the published architecture with the worker process and native dependencies.
Do not treat 500.30, 500.31 and 500.32 as interchangeable. Related runtime-loading or architecture failures can have their own ANCM status codes. Read the exact current error and its logs before deciding which component to install.
Check what you actually published
Confirm that the IIS site points to the publish output, rather than the source directory or an old build folder. Check that the DLL or executable named in web.config exists and belongs to the same deployment as its configuration and dependency files.
Republish a coherent build if files were partially copied or mixed between releases. Preserve uploads and environment-specific data before replacing deployment contents. Do not delete the site directory indiscriminately.
I would not change the hosting model to out-of-process as a universal fix. A different host can change the symptom while leaving the application’s startup exception unresolved.
Diagnose 500.30 on Azure App Service
For a Windows App Service, start with the app’s Diagnose and solve problems area and the logs available for the failed startup. Use Advanced Tools to open Kudu when available, then inspect the deployed application and diagnostic output.
Compare the configured runtime stack, platform architecture, application settings and connection strings with the deployment. Check the correct deployment slot; settings can differ between staging and production.
If temporary stdout logging is needed, preserve the existing Azure-generated web.config and its log path. Microsoft’s procedure uses Kudu to edit the deployed configuration and inspect startup output. Disable the diagnostic logging once you have the exception. Deployments that run from a read-only package may require making the change in the deployment artifact instead.
A blank Log stream is not conclusive: output depends on the application’s logging and the platform settings. Microsoft’s IIS and Azure troubleshooting reference explains the available diagnostic routes.
Verify the correction under the real hosting identity
After one evidence-based change, start or recycle the affected application as appropriate and request it again. Verify more than the homepage: test a representative endpoint and the dependency involved in the original exception.
Check fresh logs, restore temporary diagnostic settings and verify behaviour after another controlled restart. If the app starts only after you manually launch it as yourself, the hosting configuration or identity difference still needs investigation.
The useful fix for HTTP Error 500.30 is the one that removes the underlying startup exception. Once you have that exception, the problem becomes a specific deployment, configuration or application repair instead of a guessing exercise around an HTTP status code.
