Troubleshoot ASP.NET Core on Azure App Service and IIS

This article provides information on common app startup errors and instructions on how to diagnose errors when an app is deployed to Azure App Service or IIS:

App startup errors
Explains common startup HTTP status code scenarios.

Troubleshoot on Azure App Service
Provides troubleshooting advice for apps deployed to Azure App Service.

Troubleshoot on IIS
Provides troubleshooting advice for apps deployed to IIS or running on IIS Express locally. The guidance applies to both Windows Server and Windows desktop deployments.

Clear package caches
Explains what to do when incoherent packages break an app when performing major upgrades or changing package versions.

Additional resources
Lists additional troubleshooting topics.

App startup errors

In Visual Studio, the ASP.NET Core project default server is Kestrel. Visual studio can be configured to use IIS Express. A 502.5 - Process Failure or a 500.30 - Start Failure that occurs when debugging locally with IIS Express can be diagnosed using the advice in this topic.

403.14 Forbidden

The app fails to start. The following error is logged:

The Web server is configured to not list the contents of this directory.

The error is usually caused by a broken deployment on the hosting system, which includes any of the following scenarios:

• The app is deployed to the wrong folder on the hosting system.
• The deployment process failed to move all of the app's files and folders to the deployment folder on the hosting system.
• The web.config file is missing from the deployment, or the web.config file contents are malformed.

Perform the following steps:

1. Delete all of the files and folders from the deployment folder on the hosting system.
2. Redeploy the contents of the app's publish folder to the hosting system using your normal method of deployment, such as Visual Studio, PowerShell, or manual deployment:
   • Confirm that the web.config file is present in the deployment and that its contents are correct.
   • When hosting on Azure App Service, confirm that the app is deployed to the D:\home\site\wwwroot folder.
   • When the app is hosted by IIS, confirm that the app is deployed to the IIS Physical path shown in IIS Manager's Basic Settings.
3. Confirm that all of the app's files and folders are deployed by comparing the deployment on the hosting system to the contents of the project's publish folder.

For more information on the layout of a published ASP.NET Core app, see ASP.NET Core directory structure. For more information on the web.config file, see ASP.NET Core Module (ANCM) for IIS.

500 Internal Server Error

The app starts, but an error prevents the server from fulfilling the request.

This error occurs within the app's code during startup or while creating a response. The response may contain no content, or the response may appear as a 500 Internal Server Error in the browser. The Application Event Log usually states that the app started normally. From the server's perspective, that's correct. The app did start, but it can't generate a valid response. Run the app at a command prompt on the server or enable the ASP.NET Core Module stdout log to troubleshoot the problem.

This error also may occur when the .NET Core Hosting Bundle isn't installed or is corrupted. Installing or repairing the installation of the .NET Core Hosting Bundle (for IIS) or Visual Studio (for IIS Express) may fix the problem.

500.0 In-Process Handler Load Failure

The worker process fails. The app doesn't start.

An unknown error occurred loading ASP.NET Core Module components. Take one of the following actions:

• Contact Microsoft Support (select Developer Tools then ASP.NET Core).
• Ask a question on Stack Overflow.
• File an issue on our GitHub repository.

500.30 In-Process Startup Failure

The worker process fails. The app doesn't start.

The ASP.NET Core Module attempts to start the .NET Core CLR in-process, but it fails to start. The cause of a process startup failure can usually be determined from entries in the Application Event Log and the ASP.NET Core Module stdout log.

Common failure conditions:

• The app is misconfigured due to targeting a version of the ASP.NET Core shared framework that isn't present. Check which versions of the ASP.NET Core shared framework are installed on the target machine.
• Using Azure Key Vault, lack of permissions to the Key Vault. Check the access policies in the targeted Key Vault to ensure that the correct permissions are granted.

500.31 ANCM Failed to Find Native Dependencies

The worker process fails. The app doesn't start.

The ASP.NET Core Module attempts to start the .NET Core runtime in-process, but it fails to start. The most common cause of this startup failure is when the Microsoft.NETCore.App or Microsoft.AspNetCore.App runtime isn't installed. If the app is deployed to target ASP.NET Core 3.0 and that version doesn't exist on the machine, this error occurs. An example error message follows:

The specified framework 'Microsoft.NETCore.App', version '3.0.0' was not found.
  - The following frameworks were found:
      2.2.1 at [C:\Program Files\dotnet\x64\shared\Microsoft.NETCore.App]
      3.0.0-preview5-27626-15 at [C:\Program Files\dotnet\x64\shared\Microsoft.NETCore.App]
      3.0.0-preview6-27713-13 at [C:\Program Files\dotnet\x64\shared\Microsoft.NETCore.App]
      3.0.0-preview6-27714-15 at [C:\Program Files\dotnet\x64\shared\Microsoft.NETCore.App]
      3.0.0-preview6-27723-08 at [C:\Program Files\dotnet\x64\shared\Microsoft.NETCore.App]

The error message lists all the installed .NET Core versions and the version requested by the app. To fix this error, either:

• Install the appropriate version of .NET Core on the machine.
• Change the app to target a version of .NET Core that's present on the machine.
• Publish the app as a self-contained deployment.

When running in development (the ASPNETCORE_ENVIRONMENT environment variable is set to Development), the specific error is written to the HTTP response. The cause of a process startup failure is also found in the Application Event Log.

500.32 ANCM Failed to Load dll

The worker process fails. The app doesn't start.

The most common cause for this error is that the app is published for an incompatible processor architecture. If the worker process is running as a 32-bit app and the app was published to target 64-bit, this error occurs.

To fix this error, either:

• Republish the app for the same processor architecture as the worker process.
• Publish the app as a framework-dependent deployment.

500.33 ANCM Request Handler Load Failure

The worker process fails. The app doesn't start.

The app didn't reference the Microsoft.AspNetCore.App framework. Only apps targeting the Microsoft.AspNetCore.App framework can be hosted by the ASP.NET Core Module.

To fix this error, confirm that the app is targeting the Microsoft.AspNetCore.App framework. Check the .runtimeconfig.json to verify the framework targeted by the app.

500.34 ANCM Mixed Hosting Models Not Supported

The worker process can't run both an in-process app and an out-of-process app in the same process.

To fix this error, run apps in separate IIS application pools.

500.35 ANCM Multiple In-Process Applications in same Process

The worker process can't run multiple in-process apps in the same process.

To fix this error, run apps in separate IIS application pools.

500.36 ANCM Out-Of-Process Handler Load Failure

The out-of-process request handler, aspnetcorev2_outofprocess.dll, isn't next to the aspnetcorev2.dll file. This indicates a corrupted installation of the ASP.NET Core Module.

To fix this error, repair the installation of the .NET Core Hosting Bundle (for IIS) or Visual Studio (for IIS Express).

500.37 ANCM Failed to Start Within Startup Time Limit

ANCM failed to start within the provided startup time limit. By default, the timeout is 120 seconds.

This error can occur when starting a large number of apps on the same machine. Check for CPU/Memory usage spikes on the server during startup. You may need to stagger the startup process of multiple apps.

500.38 ANCM Application DLL Not Found

ANCM failed to locate the application DLL, which should be next to the executable.

This error occurs when hosting an app packaged as a single-file executable using the in-process hosting model. The in-process model requires that the ANCM load the .NET Core app into the existing IIS process. This scenario isn't supported by the single-file deployment model. Use one of the following approaches in the app's project file to fix this error:

1. Disable single-file publishing by setting the PublishSingleFile MSBuild property to false.
2. Switch to the out-of-process hosting model by setting the AspNetCoreHostingModel MSBuild property to OutOfProcess.

502.5 Process Failure

The worker process fails. The app doesn't start.

The ASP.NET Core Module attempts to start the worker process but it fails to start. The cause of a process startup failure can usually be determined from entries in the Application Event Log and the ASP.NET Core Module stdout log.

A common failure condition is the app is misconfigured due to targeting a version of the ASP.NET Core shared framework that isn't present. Check which versions of the ASP.NET Core shared framework are installed on the target machine. The shared framework is the set of assemblies (.dll files) that are installed on the machine and referenced by a metapackage such as Microsoft.AspNetCore.App. The metapackage reference can specify a minimum required version. For more information, see The shared framework.

The 502.5 Process Failure error page is returned when a hosting or app misconfiguration causes the worker process to fail:

Failed to start application (ErrorCode '0x800700c1')

EventID: 1010
Source: IIS AspNetCore Module V2
Failed to start application '/LM/W3SVC/6/ROOT/', ErrorCode '0x800700c1'.

The app failed to start because the app's assembly (.dll) couldn't be loaded.

This error occurs when there's a bitness mismatch between the published app and the w3wp/iisexpress process.

Confirm that the app pool's 32-bit setting is correct:

1. Select the app pool in IIS Manager's Application Pools.
2. Select Advanced Settings under Edit Application Pool in the Actions panel.
3. Set Enable 32-Bit Applications:
   • If deploying a 32-bit (x86) app, set the value to True.
   • If deploying a 64-bit (x64) app, set the value to False.

Confirm that there isn't a conflict between a <Platform> MSBuild property in the project file and the published bitness of the app.

Failed to start application (ErrorCode '0x800701b1')

EventID: 1010
Source: IIS AspNetCore Module V2
Failed to start application '/LM/W3SVC/3/ROOT', ErrorCode '0x800701b1'.

The app failed to start because a Windows Service failed to load.

One common service that needs to be enabled is the "null" service. The following command enables the null Windows Service:

sc.exe start null

Connection reset

If an error occurs after the headers are sent, it's too late for the server to send a 500 Internal Server Error when an error occurs. This often happens when an error occurs during the serialization of complex objects for a response. This type of error appears as a connection reset error on the client. Application logging can help troubleshoot these types of errors.

Default startup limits

The ASP.NET Core Module is configured with a default startupTimeLimit of 120 seconds. When left at the default value, an app may take up to two minutes to start before the module logs a process failure. For information on configuring the module, see Attributes of the aspNetCore element.

Troubleshoot on Azure App Service

Azure App Services Log stream

The Azure App Services Log streams logging information as it occurs. To view streaming logs:

1. In the Azure portal, open the app in App Services.
2. In the left pane, navigate to Monitoring > App Service Logs.
3. Select File System for Web Server Logging. Optionally enable Application logging.
4. In the left pane, navigate to Monitoring > Log stream, and then select Application logs or Web Server Logs.

The following images shows the application logs output:

Streaming logs have some latency and might not display immediately.

Application Event Log (Azure App Service)

To access the Application Event Log, use the Diagnose and solve problems blade in the Azure portal:

1. In the Azure portal, open the app in App Services.
2. Select Diagnose and solve problems.
3. Select the Diagnostic Tools heading.
4. Under Support Tools, select the Application Events button.
5. Examine the latest error provided by the IIS AspNetCoreModule or IIS AspNetCoreModule V2 entry in the Source column.

An alternative to using the Diagnose and solve problems blade is to examine the Application Event Log file directly using Kudu:

1. Open Advanced Tools in the Development Tools area. Select the Go→ button. The Kudu console opens in a new browser tab or window.
2. Using the navigation bar at the top of the page, open Debug console and select CMD.
3. Open the LogFiles folder.
4. Select the pencil icon next to the eventlog.xml file.
5. Examine the log. Scroll to the bottom of the log to see the most recent events.

Run the app in the Kudu console

Many startup errors don't produce useful information in the Application Event Log. You can run the app in the Kudu Remote Execution Console to discover the error:

1. Open Advanced Tools in the Development Tools area. Select the Go→ button. The Kudu console opens in a new browser tab or window.
2. Using the navigation bar at the top of the page, open Debug console and select CMD.

Test a 32-bit (x86) app

Current release

1. cd d:\home\site\wwwroot
2. Run the app:

   • If the app is a framework-dependent deployment:

     dotnet .\{ASSEMBLY NAME}.dll
     

   • If the app is a self-contained deployment:

     {ASSEMBLY NAME}.exe
     

The console output from the app, showing any errors, is piped to the Kudu console.

Framework-dependent deployment running on a preview release

Requires installing the ASP.NET Core {VERSION} (x86) Runtime site extension.

1. cd D:\home\SiteExtensions\AspNetCoreRuntime.{X.Y}.x32 ({X.Y} is the runtime version)
2. Run the app: dotnet \home\site\wwwroot\{ASSEMBLY NAME}.dll

The console output from the app, showing any errors, is piped to the Kudu console.

Test a 64-bit (x64) app

Current release

• If the app is a 64-bit (x64) framework-dependent deployment:
  1. cd D:\Program Files\dotnet
  2. Run the app: dotnet \home\site\wwwroot\{ASSEMBLY NAME}.dll
• If the app is a self-contained deployment:
  1. cd D:\home\site\wwwroot
  2. Run the app: {ASSEMBLY NAME}.exe

The console output from the app, showing any errors, is piped to the Kudu console.

Framework-dependent deployment running on a preview release

Requires installing the ASP.NET Core {VERSION} (x64) Runtime site extension.

1. cd D:\home\SiteExtensions\AspNetCoreRuntime.{X.Y}.x64 ({X.Y} is the runtime version)
2. Run the app: dotnet \home\site\wwwroot\{ASSEMBLY NAME}.dll

The console output from the app, showing any errors, is piped to the Kudu console.

