For an ASP.NET Core application that will not start on IIS, use the complete error code to choose the first investigation. A 500.30 indicates an in-process startup failure; a 500.31 identifies failure to find native dependencies, commonly a missing required runtime. The application event and startup exception must establish the actual cause.1
Do not start by reinstalling everything or repeatedly recycling the application pool. Preserve the failing deployment and its first useful startup evidence so a correction can be tied to a specific mismatch or exception.
This article uses Microsoft's ASP.NET Core 10.0 documentation view for Windows IIS. Match its guidance to the deployed runtime and hosting mode.
Identify the deployment that IIS is trying to start
Record the site, application, application pool, physical path and deployment identifier. Confirm that the reported error belongs to that application, especially on a server hosting several sites.
Then identify the hosting model and publish mode. In-process hosting loads the application within the IIS worker process. Framework-dependent and self-contained deployments have different runtime packaging expectations. These distinctions must be established from the deployed artefacts and configuration, not the developer's recollection.2
Keep a sanitised copy of the relevant configuration and deployment manifest for comparison. Preserve paths and filenames needed for diagnosis without copying credentials, connection strings or secret environment values into the ticket.
A successful local development run is useful context but not a reproduction of the IIS environment. The identity, installed components, architecture, configuration and filesystem access may differ.
Use 500.30 as a starting category
Microsoft describes 500.30 as an in-process startup failure and directs investigation to the Application Event Log and ASP.NET Core Module stdout logging. The category can include application configuration and required-framework problems; it is not a single root cause.1
Read the earliest relevant exception and its inner exception. An outer message saying the process failed is less specific than a missing configuration value, unavailable dependency or access denial recorded underneath it.
Connect the exception to a startup operation. If startup requires access to a configuration service or another dependency, identify the identity and permission boundary actually used by the IIS process. Do not assume the administrator's successful interactive access proves application access.
A hypothetical application may start locally because a developer has a credential unavailable to the pool identity. The evidence would support correcting the intended identity configuration, not granting broad filesystem or server permissions indiscriminately.
Use 500.31 to compare requirements with installed components
For 500.31, Microsoft identifies a missing Microsoft.NETCore.App or Microsoft.AspNetCore.App runtime as a common cause. Preserve the exact missing-framework message, including version and architecture, before selecting an installation or publish change.1
Compare the application's runtime requirements and publish mode with the target server's installed runtimes. An installed SDK is not the whole IIS-hosting configuration, and a list from the wrong architecture or executable path can mislead.
The .NET Hosting Bundle supplies components for IIS integration, including the ASP.NET Core Module. Microsoft's hosting documentation also records an installation-order issue: if the bundle was installed before IIS, its installation must be repaired after IIS is installed.2
Treat that as a documented condition to verify from the server's history. It does not justify repairing the bundle on every 500.31 incident. A precise missing-runtime finding should lead to a supported deployment decision for that application.
Microsoft lists three options: install the required supported runtime, retarget and rebuild for a supported installed runtime, or publish self-contained. Select the option that fits the application's support and deployment requirements; self-contained publishing does not remove IIS integration and architecture checks.1, 2
Do not collapse neighbouring error codes together
Microsoft documents 500.32 separately for failure to load the DLL, commonly involving incompatible process architecture. It also distinguishes startup time-limit failures and out-of-process failures from 500.30 and 500.31.1
Record the exact code instead of shortening all of them to “500”. Architecture belongs in the evidence checklist, but an architecture mismatch should not be asserted solely because a startup error occurred.
Check the deployed target architecture, the application pool's 32-bit setting and required native dependencies together. A framework-dependent application and a self-contained publication can expose different mismatches.
Changing the application pool's architecture is an operational modification. Assess other applications and native components using that pool before treating the setting as a harmless toggle.
Use existing event evidence first
The Application Event Log can provide the module's startup failure and associated process information. Match its timestamp and application path to the request that failed. Save the relevant event detail before repeated attempts bury it among later messages.1
If there is no useful event, record that absence and the period examined. It does not prove that startup succeeded. Some failures need another supported diagnostic source.
A compact incident record should separate the visible HTTP error, the module's event and the application's inner exception. These are related layers of evidence, not interchangeable explanations.
Also preserve the last known working deployment identifier and the changes made since then. A package comparison is more useful when it is tied to an exact build and configuration rather than a directory timestamp alone.
Bound stdout logging and protect its contents
ASP.NET Core Module stdout logging can expose useful startup errors that are absent from the event log. Microsoft warns that these logs have no built-in limit on file size or file count and should be disabled after the startup investigation.1
Before an approved capture, define the destination, required write access, free capacity, capture window and cleanup owner. Failure to create a log can reflect a path or permission problem; it is not proof that the application emitted no error.
Restrict access because startup output may include configuration or dependency details. Do not publish a raw log in a public support thread. Retain only the evidence required under the organisation's handling rules.
This article deliberately provides no logging-enablement configuration to paste into production. A bounded, reviewed change is required for the actual deployment. Routine application logging should use an appropriate managed logging configuration, not permanent startup stdout capture.
A console run changes the experiment
Microsoft describes running the application from a command prompt as a way to expose startup errors. That can be valuable, but it uses a different execution context unless deliberately controlled.1
Starting the application can also execute its startup work. Before doing so, the application owner must establish whether startup invokes jobs, migrations or external operations. This article does not authorise a second live instance merely for diagnosis.
If a controlled reproduction succeeds outside IIS, compare identities, environment, working paths and hosting configuration. If it fails with the same exception, the matching error strengthens the application or deployment hypothesis.
Do not expose a production application in Development mode to obtain detailed browser errors. Microsoft limits that recommendation to staging and testing servers not exposed to the internet.1
Verify the corrected startup and the service
After an approved correction, verify startup under the intended IIS identity and deployment mode. Confirm that the original error no longer appears and that the application completes its necessary initialisation.
Then perform an approved functional check through the real application route. A process that starts but cannot access its required dependency is not a completed recovery. Check that temporary diagnostic settings are removed and evidence retained safely.
The closure statement should name the mismatch or exception, the layer corrected and the observed application outcome. “Hosting Bundle repaired” describes an action; the startup and functional evidence establish whether it solved the incident.
Learning notes
- 500.30 and 500.31 narrow the investigation but do not replace the underlying exception.
- Runtime requirements, publish mode and architecture must match the actual IIS environment.
- Temporary startup logs need a bounded capture and cleanup plan.
- Successful startup and successful application operation are separate checks.
Acceptance checklist
- [ ] The full startup error and deployed runtime, architecture and hosting mode are recorded.
- [ ] The selected correction addresses the evidenced mismatch or exception.
- [ ] Startup and dependency access succeed under the intended IIS identity.
- [ ] The real application route passes checks and temporary diagnostics are removed safely.
References
- Troubleshoot ASP.NET Core on Azure App Service and IIS | Microsoft Learn. Accessed 2026-11-01.
- Host ASP.NET Core on Windows with IIS | Microsoft Learn. Accessed 2026-11-01.