ASP.NET Core Module stdout log (Azure App Service)

The ASP.NET Core Module stdout log often records useful error messages not found in the Application Event Log. To enable and view stdout logs:

1. In the Azure Portal, navigate to the web app.
2. In the App Service blade, enter kudu in the search box.
3. Select Advanced Tools > Go.
4. Select Debug console > CMD.
5. Navigate to site/wwwroot
6. Select the pencil icon to edit the web.config file.
7. In the <aspNetCore /> element, set stdoutLogEnabled="true" and select Save.

Disable stdout logging when troubleshooting is complete by setting stdoutLogEnabled="false".

For more information, see ASP.NET Core Module (ANCM) for IIS.

ASP.NET Core Module debug log (Azure App Service)

The ASP.NET Core Module debug log provides additional, deeper logging from the ASP.NET Core Module. To enable and view stdout logs:

1. To enable the enhanced diagnostic log, perform either of the following:
   • Follow the instructions in Enhanced diagnostic logs to configure the app for an enhanced diagnostic logging. Redeploy the app.
   • Add the <handlerSettings> shown in Enhanced diagnostic logs to the live app's web.config file using the Kudu console:
     1. Open Advanced Tools in the Development Tools area. Select the Go→ button. The Kudu console opens in a new browser tab or window.
     2. Using the navigation bar at the top of the page, open Debug console and select CMD.
     3. Open the folders to the path site > wwwroot. Edit the web.config file by selecting the pencil button. Add the <handlerSettings> section as shown in Enhanced diagnostic logs. Select the Save button.
2. Open Advanced Tools in the Development Tools area. Select the Go→ button. The Kudu console opens in a new browser tab or window.
3. Using the navigation bar at the top of the page, open Debug console and select CMD.
4. Open the folders to the path site > wwwroot. If you didn't supply a path for the aspnetcore-debug.log file, the file appears in the list. If you supplied a path, navigate to the location of the log file.
5. Open the log file with the pencil button next to the file name.

Disable debug logging when troubleshooting is complete:

To disable the enhanced debug log, perform either of the following:

• Remove the <handlerSettings> from the web.config file locally and redeploy the app.
• Use the Kudu console to edit the web.config file and remove the <handlerSettings> section. Save the file.

For more information, see Log creation and redirection with the ASP.NET Core Module.

Slow or hanging app (Azure App Service)

When an app responds slowly or hangs on a request, see Troubleshoot slow web app performance issues in Azure App Service.

Monitoring blades

Monitoring blades provide an alternative troubleshooting experience to the methods described earlier in the topic. These blades can be used to diagnose 500-series errors.

Confirm that the ASP.NET Core Extensions are installed. If the extensions aren't installed, install them manually:

1. In the DEVELOPMENT TOOLS blade section, select the Extensions blade.
2. The ASP.NET Core Extensions should appear in the list.
3. If the extensions aren't installed, select the Add button.
4. Choose the ASP.NET Core Extensions from the list.
5. Select OK to accept the legal terms.
6. Select OK on the Add extension blade.
7. An informational pop-up message indicates when the extensions are successfully installed.

If stdout logging isn't enabled, follow these steps:

1. In the Azure portal, select the Advanced Tools blade in the DEVELOPMENT TOOLS area. Select the Go→ button. The Kudu console opens in a new browser tab or window.
2. Using the navigation bar at the top of the page, open Debug console and select CMD.
3. Open the folders to the path site > wwwroot and scroll down to reveal the web.config file at the bottom of the list.
4. Click the pencil icon next to the web.config file.
5. Set stdoutLogEnabled to true and change the stdoutLogFile path to: \\?\%home%\LogFiles\stdout.
6. Select Save to save the updated web.config file.

Proceed to activate diagnostic logging:

1. In the Azure portal, select the Diagnostics logs blade.
2. Select the On switch for Application Logging (Filesystem) and Detailed error messages. Select the Save button at the top of the blade.
3. To include failed request tracing, also known as Failed Request Event Buffering (FREB) logging, select the On switch for Failed request tracing.
4. Select the Log stream blade, which is listed immediately under the Diagnostics logs blade in the portal.
5. Make a request to the app.
6. Within the log stream data, the cause of the error is indicated.

Be sure to disable stdout logging when troubleshooting is complete.

To view the failed request tracing logs (FREB logs):

1. Navigate to the Diagnose and solve problems blade in the Azure portal.
2. Select Failed Request Tracing Logs from the SUPPORT TOOLS area of the sidebar.

See Failed request traces section of the Enable diagnostics logging for web apps in Azure App Service topic and the Application performance FAQs for Web Apps in Azure: How do I turn on failed request tracing? for more information.

For more information, see Enable diagnostics logging for web apps in Azure App Service.

Troubleshoot on IIS

Application Event Log (IIS)

Access the Application Event Log:

1. Open the Start menu, search for Event Viewer, and select the Event Viewer app.
2. In Event Viewer, open the Windows Logs node.
3. Select Application to open the Application Event Log.
4. Search for errors associated with the failing app. Errors have a value of IIS AspNetCore Module or IIS Express AspNetCore Module in the Source column.

Run the app at a command prompt

Many startup errors don't produce useful information in the Application Event Log. You can find the cause of some errors by running the app at a command prompt on the hosting system.

Framework-dependent deployment

If the app is a framework-dependent deployment:

1. At a command prompt, navigate to the deployment folder and run the app by executing the app's assembly with dotnet.exe. In the following command, substitute the name of the app's assembly for <assembly_name>: dotnet .\<assembly_name>.dll.
2. The console output from the app, showing any errors, is written to the console window.
3. If the errors occur when making a request to the app, make a request to the host and port where Kestrel listens. Using the default host and post, make a request to http://localhost:5000/. If the app responds normally at the Kestrel endpoint address, the problem is more likely related to the hosting configuration and less likely within the app.

Self-contained deployment

If the app is a self-contained deployment:

1. At a command prompt, navigate to the deployment folder and run the app's executable. In the following command, substitute the name of the app's assembly for <assembly_name>: <assembly_name>.exe.
2. The console output from the app, showing any errors, is written to the console window.
3. If the errors occur when making a request to the app, make a request to the host and port where Kestrel listens. Using the default host and post, make a request to http://localhost:5000/. If the app responds normally at the Kestrel endpoint address, the problem is more likely related to the hosting configuration and less likely within the app.

ASP.NET Core Module stdout log (IIS)

To enable and view stdout logs:

1. Navigate to the site's deployment folder on the hosting system.
2. If the logs folder isn't present, create the folder. For instructions on how to enable MSBuild to create the logs folder in the deployment automatically, see the Directory structure topic.
3. Edit the web.config file. Set stdoutLogEnabled to true and change the stdoutLogFile path to point to the logs folder (for example, .\logs\stdout). stdout in the path is the log file name prefix. A timestamp, process id, and file extension are added automatically when the log is created. Using stdout as the file name prefix, a typical log file is named stdout_20180205184032_5412.log.
4. Ensure your application pool's identity has write permissions to the logs folder.
5. Save the updated web.config file.
6. Make a request to the app.
7. Navigate to the logs folder. Find and open the most recent stdout log.
8. Study the log for errors.

Disable stdout logging when troubleshooting is complete:

1. Edit the web.config file.
2. Set stdoutLogEnabled to false.
3. Save the file.

For more information, see ASP.NET Core Module (ANCM) for IIS.

ASP.NET Core Module debug log (IIS)

Add the following handler settings to the app's web.config file to enable ASP.NET Core Module debug log:

<aspNetCore ...>
  <handlerSettings>
    <handlerSetting name="debugLevel" value="file" />
    <handlerSetting name="debugFile" value="c:\temp\ancm.log" />
  </handlerSettings>
</aspNetCore>

Confirm that the path specified for the log exists and that the app pool's identity has write permissions to the location.

For more information, see Log creation and redirection with the ASP.NET Core Module.

Enable the Developer Exception Page

The ASPNETCORE_ENVIRONMENT environment variable can be added to web.config to run the app in the Development environment. As long as the environment isn't overridden in app startup by UseEnvironment on the host builder, setting the environment variable allows the Developer Exception Page to appear when the app is run.

<aspNetCore processPath="dotnet"
      arguments=".\MyApp.dll"
      stdoutLogEnabled="false"
      stdoutLogFile=".\logs\stdout"
      hostingModel="InProcess">
  <environmentVariables>
    <environmentVariable name="ASPNETCORE_ENVIRONMENT" value="Development" />
  </environmentVariables>
</aspNetCore>

Setting the environment variable for ASPNETCORE_ENVIRONMENT is only recommended for use on staging and testing servers that aren't exposed to the Internet. Remove the environment variable from the web.config file after troubleshooting. For information on setting environment variables in web.config, see environmentVariables child element of aspNetCore.

Obtain data from an app

If an app is capable of responding to requests, obtain request, connection, and additional data from the app using terminal inline middleware. For more information and sample code, see Troubleshoot and debug ASP.NET Core projects.

Slow or hanging app (IIS)

A crash dump is a snapshot of the system's memory and can help determine the cause of an app crash, startup failure, or slow app.

App crashes or encounters an exception

Obtain and analyze a dump from Windows Error Reporting (WER):

1. Create a folder to hold crash dump files at c:\dumps. The app pool must have write access to the folder.

2. Run the EnableDumps PowerShell script:

   • If the app uses the in-process hosting model, run the script for w3wp.exe:

     .\EnableDumps w3wp.exe c:\dumps
     

   • If the app uses the out-of-process hosting model, run the script for dotnet.exe:

     .\EnableDumps dotnet.exe c:\dumps
     

3. Run the app under the conditions that cause the crash to occur.

4. After the crash has occurred, run the DisableDumps PowerShell script:

   • If the app uses the in-process hosting model, run the script for w3wp.exe:

     .\DisableDumps w3wp.exe
     

   • If the app uses the out-of-process hosting model, run the script for dotnet.exe:

     .\DisableDumps dotnet.exe
     

After an app crashes and dump collection is complete, the app is allowed to terminate normally. The PowerShell script configures WER to collect up to five dumps per app.

App hangs, fails during startup, or runs normally

When an app hangs (stops responding but doesn't crash), fails during startup, or runs normally, see User-Mode Dump Files: Choosing the Best Tool to select an appropriate tool to produce the dump.

Analyze the dump

A dump can be analyzed using several approaches. For more information, see Analyzing a User-Mode Dump File.

Clear package caches

A functioning app may fail immediately after upgrading either the .NET Core SDK on the development machine or changing package versions within the app. In some cases, incoherent packages may break an app when performing major upgrades. Most of these issues can be fixed by following these instructions:

1. Delete the bin and obj folders.

2. Clear the package caches by executing dotnet nuget locals all --clear from a command shell.

   Clearing package caches can also be accomplished with the nuget.exe tool and executing the command nuget locals all -clear. nuget.exe isn't a bundled install with the Windows desktop operating system and must be obtained separately from the NuGet website.

3. Restore and rebuild the project.

4. Delete all of the files in the deployment folder on the server prior to redeploying the app.

Collect status codes and log entries

When an ASP.NET Core app running on IIS encounters an error, collect information to help diagnose the issue. The following information is useful for troubleshooting: Collect the following information:

• Browser behavior such as status code and error message.
• Application Event Log entries
  • Azure App Service: See Troubleshoot ASP.NET Core on Azure App Service and IIS.
  • IIS
    1. Select Start on the Windows menu, type Event Viewer, and press Enter.
    2. After the Event Viewer opens, expand Windows Logs > Application in the sidebar.
• ASP.NET Core Module stdout and debug log entries
  • Azure App Service: See Troubleshoot ASP.NET Core on Azure App Service and IIS.
  • IIS: Follow the instructions in the Log creation and redirection and Enhanced diagnostic logs sections of the ASP.NET Core Module topic.

Compare error information to the following common errors. If a match is found, follow the troubleshooting advice.

The list of errors in this topic isn't exhaustive. If you encounter an error not listed here, open a new issue using the Content feedback button at the bottom of this topic with detailed instructions on how to reproduce the error.

OS upgrade removed the 32-bit ASP.NET Core Module

Application Log: The Module DLL C:\WINDOWS\system32\inetsrv\aspnetcore.dll failed to load. The data is the error.

Troubleshooting:

Non-OS files in the C:\Windows\SysWOW64\inetsrv directory aren't preserved during an OS upgrade. If the ASP.NET Core Module is installed prior to an OS upgrade and then any app pool is run in 32-bit mode after an OS upgrade, this issue is encountered. After an OS upgrade, repair the ASP.NET Core Module. See Install the .NET Core Hosting bundle. Select Repair when the installer is run.

Missing site extension, 32-bit (x86) and 64-bit (x64) site extensions installed, or wrong process bitness set

Applies to apps hosted by Azure App Services.

• Browser: HTTP Error 500.0 - ANCM In-Process Handler Load Failure

• Application Log: Invoking hostfxr to find the inprocess request handler failed without finding any native dependencies. Could not find inprocess request handler. Captured output from invoking hostfxr: It was not possible to find any compatible framework version. The specified framework 'Microsoft.AspNetCore.App', version '{VERSION}-preview-*' was not found. Failed to start application '/LM/W3SVC/1416782824/ROOT', ErrorCode '0x8000ffff'.

• ASP.NET Core Module stdout Log: It was not possible to find any compatible framework version. The specified framework 'Microsoft.AspNetCore.App', version '{VERSION}-preview-*' was not found.

• ASP.NET Core Module Debug Log: Invoking hostfxr to find the inprocess request handler failed without finding any native dependencies. This most likely means the app is misconfigured, please check the versions of Microsoft.NetCore.App and Microsoft.AspNetCore.App that are targeted by the application and are installed on the machine. Failed HRESULT returned: 0x8000ffff. Could not find inprocess request handler. It was not possible to find any compatible framework version. The specified framework 'Microsoft.AspNetCore.App', version '{VERSION}-preview-*' was not found.

Troubleshooting:

• If running the app on a preview runtime, install either the 32-bit (x86) or 64-bit (x64) site extension that matches the bitness of the app and the app's runtime version. Don't install both extensions or multiple runtime versions of the extension.

  • ASP.NET Core {RUNTIME VERSION} (x86) Runtime
  • ASP.NET Core {RUNTIME VERSION} (x64) Runtime

  Restart the app. Wait several seconds for the app to restart.

• If running the app on a preview runtime and both the 32-bit (x86) and 64-bit (x64) site extensions are installed, uninstall the site extension that doesn't match the bitness of the app. After removing the site extension, restart the app. Wait several seconds for the app to restart.

• If running the app on a preview runtime and the site extension's bitness matches that of the app, confirm that the preview site extension's runtime version matches the app's runtime version.

• Confirm that the app's Platform in Application Settings matches the bitness of the app.

For more information, see Deploy ASP.NET Core apps to Azure App Service.

An x86 app is deployed but the app pool isn't enabled for 32-bit apps

• Browser: HTTP Error 500.30 - ANCM In-Process Start Failure

• Application Log: Application '/LM/W3SVC/5/ROOT' with physical root '{PATH}' hit unexpected managed exception, exception code = '0xe0434352'. Please check the stderr logs for more information. Application '/LM/W3SVC/5/ROOT' with physical root '{PATH}' failed to load clr and managed application. CLR worker thread exited prematurely

• ASP.NET Core Module stdout Log: The log file is created but empty.

• ASP.NET Core Module Debug Log: Failed HRESULT returned: 0x8007023e

This scenario is trapped by the SDK when publishing a self-contained app. The SDK produces an error if the RID doesn't match the platform target (for example, win10-x64 RID with <PlatformTarget>x86</PlatformTarget> in the project file).

Troubleshooting:

For an x86 framework-dependent deployment (<PlatformTarget>x86</PlatformTarget>), enable the IIS app pool for 32-bit apps. In IIS Manager, open the app pool's Advanced Settings and set Enable 32-Bit Applications to True.

Platform conflicts with RID

• Browser: HTTP Error 502.5 - Process Failure

• Application Log: Application 'MACHINE/WEBROOT/APPHOST/{ASSEMBLY}' with physical root 'C:{PATH}' failed to start process with commandline '"C:{PATH}{ASSEMBLY}.{exe|dll}" ', ErrorCode = '0x80004005 : ff.

• ASP.NET Core Module stdout Log: Unhandled Exception: System.BadImageFormatException: Could not load file or assembly '{ASSEMBLY}.dll'. An attempt was made to load a program with an incorrect format.

Troubleshooting:

• Confirm that the app runs locally on Kestrel. A process failure might be the result of a problem within the app. For more information, see Troubleshoot ASP.NET Core on Azure App Service and IIS.

• If this exception occurs for an Azure Apps deployment when upgrading an app and deploying newer assemblies, manually delete all files from the prior deployment. Lingering incompatible assemblies can result in a System.BadImageFormatException exception when deploying an upgraded app.

URI endpoint wrong or stopped website

• Browser: ERR_CONNECTION_REFUSED --OR-- Unable to connect

• Application Log: No entry

• ASP.NET Core Module stdout Log: The log file isn't created.

• ASP.NET Core Module Debug Log: The log file isn't created.

Troubleshooting:

• Confirm the correct URI endpoint for the app is in use. Check the bindings.

• Confirm that the IIS website isn't in the Stopped state.

CoreWebEngine or W3SVC server features disabled

OS Exception: The IIS 7.0 CoreWebEngine and W3SVC features must be installed to use the ASP.NET Core Module.

Troubleshooting:

Confirm that the proper role and features are enabled. See IIS Configuration.

Incorrect website physical path or app missing

• Browser: 403 Forbidden - Access is denied --OR-- 403.14 Forbidden - The Web server is configured to not list the contents of this directory.

• Application Log: No entry

• ASP.NET Core Module stdout Log: The log file isn't created.

• ASP.NET Core Module Debug Log: The log file isn't created.

Troubleshooting:

Check the IIS website Basic Settings and the physical app folder. Confirm that the app is in the folder at the IIS website Physical path.

Incorrect role, ASP.NET Core Module not installed, or incorrect permissions

• Browser: 500.19 Internal Server Error - The requested page cannot be accessed because the related configuration data for the page is invalid. --OR-- This page can't be displayed

• Application Log: No entry

• ASP.NET Core Module stdout Log: The log file isn't created.

• ASP.NET Core Module Debug Log: The log file isn't created.

Troubleshooting:

• Confirm that the proper role is enabled. See IIS Configuration.

• Open Programs & Features or Apps & features and confirm that Windows Server Hosting is installed. If Windows Server Hosting isn't present in the list of installed programs, download and install the .NET Core Hosting Bundle.

  Current .NET Core Hosting Bundle installer (direct download)

  For more information, see Install the .NET Core Hosting Bundle.

• Make sure that the Application Pool > Process Model > Identity is set to ApplicationPoolIdentity or the custom identity has the correct permissions to access the app's deployment folder.

• If you uninstalled the ASP.NET Core Hosting Bundle and installed an earlier version of the hosting bundle, the applicationHost.config file doesn't include a section for the ASP.NET Core Module. Open applicationHost.config at %windir%/System32/inetsrv/config and find the <configuration><configSections><sectionGroup name="system.webServer"> section group. If the section for the ASP.NET Core Module is missing from the section group, add the section element:

  <section name="aspNetCore" overrideModeDefault="Allow" />
  

  Alternatively, install the latest version of the ASP.NET Core Hosting Bundle. The latest version is backwards-compatible with supported ASP.NET Core apps.

Incorrect processPath, missing PATH variable, Hosting Bundle not installed, system/IIS not restarted, VC++ Redistributable not installed, or dotnet.exe access violation

• Browser: HTTP Error 500.0 - ANCM In-Process Handler Load Failure

• Application Log: Application 'MACHINE/WEBROOT/APPHOST/{ASSEMBLY}' with physical root 'C:{PATH}' failed to start process with commandline '"{...}" ', ErrorCode = '0x80070002 : 0. Application '{PATH}' wasn't able to start. Executable was not found at '{PATH}'. Failed to start application '/LM/W3SVC/2/ROOT', ErrorCode '0x8007023e'.

• ASP.NET Core Module stdout Log: The log file isn't created.

• ASP.NET Core Module Debug Log: Event Log: 'Application '{PATH}' wasn't able to start. Executable was not found at '{PATH}'. Failed HRESULT returned: 0x8007023e

Troubleshooting:

• Confirm that the app runs locally on Kestrel. A process failure might be the result of a problem within the app. For more information, see Troubleshoot ASP.NET Core on Azure App Service and IIS.

• Check the processPath attribute on the <aspNetCore> element in web.config to confirm that it's dotnet for a framework-dependent deployment (FDD) or .\{ASSEMBLY}.exe for a self-contained deployment (SCD).

• For an FDD, dotnet.exe might not be accessible via the PATH settings. Confirm that C:\Program Files\dotnet\ exists in the System PATH settings.

• For an FDD, dotnet.exe might not be accessible for the user identity of the app pool. Confirm that the app pool user identity has access to the C:\Program Files\dotnet directory. Confirm that there are no deny rules configured for the app pool user identity on the C:\Program Files\dotnet and app directories.

• An FDD may have been deployed and .NET Core installed without restarting IIS. Either restart the server or restart IIS by executing net stop was /y followed by net start w3svc from a command prompt.

• An FDD may have been deployed without installing the .NET Core runtime on the hosting system. If the .NET Core runtime hasn't been installed, run the .NET Core Hosting Bundle installer on the system.

  Current .NET Core Hosting Bundle installer (direct download)

  For more information, see Install the .NET Core Hosting Bundle.

  If a specific runtime is required, download the runtime from the .NET Downloads page and install it on the system. Complete the installation by restarting the system or restarting IIS by executing net stop was /y followed by net start w3svc from a command prompt.

Incorrect arguments of <aspNetCore> element

• Browser: HTTP Error 500.0 - ANCM In-Process Handler Load Failure

• Application Log: Invoking hostfxr to find the inprocess request handler failed without finding any native dependencies. This most likely means the app is misconfigured, please check the versions of Microsoft.NetCore.App and Microsoft.AspNetCore.App that are targeted by the application and are installed on the machine. Could not find inprocess request handler. Captured output from invoking hostfxr: Did you mean to run dotnet SDK commands? Please install dotnet SDK from: https://go.microsoft.com/fwlink/?LinkID=798306&clcid=0x409 Failed to start application '/LM/W3SVC/3/ROOT', ErrorCode '0x8000ffff'.

• ASP.NET Core Module stdout Log: Did you mean to run dotnet SDK commands? Please install dotnet SDK from: https://go.microsoft.com/fwlink/?LinkID=798306&clcid=0x409

• ASP.NET Core Module Debug Log: Invoking hostfxr to find the inprocess request handler failed without finding any native dependencies. This most likely means the app is misconfigured, please check the versions of Microsoft.NetCore.App and Microsoft.AspNetCore.App that are targeted by the application and are installed on the machine. Failed HRESULT returned: 0x8000ffff Could not find inprocess request handler. Captured output from invoking hostfxr: Did you mean to run dotnet SDK commands? Please install dotnet SDK from: https://go.microsoft.com/fwlink/?LinkID=798306&clcid=0x409 Failed HRESULT returned: 0x8000ffff

Troubleshooting:

• Confirm that the app runs locally on Kestrel. A process failure might be the result of a problem within the app. For more information, see Troubleshoot ASP.NET Core on Azure App Service and IIS.

• Examine the arguments attribute on the <aspNetCore> element in web.config to confirm that it's either (a) .\{ASSEMBLY}.dll for a framework-dependent deployment (FDD); or (b) not present, an empty string (arguments=""), or a list of the app's arguments (arguments="{ARGUMENT_1}, {ARGUMENT_2}, ... {ARGUMENT_X}") for a self-contained deployment (SCD).

Missing .NET Core shared framework

• Browser: HTTP Error 500.0 - ANCM In-Process Handler Load Failure

• Application Log: Invoking hostfxr to find the inprocess request handler failed without finding any native dependencies. This most likely means the app is misconfigured, please check the versions of Microsoft.NetCore.App and Microsoft.AspNetCore.App that are targeted by the application and are installed on the machine. Could not find inprocess request handler. Captured output from invoking hostfxr: It was not possible to find any compatible framework version. The specified framework 'Microsoft.AspNetCore.App', version '{VERSION}' was not found.

Failed to start application '/LM/W3SVC/5/ROOT', ErrorCode '0x8000ffff'.

• ASP.NET Core Module stdout Log: It was not possible to find any compatible framework version. The specified framework 'Microsoft.AspNetCore.App', version '{VERSION}' was not found.

• ASP.NET Core Module Debug Log: Failed HRESULT returned: 0x8000ffff

Troubleshooting:

For a framework-dependent deployment (FDD), confirm that the correct runtime installed on the system.

Stopped Application Pool

• Browser: 503 Service Unavailable

• Application Log: No entry

• ASP.NET Core Module stdout Log: The log file isn't created.

• ASP.NET Core Module Debug Log: The log file isn't created.

Troubleshooting:

Confirm that the Application Pool isn't in the Stopped state.

Sub-application includes a <handlers> section

• Browser: HTTP Error 500.19 - Internal Server Error

• Application Log: No entry

• ASP.NET Core Module stdout Log: The root app's log file is created and shows normal operation. The sub-app's log file isn't created.

• ASP.NET Core Module Debug Log: The root app's log file is created and shows normal operation. The sub-app's log file isn't created.

Troubleshooting:

Confirm that the sub-app's web.config file doesn't include a <handlers> section or that the sub-app doesn't inherit the parent app's handlers.

The parent app's <system.webServer> section of web.config is placed inside of a <location> element. The InheritInChildApplications property is set to false to indicate that the settings specified within the <location> element aren't inherited by apps that reside in a subdirectory of the parent app. For more information, see ASP.NET Core Module (ANCM) for IIS.

stdout log path incorrect

• Browser: The app responds normally.

• Application Log: Could not start stdout redirection in C:\Program Files\IIS\Asp.Net Core Module\V2\aspnetcorev2.dll. Exception message: HRESULT 0x80070005 returned at {PATH}\aspnetcoremodulev2\commonlib\fileoutputmanager.cpp:84. Could not stop stdout redirection in C:\Program Files\IIS\Asp.Net Core Module\V2\aspnetcorev2.dll. Exception message: HRESULT 0x80070002 returned at {PATH}. Could not start stdout redirection in {PATH}\aspnetcorev2_inprocess.dll.

• ASP.NET Core Module stdout Log: The log file isn't created.

• ASP.NET Core Module debug Log: Could not start stdout redirection in C:\Program Files\IIS\Asp.Net Core Module\V2\aspnetcorev2.dll. Exception message: HRESULT 0x80070005 returned at {PATH}\aspnetcoremodulev2\commonlib\fileoutputmanager.cpp:84. Could not stop stdout redirection in C:\Program Files\IIS\Asp.Net Core Module\V2\aspnetcorev2.dll. Exception message: HRESULT 0x80070002 returned at {PATH}. Could not start stdout redirection in {PATH}\aspnetcorev2_inprocess.dll.

Troubleshooting:

• The stdoutLogFile path specified in the <aspNetCore> element of web.config doesn't exist. For more information, see ASP.NET Core Module: Log creation and redirection.

• The app pool user doesn't have write access to the stdout log path.

Application configuration general issue

• Browser: HTTP Error 500.0 - ANCM In-Process Handler Load Failure --OR-- HTTP Error 500.30 - ANCM In-Process Start Failure

• Application Log: Variable

• ASP.NET Core Module stdout Log: The log file is created but empty or created with normal entries until the point of the app failing.

• ASP.NET Core Module Debug Log: Variable

Troubleshooting:

The process failed to start, most likely due to an app configuration or programming issue.

For more information, see the following topics:

• Troubleshoot ASP.NET Core on Azure App Service and IIS
• Troubleshoot and debug ASP.NET Core projects

Additional resources

• Debug .NET and ASP.NET Core source code with Visual Studio
• Troubleshoot and debug ASP.NET Core projects
• Handle errors in ASP.NET Core
• ASP.NET Core Module (ANCM) for IIS

Azure documentation

• Application Insights for ASP.NET Core
• Remote debugging web apps section of Troubleshoot a web app in Azure App Service using Visual Studio
• Azure App Service diagnostics overview
• How to: Monitor Apps in Azure App Service
• Troubleshoot a web app in Azure App Service using Visual Studio
• Troubleshoot HTTP errors of "502 bad gateway" and "503 service unavailable" in your Azure web apps
• Troubleshoot slow web app performance issues in Azure App Service
• Application performance FAQs for Web Apps in Azure
• Azure Web App sandbox (App Service runtime execution limitations)

Visual Studio documentation

• Remote Debug ASP.NET Core on IIS in Azure in Visual Studio 2017
• Remote Debug ASP.NET Core on a Remote IIS Computer in Visual Studio 2017
• Learn to debug using Visual Studio

Visual Studio Code documentation

• Debugging with Visual Studio Code

This article provides information on common app startup errors and instructions on how to diagnose errors when an app is deployed to Azure App Service or IIS:

App startup errors
Explains common startup HTTP status code scenarios.

Troubleshoot on Azure App Service
Provides troubleshooting advice for apps deployed to Azure App Service.

Troubleshoot on IIS
Provides troubleshooting advice for apps deployed to IIS or running on IIS Express locally. The guidance applies to both Windows Server and Windows desktop deployments.

Clear package caches
Explains what to do when incoherent packages break an app when performing major upgrades or changing package versions.

Additional resources
Lists additional troubleshooting topics.

App startup errors

In Visual Studio, an ASP.NET Core project defaults to IIS Express hosting during debugging. A 502.5 - Process Failure or a 500.30 - Start Failure that occurs when debugging locally can be diagnosed using the advice in this topic.

403.14 Forbidden

The app fails to start. The following error is logged:

The Web server is configured to not list the contents of this directory.

The error is usually caused by a broken deployment on the hosting system, which includes any of the following scenarios:

• The app is deployed to the wrong folder on the hosting system.
• The deployment process failed to move all of the app's files and folders to the deployment folder on the hosting system.
• The web.config file is missing from the deployment, or the web.config file contents are malformed.

Perform the following steps:

1. Delete all of the files and folders from the deployment folder on the hosting system.
2. Redeploy the contents of the app's publish folder to the hosting system using your normal method of deployment, such as Visual Studio, PowerShell, or manual deployment:
   • Confirm that the web.config file is present in the deployment and that its contents are correct.
   • When hosting on Azure App Service, confirm that the app is deployed to the D:\home\site\wwwroot folder.
   • When the app is hosted by IIS, confirm that the app is deployed to the IIS Physical path shown in IIS Manager's Basic Settings.
3. Confirm that all of the app's files and folders are deployed by comparing the deployment on the hosting system to the contents of the project's publish folder.

For more information on the layout of a published ASP.NET Core app, see ASP.NET Core directory structure. For more information on the web.config file, see ASP.NET Core Module (ANCM) for IIS.

500 Internal Server Error

The app starts, but an error prevents the server from fulfilling the request.

This error occurs within the app's code during startup or while creating a response. The response may contain no content, or the response may appear as a 500 Internal Server Error in the browser. The Application Event Log usually states that the app started normally. From the server's perspective, that's correct. The app did start, but it can't generate a valid response. Run the app at a command prompt on the server or enable the ASP.NET Core Module stdout log to troubleshoot the problem.

This error also may occur when the .NET Core Hosting Bundle isn't installed or is corrupted. Installing or repairing the installation of the .NET Core Hosting Bundle (for IIS) or Visual Studio (for IIS Express) may fix the problem.

500.0 In-Process Handler Load Failure

The worker process fails. The app doesn't start.

The ASP.NET Core Module fails to find the .NET Core CLR and find the in-process request handler (aspnetcorev2_inprocess.dll). Check that:

• The app targets either the Microsoft.AspNetCore.Server.IIS NuGet package or the Microsoft.AspNetCore.App metapackage.
• The version of the ASP.NET Core shared framework that the app targets is installed on the target machine.

500.0 Out-Of-Process Handler Load Failure

The worker process fails. The app doesn't start.

The ASP.NET Core Module fails to find the out-of-process hosting request handler. Make sure the aspnetcorev2_outofprocess.dll is present in a subfolder next to aspnetcorev2.dll.

502.5 Process Failure

The worker process fails. The app doesn't start.

The ASP.NET Core Module attempts to start the worker process but it fails to start. The cause of a process startup failure can usually be determined from entries in the Application Event Log and the ASP.NET Core Module stdout log.

A common failure condition is the app is misconfigured due to targeting a version of the ASP.NET Core shared framework that isn't present. Check which versions of the ASP.NET Core shared framework are installed on the target machine. The shared framework is the set of assemblies (.dll files) that are installed on the machine and referenced by a metapackage such as Microsoft.AspNetCore.App. The metapackage reference can specify a minimum required version. For more information, see The shared framework.

The 502.5 Process Failure error page is returned when a hosting or app misconfiguration causes the worker process to fail:

Failed to start application (ErrorCode '0x800700c1')

EventID: 1010
Source: IIS AspNetCore Module V2
Failed to start application '/LM/W3SVC/6/ROOT/', ErrorCode '0x800700c1'.

The app failed to start because the app's assembly (.dll) couldn't be loaded.

This error occurs when there's a bitness mismatch between the published app and the w3wp/iisexpress process.

Confirm that the app pool's 32-bit setting is correct:

1. Select the app pool in IIS Manager's Application Pools.
2. Select Advanced Settings under Edit Application Pool in the Actions panel.
3. Set Enable 32-Bit Applications:
   • If deploying a 32-bit (x86) app, set the value to True.
   • If deploying a 64-bit (x64) app, set the value to False.

Confirm that there isn't a conflict between a <Platform> MSBuild property in the project file and the published bitness of the app.

Connection reset

If an error occurs after the headers are sent, it's too late for the server to send a 500 Internal Server Error when an error occurs. This often happens when an error occurs during the serialization of complex objects for a response. This type of error appears as a connection reset error on the client. Application logging can help troubleshoot these types of errors.

Default startup limits

The ASP.NET Core Module is configured with a default startupTimeLimit of 120 seconds. When left at the default value, an app may take up to two minutes to start before the module logs a process failure. For information on configuring the module, see Attributes of the aspNetCore element.

Troubleshoot on Azure App Service

Application Event Log (Azure App Service)

To access the Application Event Log, use the Diagnose and solve problems blade in the Azure portal:

1. In the Azure portal, open the app in App Services.
2. Select Diagnose and solve problems.
3. Select the Diagnostic Tools heading.
4. Under Support Tools, select the Application Events button.
5. Examine the latest error provided by the IIS AspNetCoreModule or IIS AspNetCoreModule V2 entry in the Source column.

An alternative to using the Diagnose and solve problems blade is to examine the Application Event Log file directly using Kudu:

1. Open Advanced Tools in the Development Tools area. Select the Go→ button. The Kudu console opens in a new browser tab or window.
2. Using the navigation bar at the top of the page, open Debug console and select CMD.
3. Open the LogFiles folder.
4. Select the pencil icon next to the eventlog.xml file.
5. Examine the log. Scroll to the bottom of the log to see the most recent events.

Run the app in the Kudu console

Many startup errors don't produce useful information in the Application Event Log. You can run the app in the Kudu Remote Execution Console to discover the error:

1. Open Advanced Tools in the Development Tools area. Select the Go→ button. The Kudu console opens in a new browser tab or window.
2. Using the navigation bar at the top of the page, open Debug console and select CMD.

Test a 32-bit (x86) app

Current release

1. cd d:\home\site\wwwroot
2. Run the app:

   • If the app is a framework-dependent deployment:

     dotnet .\{ASSEMBLY NAME}.dll
     

   • If the app is a self-contained deployment:

     {ASSEMBLY NAME}.exe
     

The console output from the app, showing any errors, is piped to the Kudu console.

Framework-dependent deployment running on a preview release

Requires installing the ASP.NET Core {VERSION} (x86) Runtime site extension.

1. cd D:\home\SiteExtensions\AspNetCoreRuntime.{X.Y}.x32 ({X.Y} is the runtime version)
2. Run the app: dotnet \home\site\wwwroot\{ASSEMBLY NAME}.dll

The console output from the app, showing any errors, is piped to the Kudu console.

Test a 64-bit (x64) app

Current release

• If the app is a 64-bit (x64) framework-dependent deployment:
  1. cd D:\Program Files\dotnet
  2. Run the app: dotnet \home\site\wwwroot\{ASSEMBLY NAME}.dll
• If the app is a self-contained deployment:
  1. cd D:\home\site\wwwroot
  2. Run the app: {ASSEMBLY NAME}.exe

The console output from the app, showing any errors, is piped to the Kudu console.

Framework-dependent deployment running on a preview release

Requires installing the ASP.NET Core {VERSION} (x64) Runtime site extension.

1. cd D:\home\SiteExtensions\AspNetCoreRuntime.{X.Y}.x64 ({X.Y} is the runtime version)
2. Run the app: dotnet \home\site\wwwroot\{ASSEMBLY NAME}.dll

The console output from the app, showing any errors, is piped to the Kudu console.

ASP.NET Core Module stdout log (Azure App Service)

The ASP.NET Core Module stdout log often records useful error messages not found in the Application Event Log. To enable and view stdout logs:

1. Navigate to the Diagnose and solve problems blade in the Azure portal.
2. Under SELECT PROBLEM CATEGORY, select the Web App Down button.
3. Under Suggested Solutions > Enable Stdout Log Redirection, select the button to Open Kudu Console to edit Web.Config.
4. In the Kudu Diagnostic Console, open the folders to the path site > wwwroot. Scroll down to reveal the web.config file at the bottom of the list.
5. Click the pencil icon next to the web.config file.
6. Set stdoutLogEnabled to true and change the stdoutLogFile path to: \\?\%home%\LogFiles\stdout.
7. Select Save to save the updated web.config file.
8. Make a request to the app.
9. Return to the Azure portal. Select the Advanced Tools blade in the DEVELOPMENT TOOLS area. Select the Go→ button. The Kudu console opens in a new browser tab or window.
10. Using the navigation bar at the top of the page, open Debug console and select CMD.
11. Select the LogFiles folder.
12. Inspect the Modified column and select the pencil icon to edit the stdout log with the latest modification date.
13. When the log file opens, the error is displayed.

Disable stdout logging when troubleshooting is complete:

1. In the Kudu Diagnostic Console, return to the path site > wwwroot to reveal the web.config file. Open the web.config file again by selecting the pencil icon.
2. Set stdoutLogEnabled to false.
3. Select Save to save the file.

For more information, see ASP.NET Core Module (ANCM) for IIS.

ASP.NET Core Module debug log (Azure App Service)

The ASP.NET Core Module debug log provides additional, deeper logging from the ASP.NET Core Module. To enable and view stdout logs:

1. To enable the enhanced diagnostic log, perform either of the following:
   • Follow the instructions in Enhanced diagnostic logs to configure the app for an enhanced diagnostic logging. Redeploy the app.
   • Add the <handlerSettings> shown in Enhanced diagnostic logs to the live app's web.config file using the Kudu console:
     1. Open Advanced Tools in the Development Tools area. Select the Go→ button. The Kudu console opens in a new browser tab or window.
     2. Using the navigation bar at the top of the page, open Debug console and select CMD.
     3. Open the folders to the path site > wwwroot. Edit the web.config file by selecting the pencil button. Add the <handlerSettings> section as shown in Enhanced diagnostic logs. Select the Save button.
2. Open Advanced Tools in the Development Tools area. Select the Go→ button. The Kudu console opens in a new browser tab or window.
3. Using the navigation bar at the top of the page, open Debug console and select CMD.
4. Open the folders to the path site > wwwroot. If you didn't supply a path for the aspnetcore-debug.log file, the file appears in the list. If you supplied a path, navigate to the location of the log file.
5. Open the log file with the pencil button next to the file name.

Disable debug logging when troubleshooting is complete:

To disable the enhanced debug log, perform either of the following:

• Remove the <handlerSettings> from the web.config file locally and redeploy the app.
• Use the Kudu console to edit the web.config file and remove the <handlerSettings> section. Save the file.

For more information, see Log creation and redirection with the ASP.NET Core Module.

Slow or hanging app (Azure App Service)

When an app responds slowly or hangs on a request, see the following articles:

• Troubleshoot slow web app performance issues in Azure App Service
• Use Crash Diagnoser Site Extension to Capture Dump for Intermittent Exception issues or performance issues on Azure Web App

Monitoring blades

Monitoring blades provide an alternative troubleshooting experience to the methods described earlier in the topic. These blades can be used to diagnose 500-series errors.

Confirm that the ASP.NET Core Extensions are installed. If the extensions aren't installed, install them manually:

1. In the DEVELOPMENT TOOLS blade section, select the Extensions blade.
2. The ASP.NET Core Extensions should appear in the list.
3. If the extensions aren't installed, select the Add button.
4. Choose the ASP.NET Core Extensions from the list.
5. Select OK to accept the legal terms.
6. Select OK on the Add extension blade.
7. An informational pop-up message indicates when the extensions are successfully installed.

If stdout logging isn't enabled, follow these steps:

1. In the Azure portal, select the Advanced Tools blade in the DEVELOPMENT TOOLS area. Select the Go→ button. The Kudu console opens in a new browser tab or window.
2. Using the navigation bar at the top of the page, open Debug console and select CMD.
3. Open the folders to the path site > wwwroot and scroll down to reveal the web.config file at the bottom of the list.
4. Click the pencil icon next to the web.config file.
5. Set stdoutLogEnabled to true and change the stdoutLogFile path to: \\?\%home%\LogFiles\stdout.
6. Select Save to save the updated web.config file.

Proceed to activate diagnostic logging:

1. In the Azure portal, select the Diagnostics logs blade.
2. Select the On switch for Application Logging (Filesystem) and Detailed error messages. Select the Save button at the top of the blade.
3. To include failed request tracing, also known as Failed Request Event Buffering (FREB) logging, select the On switch for Failed request tracing.
4. Select the Log stream blade, which is listed immediately under the Diagnostics logs blade in the portal.
5. Make a request to the app.
6. Within the log stream data, the cause of the error is indicated.

Be sure to disable stdout logging when troubleshooting is complete.

To view the failed request tracing logs (FREB logs):

1. Navigate to the Diagnose and solve problems blade in the Azure portal.
2. Select Failed Request Tracing Logs from the SUPPORT TOOLS area of the sidebar.

See Failed request traces section of the Enable diagnostics logging for web apps in Azure App Service topic and the Application performance FAQs for Web Apps in Azure: How do I turn on failed request tracing? for more information.

For more information, see Enable diagnostics logging for web apps in Azure App Service.

Troubleshoot on IIS

Application Event Log (IIS)

Access the Application Event Log:

1. Open the Start menu, search for Event Viewer, and select the Event Viewer app.
2. In Event Viewer, open the Windows Logs node.
3. Select Application to open the Application Event Log.
4. Search for errors associated with the failing app. Errors have a value of IIS AspNetCore Module or IIS Express AspNetCore Module in the Source column.

Run the app at a command prompt

Many startup errors don't produce useful information in the Application Event Log. You can find the cause of some errors by running the app at a command prompt on the hosting system.

Framework-dependent deployment

If the app is a framework-dependent deployment:

1. At a command prompt, navigate to the deployment folder and run the app by executing the app's assembly with dotnet.exe. In the following command, substitute the name of the app's assembly for <assembly_name>: dotnet .\<assembly_name>.dll.
2. The console output from the app, showing any errors, is written to the console window.
3. If the errors occur when making a request to the app, make a request to the host and port where Kestrel listens. Using the default host and post, make a request to http://localhost:5000/. If the app responds normally at the Kestrel endpoint address, the problem is more likely related to the hosting configuration and less likely within the app.

Self-contained deployment

If the app is a self-contained deployment:

1. At a command prompt, navigate to the deployment folder and run the app's executable. In the following command, substitute the name of the app's assembly for <assembly_name>: <assembly_name>.exe.
2. The console output from the app, showing any errors, is written to the console window.
3. If the errors occur when making a request to the app, make a request to the host and port where Kestrel listens. Using the default host and post, make a request to http://localhost:5000/. If the app responds normally at the Kestrel endpoint address, the problem is more likely related to the hosting configuration and less likely within the app.

ASP.NET Core Module stdout log (IIS)

To enable and view stdout logs:

1. Navigate to the site's deployment folder on the hosting system.
2. If the logs folder isn't present, create the folder. For instructions on how to enable MSBuild to create the logs folder in the deployment automatically, see the Directory structure topic.
3. Edit the web.config file. Set stdoutLogEnabled to true and change the stdoutLogFile path to point to the logs folder (for example, .\logs\stdout). stdout in the path is the log file name prefix. A timestamp, process id, and file extension are added automatically when the log is created. Using stdout as the file name prefix, a typical log file is named stdout_20180205184032_5412.log.
4. Ensure your application pool's identity has write permissions to the logs folder.
5. Save the updated web.config file.
6. Make a request to the app.
7. Navigate to the logs folder. Find and open the most recent stdout log.
8. Study the log for errors.

Disable stdout logging when troubleshooting is complete:

1. Edit the web.config file.
2. Set stdoutLogEnabled to false.
3. Save the file.

For more information, see ASP.NET Core Module (ANCM) for IIS.

ASP.NET Core Module debug log (IIS)

Add the following handler settings to the app's web.config file to enable ASP.NET Core Module debug log:

<aspNetCore ...>
  <handlerSettings>
    <handlerSetting name="debugLevel" value="file" />
    <handlerSetting name="debugFile" value="c:\temp\ancm.log" />
  </handlerSettings>
</aspNetCore>

Confirm that the path specified for the log exists and that the app pool's identity has write permissions to the location.

For more information, see Log creation and redirection with the ASP.NET Core Module.

Enable the Developer Exception Page

The ASPNETCORE_ENVIRONMENT environment variable can be added to web.config to run the app in the Development environment. As long as the environment isn't overridden in app startup by UseEnvironment on the host builder, setting the environment variable allows the Developer Exception Page to appear when the app is run.

<aspNetCore processPath="dotnet"
      arguments=".\MyApp.dll"
      stdoutLogEnabled="false"
      stdoutLogFile=".\logs\stdout"
      hostingModel="InProcess">
  <environmentVariables>
    <environmentVariable name="ASPNETCORE_ENVIRONMENT" value="Development" />
  </environmentVariables>
</aspNetCore>

Setting the environment variable for ASPNETCORE_ENVIRONMENT is only recommended for use on staging and testing servers that aren't exposed to the Internet. Remove the environment variable from the web.config file after troubleshooting. For information on setting environment variables in web.config, see environmentVariables child element of aspNetCore.

Obtain data from an app

If an app is capable of responding to requests, obtain request, connection, and additional data from the app using terminal inline middleware. For more information and sample code, see Troubleshoot and debug ASP.NET Core projects.

Slow or hanging app (IIS)

A crash dump is a snapshot of the system's memory and can help determine the cause of an app crash, startup failure, or slow app.

App crashes or encounters an exception

Obtain and analyze a dump from Windows Error Reporting (WER):

1. Create a folder to hold crash dump files at c:\dumps. The app pool must have write access to the folder.

2. Run the EnableDumps PowerShell script:

   • If the app uses the in-process hosting model, run the script for w3wp.exe:

     .\EnableDumps w3wp.exe c:\dumps
     

   • If the app uses the out-of-process hosting model, run the script for dotnet.exe:

     .\EnableDumps dotnet.exe c:\dumps
     

3. Run the app under the conditions that cause the crash to occur.

4. After the crash has occurred, run the DisableDumps PowerShell script:

   • If the app uses the in-process hosting model, run the script for w3wp.exe:

     .\DisableDumps w3wp.exe
     

   • If the app uses the out-of-process hosting model, run the script for dotnet.exe:

     .\DisableDumps dotnet.exe
     

After an app crashes and dump collection is complete, the app is allowed to terminate normally. The PowerShell script configures WER to collect up to five dumps per app.

App hangs, fails during startup, or runs normally

When an app hangs (stops responding but doesn't crash), fails during startup, or runs normally, see User-Mode Dump Files: Choosing the Best Tool to select an appropriate tool to produce the dump.

Analyze the dump

A dump can be analyzed using several approaches. For more information, see Analyzing a User-Mode Dump File.

Clear package caches

A functioning app may fail immediately after upgrading either the .NET Core SDK on the development machine or changing package versions within the app. In some cases, incoherent packages may break an app when performing major upgrades. Most of these issues can be fixed by following these instructions:

1. Delete the bin and obj folders.

2. Clear the package caches by executing dotnet nuget locals all --clear from a command shell.

   Clearing package caches can also be accomplished with the nuget.exe tool and executing the command nuget locals all -clear. nuget.exe isn't a bundled install with the Windows desktop operating system and must be obtained separately from the NuGet website.

3. Restore and rebuild the project.

4. Delete all of the files in the deployment folder on the server prior to redeploying the app.

Additional resources

• Troubleshoot and debug ASP.NET Core projects
• Handle errors in ASP.NET Core
• ASP.NET Core Module (ANCM) for IIS

Azure documentation

• Application Insights for ASP.NET Core
• Remote debugging web apps section of Troubleshoot a web app in Azure App Service using Visual Studio
• Azure App Service diagnostics overview
• How to: Monitor Apps in Azure App Service
• Troubleshoot a web app in Azure App Service using Visual Studio
• Troubleshoot HTTP errors of "502 bad gateway" and "503 service unavailable" in your Azure web apps
• Troubleshoot slow web app performance issues in Azure App Service
• Application performance FAQs for Web Apps in Azure
• Azure Web App sandbox (App Service runtime execution limitations)

Visual Studio documentation

• Remote Debug ASP.NET Core on IIS in Azure in Visual Studio 2017
• Remote Debug ASP.NET Core on a Remote IIS Computer in Visual Studio 2017
• Learn to debug using Visual Studio

Visual Studio Code documentation

• Debugging with Visual Studio Code

This article provides information on common app startup errors and instructions on how to diagnose errors when an app is deployed to Azure App Service or IIS:

App startup errors
Explains common startup HTTP status code scenarios.

Troubleshoot on Azure App Service
Provides troubleshooting advice for apps deployed to Azure App Service.

Troubleshoot on IIS
Provides troubleshooting advice for apps deployed to IIS or running on IIS Express locally. The guidance applies to both Windows Server and Windows desktop deployments.

Clear package caches
Explains what to do when incoherent packages break an app when performing major upgrades or changing package versions.

Additional resources
Lists additional troubleshooting topics.

App startup errors

In Visual Studio, the ASP.NET Core project default server is Kestrel. Visual studio can be configured to use IIS Express. A 502.5 - Process Failure or a 500.30 - Start Failure that occurs when debugging locally with IIS Express can be diagnosed using the advice in this topic.

403.14 Forbidden

The app fails to start. The following error is logged:

The Web server is configured to not list the contents of this directory.

The error is usually caused by a broken deployment on the hosting system, which includes any of the following scenarios:

• The app is deployed to the wrong folder on the hosting system.
• The deployment process failed to move all of the app's files and folders to the deployment folder on the hosting system.
• The web.config file is missing from the deployment, or the web.config file contents are malformed.

Perform the following steps:

1. Delete all of the files and folders from the deployment folder on the hosting system.
2. Redeploy the contents of the app's publish folder to the hosting system using your normal method of deployment, such as Visual Studio, PowerShell, or manual deployment:
   • Confirm that the web.config file is present in the deployment and that its contents are correct.
   • When hosting on Azure App Service, confirm that the app is deployed to the D:\home\site\wwwroot folder.
   • When the app is hosted by IIS, confirm that the app is deployed to the IIS Physical path shown in IIS Manager's Basic Settings.
3. Confirm that all of the app's files and folders are deployed by comparing the deployment on the hosting system to the contents of the project's publish folder.

For more information on the layout of a published ASP.NET Core app, see ASP.NET Core directory structure. For more information on the web.config file, see ASP.NET Core Module (ANCM) for IIS.

500 Internal Server Error

The app starts, but an error prevents the server from fulfilling the request.

This error occurs within the app's code during startup or while creating a response. The response may contain no content, or the response may appear as a 500 Internal Server Error in the browser. The Application Event Log usually states that the app started normally. From the server's perspective, that's correct. The app did start, but it can't generate a valid response. Run the app at a command prompt on the server or enable the ASP.NET Core Module stdout log to troubleshoot the problem.

This error also may occur when the .NET Core Hosting Bundle isn't installed or is corrupted. Installing or repairing the installation of the .NET Core Hosting Bundle (for IIS) or Visual Studio (for IIS Express) may fix the problem.

500.0 In-Process Handler Load Failure

The worker process fails. The app doesn't start.

An unknown error occurred loading ASP.NET Core Module components. Take one of the following actions:

• Contact Microsoft Support (select Developer Tools then ASP.NET Core).
• Ask a question on Stack Overflow.
• File an issue on our GitHub repository.

500.30 In-Process Startup Failure

The worker process fails. The app doesn't start.

The ASP.NET Core Module attempts to start the .NET Core CLR in-process, but it fails to start. The cause of a process startup failure can usually be determined from entries in the Application Event Log and the ASP.NET Core Module stdout log.

Common failure conditions:

• The app is misconfigured due to targeting a version of the ASP.NET Core shared framework that isn't present. Check which versions of the ASP.NET Core shared framework are installed on the target machine.
• Using Azure Key Vault, lack of permissions to the Key Vault. Check the access policies in the targeted Key Vault to ensure that the correct permissions are granted.

500.31 ANCM Failed to Find Native Dependencies

The worker process fails. The app doesn't start.

The ASP.NET Core Module attempts to start the .NET Core runtime in-process, but it fails to start. The most common cause of this startup failure is when the Microsoft.NETCore.App or Microsoft.AspNetCore.App runtime isn't installed. If the app is deployed to target ASP.NET Core 3.0 and that version doesn't exist on the machine, this error occurs. An example error message follows:

The specified framework 'Microsoft.NETCore.App', version '3.0.0' was not found.
  - The following frameworks were found:
      2.2.1 at [C:\Program Files\dotnet\x64\shared\Microsoft.NETCore.App]
      3.0.0-preview5-27626-15 at [C:\Program Files\dotnet\x64\shared\Microsoft.NETCore.App]
      3.0.0-preview6-27713-13 at [C:\Program Files\dotnet\x64\shared\Microsoft.NETCore.App]
      3.0.0-preview6-27714-15 at [C:\Program Files\dotnet\x64\shared\Microsoft.NETCore.App]
      3.0.0-preview6-27723-08 at [C:\Program Files\dotnet\x64\shared\Microsoft.NETCore.App]

The error message lists all the installed .NET Core versions and the version requested by the app. To fix this error, either:

• Install the appropriate version of .NET Core on the machine.
• Change the app to target a version of .NET Core that's present on the machine.
• Publish the app as a self-contained deployment.

When running in development (the ASPNETCORE_ENVIRONMENT environment variable is set to Development), the specific error is written to the HTTP response. The cause of a process startup failure is also found in the Application Event Log.

500.32 ANCM Failed to Load dll

The worker process fails. The app doesn't start.

The most common cause for this error is that the app is published for an incompatible processor architecture. If the worker process is running as a 32-bit app and the app was published to target 64-bit, this error occurs.

To fix this error, either:

• Republish the app for the same processor architecture as the worker process.
• Publish the app as a framework-dependent deployment.

500.33 ANCM Request Handler Load Failure

The worker process fails. The app doesn't start.

The app didn't reference the Microsoft.AspNetCore.App framework. Only apps targeting the Microsoft.AspNetCore.App framework can be hosted by the ASP.NET Core Module.

To fix this error, confirm that the app is targeting the Microsoft.AspNetCore.App framework. Check the .runtimeconfig.json to verify the framework targeted by the app.

500.34 ANCM Mixed Hosting Models Not Supported

The worker process can't run both an in-process app and an out-of-process app in the same process.

To fix this error, run apps in separate IIS application pools.

500.35 ANCM Multiple In-Process Applications in same Process

The worker process can't run multiple in-process apps in the same process.

To fix this error, run apps in separate IIS application pools.

500.36 ANCM Out-Of-Process Handler Load Failure

The out-of-process request handler, aspnetcorev2_outofprocess.dll, isn't next to the aspnetcorev2.dll file. This indicates a corrupted installation of the ASP.NET Core Module.

To fix this error, repair the installation of the .NET Core Hosting Bundle (for IIS) or Visual Studio (for IIS Express).

500.37 ANCM Failed to Start Within Startup Time Limit

ANCM failed to start within the provided startup time limit. By default, the timeout is 120 seconds.

This error can occur when starting a large number of apps on the same machine. Check for CPU/Memory usage spikes on the server during startup. You may need to stagger the startup process of multiple apps.

500.38 ANCM Application DLL Not Found

ANCM failed to locate the application DLL, which should be next to the executable.

This error occurs when hosting an app packaged as a single-file executable using the in-process hosting model. The in-process model requires that the ANCM load the .NET Core app into the existing IIS process. This scenario isn't supported by the single-file deployment model. Use one of the following approaches in the app's project file to fix this error:

1. Disable single-file publishing by setting the PublishSingleFile MSBuild property to false.
2. Switch to the out-of-process hosting model by setting the AspNetCoreHostingModel MSBuild property to OutOfProcess.

502.5 Process Failure

The worker process fails. The app doesn't start.

The ASP.NET Core Module attempts to start the worker process but it fails to start. The cause of a process startup failure can usually be determined from entries in the Application Event Log and the ASP.NET Core Module stdout log.

A common failure condition is the app is misconfigured due to targeting a version of the ASP.NET Core shared framework that isn't present. Check which versions of the ASP.NET Core shared framework are installed on the target machine. The shared framework is the set of assemblies (.dll files) that are installed on the machine and referenced by a metapackage such as Microsoft.AspNetCore.App. The metapackage reference can specify a minimum required version. For more information, see The shared framework.

The 502.5 Process Failure error page is returned when a hosting or app misconfiguration causes the worker process to fail:

Failed to start application (ErrorCode '0x800700c1')

EventID: 1010
Source: IIS AspNetCore Module V2
Failed to start application '/LM/W3SVC/6/ROOT/', ErrorCode '0x800700c1'.

The app failed to start because the app's assembly (.dll) couldn't be loaded.

This error occurs when there's a bitness mismatch between the published app and the w3wp/iisexpress process.

Confirm that the app pool's 32-bit setting is correct:

1. Select the app pool in IIS Manager's Application Pools.
2. Select Advanced Settings under Edit Application Pool in the Actions panel.
3. Set Enable 32-Bit Applications:
   • If deploying a 32-bit (x86) app, set the value to True.
   • If deploying a 64-bit (x64) app, set the value to False.

Confirm that there isn't a conflict between a <Platform> MSBuild property in the project file and the published bitness of the app.

Failed to start application (ErrorCode '0x800701b1')

EventID: 1010
Source: IIS AspNetCore Module V2
Failed to start application '/LM/W3SVC/3/ROOT', ErrorCode '0x800701b1'.

The app failed to start because a Windows Service failed to load.

One common service that needs to be enabled is the "null" service. The following command enables the null Windows Service:

sc.exe start null

Connection reset

If an error occurs after the headers are sent, it's too late for the server to send a 500 Internal Server Error when an error occurs. This often happens when an error occurs during the serialization of complex objects for a response. This type of error appears as a connection reset error on the client. Application logging can help troubleshoot these types of errors.

Default startup limits

The ASP.NET Core Module is configured with a default startupTimeLimit of 120 seconds. When left at the default value, an app may take up to two minutes to start before the module logs a process failure. For information on configuring the module, see Attributes of the aspNetCore element.

Troubleshoot on Azure App Service

Azure App Services Log stream

The Azure App Services Log streams logging information as it occurs. To view streaming logs:

1. In the Azure portal, open the app in App Services.
2. In the left pane, navigate to Monitoring > App Service Logs.
3. Select File System for Web Server Logging. Optionally enable Application logging.
4. In the left pane, navigate to Monitoring > Log stream, and then select Application logs or Web Server Logs.

The following images shows the application logs output:

Streaming logs have some latency and might not display immediately.

Application Event Log (Azure App Service)

To access the Application Event Log, use the Diagnose and solve problems blade in the Azure portal:

1. In the Azure portal, open the app in App Services.
2. Select Diagnose and solve problems.
3. Select the Diagnostic Tools heading.
4. Under Support Tools, select the Application Events button.
5. Examine the latest error provided by the IIS AspNetCoreModule or IIS AspNetCoreModule V2 entry in the Source column.

An alternative to using the Diagnose and solve problems blade is to examine the Application Event Log file directly using Kudu:

1. Open Advanced Tools in the Development Tools area. Select the Go→ button. The Kudu console opens in a new browser tab or window.
2. Using the navigation bar at the top of the page, open Debug console and select CMD.
3. Open the LogFiles folder.
4. Select the pencil icon next to the eventlog.xml file.
5. Examine the log. Scroll to the bottom of the log to see the most recent events.

Run the app in the Kudu console

Many startup errors don't produce useful information in the Application Event Log. You can run the app in the Kudu Remote Execution Console to discover the error:

1. Open Advanced Tools in the Development Tools area. Select the Go→ button. The Kudu console opens in a new browser tab or window.
2. Using the navigation bar at the top of the page, open Debug console and select CMD.

Test a 32-bit (x86) app

Current release

1. cd d:\home\site\wwwroot
2. Run the app:

   • If the app is a framework-dependent deployment:

     dotnet .\{ASSEMBLY NAME}.dll
     

   • If the app is a self-contained deployment:

     {ASSEMBLY NAME}.exe
     

The console output from the app, showing any errors, is piped to the Kudu console.

Framework-dependent deployment running on a preview release

Requires installing the ASP.NET Core {VERSION} (x86) Runtime site extension.

1. cd D:\home\SiteExtensions\AspNetCoreRuntime.{X.Y}.x32 ({X.Y} is the runtime version)
2. Run the app: dotnet \home\site\wwwroot\{ASSEMBLY NAME}.dll

The console output from the app, showing any errors, is piped to the Kudu console.

Test a 64-bit (x64) app

Current release

• If the app is a 64-bit (x64) framework-dependent deployment:
  1. cd D:\Program Files\dotnet
  2. Run the app: dotnet \home\site\wwwroot\{ASSEMBLY NAME}.dll
• If the app is a self-contained deployment:
  1. cd D:\home\site\wwwroot
  2. Run the app: {ASSEMBLY NAME}.exe

The console output from the app, showing any errors, is piped to the Kudu console.

Framework-dependent deployment running on a preview release

Requires installing the ASP.NET Core {VERSION} (x64) Runtime site extension.

1. cd D:\home\SiteExtensions\AspNetCoreRuntime.{X.Y}.x64 ({X.Y} is the runtime version)
2. Run the app: dotnet \home\site\wwwroot\{ASSEMBLY NAME}.dll

The console output from the app, showing any errors, is piped to the Kudu console.

ASP.NET Core Module stdout log (Azure App Service)

The ASP.NET Core Module stdout log often records useful error messages not found in the Application Event Log. To enable and view stdout logs:

1. In the Azure Portal, navigate to the web app.
2. In the App Service blade, enter kudu in the search box.
3. Select Advanced Tools > Go.
4. Select Debug console > CMD.
5. Navigate to site/wwwroot
6. Select the pencil icon to edit the web.config file.
7. In the <aspNetCore /> element, set stdoutLogEnabled="true" and select Save.

Disable stdout logging when troubleshooting is complete by setting stdoutLogEnabled="false".

For more information, see ASP.NET Core Module (ANCM) for IIS.

ASP.NET Core Module debug log (Azure App Service)

The ASP.NET Core Module debug log provides additional, deeper logging from the ASP.NET Core Module. To enable and view stdout logs:

1. To enable the enhanced diagnostic log, perform either of the following:
   • Follow the instructions in Enhanced diagnostic logs to configure the app for an enhanced diagnostic logging. Redeploy the app.
   • Add the <handlerSettings> shown in Enhanced diagnostic logs to the live app's web.config file using the Kudu console:
     1. Open Advanced Tools in the Development Tools area. Select the Go→ button. The Kudu console opens in a new browser tab or window.
     2. Using the navigation bar at the top of the page, open Debug console and select CMD.
     3. Open the folders to the path site > wwwroot. Edit the web.config file by selecting the pencil button. Add the <handlerSettings> section as shown in Enhanced diagnostic logs. Select the Save button.
2. Open Advanced Tools in the Development Tools area. Select the Go→ button. The Kudu console opens in a new browser tab or window.
3. Using the navigation bar at the top of the page, open Debug console and select CMD.
4. Open the folders to the path site > wwwroot. If you didn't supply a path for the aspnetcore-debug.log file, the file appears in the list. If you supplied a path, navigate to the location of the log file.
5. Open the log file with the pencil button next to the file name.

Disable debug logging when troubleshooting is complete:

To disable the enhanced debug log, perform either of the following:

• Remove the <handlerSettings> from the web.config file locally and redeploy the app.
• Use the Kudu console to edit the web.config file and remove the <handlerSettings> section. Save the file.

For more information, see Log creation and redirection with the ASP.NET Core Module.

Slow or hanging app (Azure App Service)

When an app responds slowly or hangs on a request, see Troubleshoot slow web app performance issues in Azure App Service.

Monitoring blades

Monitoring blades provide an alternative troubleshooting experience to the methods described earlier in the topic. These blades can be used to diagnose 500-series errors.

Confirm that the ASP.NET Core Extensions are installed. If the extensions aren't installed, install them manually:

1. In the DEVELOPMENT TOOLS blade section, select the Extensions blade.
2. The ASP.NET Core Extensions should appear in the list.
3. If the extensions aren't installed, select the Add button.
4. Choose the ASP.NET Core Extensions from the list.
5. Select OK to accept the legal terms.
6. Select OK on the Add extension blade.
7. An informational pop-up message indicates when the extensions are successfully installed.

If stdout logging isn't enabled, follow these steps:

1. In the Azure portal, select the Advanced Tools blade in the DEVELOPMENT TOOLS area. Select the Go→ button. The Kudu console opens in a new browser tab or window.
2. Using the navigation bar at the top of the page, open Debug console and select CMD.
3. Open the folders to the path site > wwwroot and scroll down to reveal the web.config file at the bottom of the list.
4. Click the pencil icon next to the web.config file.
5. Set stdoutLogEnabled to true and change the stdoutLogFile path to: \\?\%home%\LogFiles\stdout.
6. Select Save to save the updated web.config file.

Proceed to activate diagnostic logging:

1. In the Azure portal, select the Diagnostics logs blade.
2. Select the On switch for Application Logging (Filesystem) and Detailed error messages. Select the Save button at the top of the blade.
3. To include failed request tracing, also known as Failed Request Event Buffering (FREB) logging, select the On switch for Failed request tracing.
4. Select the Log stream blade, which is listed immediately under the Diagnostics logs blade in the portal.
5. Make a request to the app.
6. Within the log stream data, the cause of the error is indicated.

Be sure to disable stdout logging when troubleshooting is complete.

To view the failed request tracing logs (FREB logs):

1. Navigate to the Diagnose and solve problems blade in the Azure portal.
2. Select Failed Request Tracing Logs from the SUPPORT TOOLS area of the sidebar.

See Failed request traces section of the Enable diagnostics logging for web apps in Azure App Service topic and the Application performance FAQs for Web Apps in Azure: How do I turn on failed request tracing? for more information.

For more information, see Enable diagnostics logging for web apps in Azure App Service.

Troubleshoot on IIS

Application Event Log (IIS)

Access the Application Event Log:

1. Open the Start menu, search for Event Viewer, and select the Event Viewer app.
2. In Event Viewer, open the Windows Logs node.
3. Select Application to open the Application Event Log.
4. Search for errors associated with the failing app. Errors have a value of IIS AspNetCore Module or IIS Express AspNetCore Module in the Source column.

Run the app at a command prompt

Many startup errors don't produce useful information in the Application Event Log. You can find the cause of some errors by running the app at a command prompt on the hosting system.

Framework-dependent deployment

If the app is a framework-dependent deployment:

1. At a command prompt, navigate to the deployment folder and run the app by executing the app's assembly with dotnet.exe. In the following command, substitute the name of the app's assembly for <assembly_name>: dotnet .\<assembly_name>.dll.
2. The console output from the app, showing any errors, is written to the console window.
3. If the errors occur when making a request to the app, make a request to the host and port where Kestrel listens. Using the default host and post, make a request to http://localhost:5000/. If the app responds normally at the Kestrel endpoint address, the problem is more likely related to the hosting configuration and less likely within the app.

Self-contained deployment

If the app is a self-contained deployment:

1. At a command prompt, navigate to the deployment folder and run the app's executable. In the following command, substitute the name of the app's assembly for <assembly_name>: <assembly_name>.exe.
2. The console output from the app, showing any errors, is written to the console window.
3. If the errors occur when making a request to the app, make a request to the host and port where Kestrel listens. Using the default host and post, make a request to http://localhost:5000/. If the app responds normally at the Kestrel endpoint address, the problem is more likely related to the hosting configuration and less likely within the app.

ASP.NET Core Module stdout log (IIS)

To enable and view stdout logs:

1. Navigate to the site's deployment folder on the hosting system.
2. If the logs folder isn't present, create the folder. For instructions on how to enable MSBuild to create the logs folder in the deployment automatically, see the Directory structure topic.
3. Edit the web.config file. Set stdoutLogEnabled to true and change the stdoutLogFile path to point to the logs folder (for example, .\logs\stdout). stdout in the path is the log file name prefix. A timestamp, process id, and file extension are added automatically when the log is created. Using stdout as the file name prefix, a typical log file is named stdout_20180205184032_5412.log.
4. Ensure your application pool's identity has write permissions to the logs folder.
5. Save the updated web.config file.
6. Make a request to the app.
7. Navigate to the logs folder. Find and open the most recent stdout log.
8. Study the log for errors.

Disable stdout logging when troubleshooting is complete:

1. Edit the web.config file.
2. Set stdoutLogEnabled to false.
3. Save the file.

For more information, see ASP.NET Core Module (ANCM) for IIS.

ASP.NET Core Module debug log (IIS)

Add the following handler settings to the app's web.config file to enable ASP.NET Core Module debug log:

<aspNetCore ...>
  <handlerSettings>
    <handlerSetting name="debugLevel" value="file" />
    <handlerSetting name="debugFile" value="c:\temp\ancm.log" />
  </handlerSettings>
</aspNetCore>

Confirm that the path specified for the log exists and that the app pool's identity has write permissions to the location.

For more information, see Log creation and redirection with the ASP.NET Core Module.

Enable the Developer Exception Page

The ASPNETCORE_ENVIRONMENT environment variable can be added to web.config to run the app in the Development environment. As long as the environment isn't overridden in app startup by UseEnvironment on the host builder, setting the environment variable allows the Developer Exception Page to appear when the app is run.

<aspNetCore processPath="dotnet"
      arguments=".\MyApp.dll"
      stdoutLogEnabled="false"
      stdoutLogFile=".\logs\stdout"
      hostingModel="InProcess">
  <environmentVariables>
    <environmentVariable name="ASPNETCORE_ENVIRONMENT" value="Development" />
  </environmentVariables>
</aspNetCore>

Setting the environment variable for ASPNETCORE_ENVIRONMENT is only recommended for use on staging and testing servers that aren't exposed to the Internet. Remove the environment variable from the web.config file after troubleshooting. For information on setting environment variables in web.config, see environmentVariables child element of aspNetCore.

Obtain data from an app

If an app is capable of responding to requests, obtain request, connection, and additional data from the app using terminal inline middleware. For more information and sample code, see Troubleshoot and debug ASP.NET Core projects.

Slow or hanging app (IIS)

A crash dump is a snapshot of the system's memory and can help determine the cause of an app crash, startup failure, or slow app.

App crashes or encounters an exception

Obtain and analyze a dump from Windows Error Reporting (WER):

1. Create a folder to hold crash dump files at c:\dumps. The app pool must have write access to the folder.

2. Run the EnableDumps PowerShell script:

   • If the app uses the in-process hosting model, run the script for w3wp.exe:

     .\EnableDumps w3wp.exe c:\dumps
     

   • If the app uses the out-of-process hosting model, run the script for dotnet.exe:

     .\EnableDumps dotnet.exe c:\dumps
     

3. Run the app under the conditions that cause the crash to occur.

4. After the crash has occurred, run the DisableDumps PowerShell script:

   • If the app uses the in-process hosting model, run the script for w3wp.exe:

     .\DisableDumps w3wp.exe
     

   • If the app uses the out-of-process hosting model, run the script for dotnet.exe:

     .\DisableDumps dotnet.exe
     

After an app crashes and dump collection is complete, the app is allowed to terminate normally. The PowerShell script configures WER to collect up to five dumps per app.

App hangs, fails during startup, or runs normally

When an app hangs (stops responding but doesn't crash), fails during startup, or runs normally, see User-Mode Dump Files: Choosing the Best Tool to select an appropriate tool to produce the dump.

Analyze the dump

A dump can be analyzed using several approaches. For more information, see Analyzing a User-Mode Dump File.

Clear package caches

A functioning app may fail immediately after upgrading either the .NET Core SDK on the development machine or changing package versions within the app. In some cases, incoherent packages may break an app when performing major upgrades. Most of these issues can be fixed by following these instructions:

1. Delete the bin and obj folders.

2. Clear the package caches by executing dotnet nuget locals all --clear from a command shell.

   Clearing package caches can also be accomplished with the nuget.exe tool and executing the command nuget locals all -clear. nuget.exe isn't a bundled install with the Windows desktop operating system and must be obtained separately from the NuGet website.

3. Restore and rebuild the project.

4. Delete all of the files in the deployment folder on the server prior to redeploying the app.

Collect status codes and log entries

When an ASP.NET Core app running on IIS encounters an error, collect information to help diagnose the issue. The following information is useful for troubleshooting: Collect the following information:

• Browser behavior such as status code and error message.
• Application Event Log entries
  • Azure App Service: See Troubleshoot ASP.NET Core on Azure App Service and IIS.
  • IIS
    1. Select Start on the Windows menu, type Event Viewer, and press Enter.
    2. After the Event Viewer opens, expand Windows Logs > Application in the sidebar.
• ASP.NET Core Module stdout and debug log entries
  • Azure App Service: See Troubleshoot ASP.NET Core on Azure App Service and IIS.
  • IIS: Follow the instructions in the Log creation and redirection and Enhanced diagnostic logs sections of the ASP.NET Core Module topic.

Compare error information to the following common errors. If a match is found, follow the troubleshooting advice.

The list of errors in this topic isn't exhaustive. If you encounter an error not listed here, open a new issue using the Content feedback button at the bottom of this topic with detailed instructions on how to reproduce the error.

OS upgrade removed the 32-bit ASP.NET Core Module

Application Log: The Module DLL C:\WINDOWS\system32\inetsrv\aspnetcore.dll failed to load. The data is the error.

Troubleshooting:

Non-OS files in the C:\Windows\SysWOW64\inetsrv directory aren't preserved during an OS upgrade. If the ASP.NET Core Module is installed prior to an OS upgrade and then any app pool is run in 32-bit mode after an OS upgrade, this issue is encountered. After an OS upgrade, repair the ASP.NET Core Module. See Install the .NET Core Hosting bundle. Select Repair when the installer is run.

Missing site extension, 32-bit (x86) and 64-bit (x64) site extensions installed, or wrong process bitness set

Applies to apps hosted by Azure App Services.

• Browser: HTTP Error 500.0 - ANCM In-Process Handler Load Failure

• Application Log: Invoking hostfxr to find the inprocess request handler failed without finding any native dependencies. Could not find inprocess request handler. Captured output from invoking hostfxr: It was not possible to find any compatible framework version. The specified framework 'Microsoft.AspNetCore.App', version '{VERSION}-preview-*' was not found. Failed to start application '/LM/W3SVC/1416782824/ROOT', ErrorCode '0x8000ffff'.

• ASP.NET Core Module stdout Log: It was not possible to find any compatible framework version. The specified framework 'Microsoft.AspNetCore.App', version '{VERSION}-preview-*' was not found.

• ASP.NET Core Module Debug Log: Invoking hostfxr to find the inprocess request handler failed without finding any native dependencies. This most likely means the app is misconfigured, please check the versions of Microsoft.NetCore.App and Microsoft.AspNetCore.App that are targeted by the application and are installed on the machine. Failed HRESULT returned: 0x8000ffff. Could not find inprocess request handler. It was not possible to find any compatible framework version. The specified framework 'Microsoft.AspNetCore.App', version '{VERSION}-preview-*' was not found.

Troubleshooting:

• If running the app on a preview runtime, install either the 32-bit (x86) or 64-bit (x64) site extension that matches the bitness of the app and the app's runtime version. Don't install both extensions or multiple runtime versions of the extension.

  • ASP.NET Core {RUNTIME VERSION} (x86) Runtime
  • ASP.NET Core {RUNTIME VERSION} (x64) Runtime

  Restart the app. Wait several seconds for the app to restart.

• If running the app on a preview runtime and both the 32-bit (x86) and 64-bit (x64) site extensions are installed, uninstall the site extension that doesn't match the bitness of the app. After removing the site extension, restart the app. Wait several seconds for the app to restart.

• If running the app on a preview runtime and the site extension's bitness matches that of the app, confirm that the preview site extension's runtime version matches the app's runtime version.

• Confirm that the app's Platform in Application Settings matches the bitness of the app.

For more information, see Deploy ASP.NET Core apps to Azure App Service.

An x86 app is deployed but the app pool isn't enabled for 32-bit apps

• Browser: HTTP Error 500.30 - ANCM In-Process Start Failure

• Application Log: Application '/LM/W3SVC/5/ROOT' with physical root '{PATH}' hit unexpected managed exception, exception code = '0xe0434352'. Please check the stderr logs for more information. Application '/LM/W3SVC/5/ROOT' with physical root '{PATH}' failed to load clr and managed application. CLR worker thread exited prematurely

• ASP.NET Core Module stdout Log: The log file is created but empty.

• ASP.NET Core Module Debug Log: Failed HRESULT returned: 0x8007023e

This scenario is trapped by the SDK when publishing a self-contained app. The SDK produces an error if the RID doesn't match the platform target (for example, win10-x64 RID with <PlatformTarget>x86</PlatformTarget> in the project file).

Troubleshooting:

For an x86 framework-dependent deployment (<PlatformTarget>x86</PlatformTarget>), enable the IIS app pool for 32-bit apps. In IIS Manager, open the app pool's Advanced Settings and set Enable 32-Bit Applications to True.

Platform conflicts with RID

• Browser: HTTP Error 502.5 - Process Failure

• Application Log: Application 'MACHINE/WEBROOT/APPHOST/{ASSEMBLY}' with physical root 'C:{PATH}' failed to start process with commandline '"C:{PATH}{ASSEMBLY}.{exe|dll}" ', ErrorCode = '0x80004005 : ff.

• ASP.NET Core Module stdout Log: Unhandled Exception: System.BadImageFormatException: Could not load file or assembly '{ASSEMBLY}.dll'. An attempt was made to load a program with an incorrect format.

Troubleshooting:

• Confirm that the app runs locally on Kestrel. A process failure might be the result of a problem within the app. For more information, see Troubleshoot ASP.NET Core on Azure App Service and IIS.

• If this exception occurs for an Azure Apps deployment when upgrading an app and deploying newer assemblies, manually delete all files from the prior deployment. Lingering incompatible assemblies can result in a System.BadImageFormatException exception when deploying an upgraded app.

URI endpoint wrong or stopped website

• Browser: ERR_CONNECTION_REFUSED --OR-- Unable to connect

• Application Log: No entry

• ASP.NET Core Module stdout Log: The log file isn't created.

• ASP.NET Core Module Debug Log: The log file isn't created.

Troubleshooting:

• Confirm the correct URI endpoint for the app is in use. Check the bindings.

• Confirm that the IIS website isn't in the Stopped state.

CoreWebEngine or W3SVC server features disabled

OS Exception: The IIS 7.0 CoreWebEngine and W3SVC features must be installed to use the ASP.NET Core Module.

Troubleshooting:

Confirm that the proper role and features are enabled. See IIS Configuration.

Incorrect website physical path or app missing

• Browser: 403 Forbidden - Access is denied --OR-- 403.14 Forbidden - The Web server is configured to not list the contents of this directory.

• Application Log: No entry

• ASP.NET Core Module stdout Log: The log file isn't created.

• ASP.NET Core Module Debug Log: The log file isn't created.

Troubleshooting:

Check the IIS website Basic Settings and the physical app folder. Confirm that the app is in the folder at the IIS website Physical path.

Incorrect role, ASP.NET Core Module not installed, or incorrect permissions

• Browser: 500.19 Internal Server Error - The requested page cannot be accessed because the related configuration data for the page is invalid. --OR-- This page can't be displayed

• Application Log: No entry

• ASP.NET Core Module stdout Log: The log file isn't created.

• ASP.NET Core Module Debug Log: The log file isn't created.

Troubleshooting:

• Confirm that the proper role is enabled. See IIS Configuration.

• Open Programs & Features or Apps & features and confirm that Windows Server Hosting is installed. If Windows Server Hosting isn't present in the list of installed programs, download and install the .NET Core Hosting Bundle.

  Current .NET Core Hosting Bundle installer (direct download)

  For more information, see Install the .NET Core Hosting Bundle.

• Make sure that the Application Pool > Process Model > Identity is set to ApplicationPoolIdentity or the custom identity has the correct permissions to access the app's deployment folder.

• If you uninstalled the ASP.NET Core Hosting Bundle and installed an earlier version of the hosting bundle, the applicationHost.config file doesn't include a section for the ASP.NET Core Module. Open applicationHost.config at %windir%/System32/inetsrv/config and find the <configuration><configSections><sectionGroup name="system.webServer"> section group. If the section for the ASP.NET Core Module is missing from the section group, add the section element:

  <section name="aspNetCore" overrideModeDefault="Allow" />
  

  Alternatively, install the latest version of the ASP.NET Core Hosting Bundle. The latest version is backwards-compatible with supported ASP.NET Core apps.

Incorrect processPath, missing PATH variable, Hosting Bundle not installed, system/IIS not restarted, VC++ Redistributable not installed, or dotnet.exe access violation

• Browser: HTTP Error 500.0 - ANCM In-Process Handler Load Failure

• Application Log: Application 'MACHINE/WEBROOT/APPHOST/{ASSEMBLY}' with physical root 'C:{PATH}' failed to start process with commandline '"{...}" ', ErrorCode = '0x80070002 : 0. Application '{PATH}' wasn't able to start. Executable was not found at '{PATH}'. Failed to start application '/LM/W3SVC/2/ROOT', ErrorCode '0x8007023e'.

• ASP.NET Core Module stdout Log: The log file isn't created.

• ASP.NET Core Module Debug Log: Event Log: 'Application '{PATH}' wasn't able to start. Executable was not found at '{PATH}'. Failed HRESULT returned: 0x8007023e

Troubleshooting:

• Confirm that the app runs locally on Kestrel. A process failure might be the result of a problem within the app. For more information, see Troubleshoot ASP.NET Core on Azure App Service and IIS.

• Check the processPath attribute on the <aspNetCore> element in web.config to confirm that it's dotnet for a framework-dependent deployment (FDD) or .\{ASSEMBLY}.exe for a self-contained deployment (SCD).

• For an FDD, dotnet.exe might not be accessible via the PATH settings. Confirm that C:\Program Files\dotnet\ exists in the System PATH settings.

• For an FDD, dotnet.exe might not be accessible for the user identity of the app pool. Confirm that the app pool user identity has access to the C:\Program Files\dotnet directory. Confirm that there are no deny rules configured for the app pool user identity on the C:\Program Files\dotnet and app directories.

• An FDD may have been deployed and .NET Core installed without restarting IIS. Either restart the server or restart IIS by executing net stop was /y followed by net start w3svc from a command prompt.

• An FDD may have been deployed without installing the .NET Core runtime on the hosting system. If the .NET Core runtime hasn't been installed, run the .NET Core Hosting Bundle installer on the system.

  Current .NET Core Hosting Bundle installer (direct download)

  For more information, see Install the .NET Core Hosting Bundle.

  If a specific runtime is required, download the runtime from the .NET Downloads page and install it on the system. Complete the installation by restarting the system or restarting IIS by executing net stop was /y followed by net start w3svc from a command prompt.

Incorrect arguments of <aspNetCore> element

• Browser: HTTP Error 500.0 - ANCM In-Process Handler Load Failure

• Application Log: Invoking hostfxr to find the inprocess request handler failed without finding any native dependencies. This most likely means the app is misconfigured, please check the versions of Microsoft.NetCore.App and Microsoft.AspNetCore.App that are targeted by the application and are installed on the machine. Could not find inprocess request handler. Captured output from invoking hostfxr: Did you mean to run dotnet SDK commands? Please install dotnet SDK from: https://go.microsoft.com/fwlink/?LinkID=798306&clcid=0x409 Failed to start application '/LM/W3SVC/3/ROOT', ErrorCode '0x8000ffff'.

• ASP.NET Core Module stdout Log: Did you mean to run dotnet SDK commands? Please install dotnet SDK from: https://go.microsoft.com/fwlink/?LinkID=798306&clcid=0x409

• ASP.NET Core Module Debug Log: Invoking hostfxr to find the inprocess request handler failed without finding any native dependencies. This most likely means the app is misconfigured, please check the versions of Microsoft.NetCore.App and Microsoft.AspNetCore.App that are targeted by the application and are installed on the machine. Failed HRESULT returned: 0x8000ffff Could not find inprocess request handler. Captured output from invoking hostfxr: Did you mean to run dotnet SDK commands? Please install dotnet SDK from: https://go.microsoft.com/fwlink/?LinkID=798306&clcid=0x409 Failed HRESULT returned: 0x8000ffff

Troubleshooting:

• Confirm that the app runs locally on Kestrel. A process failure might be the result of a problem within the app. For more information, see Troubleshoot ASP.NET Core on Azure App Service and IIS.

• Examine the arguments attribute on the <aspNetCore> element in web.config to confirm that it's either (a) .\{ASSEMBLY}.dll for a framework-dependent deployment (FDD); or (b) not present, an empty string (arguments=""), or a list of the app's arguments (arguments="{ARGUMENT_1}, {ARGUMENT_2}, ... {ARGUMENT_X}") for a self-contained deployment (SCD).

Missing .NET Core shared framework

• Browser: HTTP Error 500.0 - ANCM In-Process Handler Load Failure

• Application Log: Invoking hostfxr to find the inprocess request handler failed without finding any native dependencies. This most likely means the app is misconfigured, please check the versions of Microsoft.NetCore.App and Microsoft.AspNetCore.App that are targeted by the application and are installed on the machine. Could not find inprocess request handler. Captured output from invoking hostfxr: It was not possible to find any compatible framework version. The specified framework 'Microsoft.AspNetCore.App', version '{VERSION}' was not found.

Failed to start application '/LM/W3SVC/5/ROOT', ErrorCode '0x8000ffff'.

• ASP.NET Core Module stdout Log: It was not possible to find any compatible framework version. The specified framework 'Microsoft.AspNetCore.App', version '{VERSION}' was not found.

• ASP.NET Core Module Debug Log: Failed HRESULT returned: 0x8000ffff

Troubleshooting:

For a framework-dependent deployment (FDD), confirm that the correct runtime installed on the system.

Stopped Application Pool

• Browser: 503 Service Unavailable

• Application Log: No entry

• ASP.NET Core Module stdout Log: The log file isn't created.

• ASP.NET Core Module Debug Log: The log file isn't created.

Troubleshooting:

Confirm that the Application Pool isn't in the Stopped state.

Sub-application includes a <handlers> section

• Browser: HTTP Error 500.19 - Internal Server Error

• Application Log: No entry

• ASP.NET Core Module stdout Log: The root app's log file is created and shows normal operation. The sub-app's log file isn't created.

• ASP.NET Core Module Debug Log: The root app's log file is created and shows normal operation. The sub-app's log file isn't created.

Troubleshooting:

Confirm that the sub-app's web.config file doesn't include a <handlers> section or that the sub-app doesn't inherit the parent app's handlers.

The parent app's <system.webServer> section of web.config is placed inside of a <location> element. The InheritInChildApplications property is set to false to indicate that the settings specified within the <location> element aren't inherited by apps that reside in a subdirectory of the parent app. For more information, see ASP.NET Core Module (ANCM) for IIS.

stdout log path incorrect

• Browser: The app responds normally.

• Application Log: Could not start stdout redirection in C:\Program Files\IIS\Asp.Net Core Module\V2\aspnetcorev2.dll. Exception message: HRESULT 0x80070005 returned at {PATH}\aspnetcoremodulev2\commonlib\fileoutputmanager.cpp:84. Could not stop stdout redirection in C:\Program Files\IIS\Asp.Net Core Module\V2\aspnetcorev2.dll. Exception message: HRESULT 0x80070002 returned at {PATH}. Could not start stdout redirection in {PATH}\aspnetcorev2_inprocess.dll.

• ASP.NET Core Module stdout Log: The log file isn't created.

• ASP.NET Core Module debug Log: Could not start stdout redirection in C:\Program Files\IIS\Asp.Net Core Module\V2\aspnetcorev2.dll. Exception message: HRESULT 0x80070005 returned at {PATH}\aspnetcoremodulev2\commonlib\fileoutputmanager.cpp:84. Could not stop stdout redirection in C:\Program Files\IIS\Asp.Net Core Module\V2\aspnetcorev2.dll. Exception message: HRESULT 0x80070002 returned at {PATH}. Could not start stdout redirection in {PATH}\aspnetcorev2_inprocess.dll.

Troubleshooting:

• The stdoutLogFile path specified in the <aspNetCore> element of web.config doesn't exist. For more information, see ASP.NET Core Module: Log creation and redirection.

• The app pool user doesn't have write access to the stdout log path.

Application configuration general issue

• Browser: HTTP Error 500.0 - ANCM In-Process Handler Load Failure --OR-- HTTP Error 500.30 - ANCM In-Process Start Failure

• Application Log: Variable

• ASP.NET Core Module stdout Log: The log file is created but empty or created with normal entries until the point of the app failing.

• ASP.NET Core Module Debug Log: Variable

Troubleshooting:

The process failed to start, most likely due to an app configuration or programming issue.

For more information, see the following topics:

• Troubleshoot ASP.NET Core on Azure App Service and IIS
• Troubleshoot and debug ASP.NET Core projects

Additional resources

• Debug .NET and ASP.NET Core source code with Visual Studio
• Troubleshoot and debug ASP.NET Core projects
• Handle errors in ASP.NET Core
• ASP.NET Core Module (ANCM) for IIS

Azure documentation

• Application Insights for ASP.NET Core
• Remote debugging web apps section of Troubleshoot a web app in Azure App Service using Visual Studio
• Azure App Service diagnostics overview
• How to: Monitor Apps in Azure App Service
• Troubleshoot a web app in Azure App Service using Visual Studio
• Troubleshoot HTTP errors of "502 bad gateway" and "503 service unavailable" in your Azure web apps
• Troubleshoot slow web app performance issues in Azure App Service
• Application performance FAQs for Web Apps in Azure
• Azure Web App sandbox (App Service runtime execution limitations)

Visual Studio documentation

• Remote Debug ASP.NET Core on IIS in Azure in Visual Studio 2017
• Remote Debug ASP.NET Core on a Remote IIS Computer in Visual Studio 2017
• Learn to debug using Visual Studio

Visual Studio Code documentation

• Debugging with Visual Studio Code