Lỗi the project has been corrupted trên visual studio 2023 năm 2024
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support. Show
Troubleshoot ASP.NET Core on Azure App Service and IIS
In this articleBy Justin Kotalik 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: Explains common startup HTTP status code scenarios. Provides troubleshooting advice for apps deployed to Azure App Service. 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. Explains what to do when incoherent packages break an app when performing major upgrades or changing package versions. Lists additional troubleshooting topics. App startup errorsIn 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 ForbiddenThe app fails to start. The following error is logged:
The error is usually caused by a broken deployment on the hosting system, which includes any of the following scenarios:
Perform the following steps:
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 . 500 Internal Server ErrorThe 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 FailureThe worker process fails. The app doesn't start. An unknown error occurred loading ASP.NET Core Module components. Take one of the following actions:
500.30 In-Process Startup FailureThe 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:
500.31 ANCM Failed to Find Native DependenciesThe 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
3 or
4 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 error message lists all the installed .NET Core versions and the version requested by the app. To fix this error, either:
When running in development (the
5 environment variable is set to
6), 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 dllThe 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:
500.33 ANCM Request Handler Load FailureThe worker process fails. The app doesn't start. The app didn't reference the
4 framework. Only apps targeting the
4 framework can be hosted by the ASP.NET Core Module. To fix this error, confirm that the app is targeting the
4 framework. Check the
0 to verify the framework targeted by the app. 500.34 ANCM Mixed Hosting Models Not SupportedThe 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 ProcessThe 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 FailureThe 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 (for IIS) or Visual Studio (for IIS Express). 500.37 ANCM Failed to Start Within Startup Time LimitANCM 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 FoundANCM failed to locate the application DLL, which should be next to the executable. This error occurs when hosting an app packaged as a 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:
502.5 Process FailureThe 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
4. 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')
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:
Confirm that there isn't a conflict between a
8 MSBuild property in the project file and the published bitness of the app. Failed to start application (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
9 Windows Service:
Connection resetIf 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 limitsThe 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 . Troubleshoot on Azure App ServiceAzure App Services Log streamThe Azure App Services Log streams logging information as it occurs. To view streaming 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:
An alternative to using the Diagnose and solve problems blade is to examine the Application Event Log file directly using Kudu:
Run the app in the Kudu consoleMany 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:
Test a 32-bit (x86) appCurrent release
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.
The console output from the app, showing any errors, is piped to the Kudu console. Test a 64-bit (x64) appCurrent release
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.
The console output from the app, showing any errors, is piped to the Kudu console. ASP.NET Core Module stdout log (Azure App Service)Warning Failure to disable the stdout log can lead to app or server failure. There's no limit on log file size or the number of log files created. Only use stdout logging to troubleshoot app startup problems. For general logging in an ASP.NET Core app after startup, use a logging library that limits log file size and rotates logs. For more information, see . 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:
Disable stdout logging when troubleshooting is complete by setting
4. For more information, see . 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:
Disable debug logging when troubleshooting is complete: To disable the enhanced debug log, perform either of the following:
For more information, see . Warning Failure to disable the debug log can lead to app or server failure. There's no limit on log file size. Only use debug logging to troubleshoot app startup problems. For general logging in an ASP.NET Core app after startup, use a logging library that limits log file size and rotates logs. For more information, see . 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 bladesMonitoring 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:
If stdout logging isn't enabled, follow these steps:
Proceed to activate diagnostic logging:
Be sure to disable stdout logging when troubleshooting is complete. To view the failed request tracing logs (FREB logs):
See and the for more information. For more information, see Enable diagnostics logging for web apps in Azure App Service. Warning Failure to disable the stdout log can lead to app or server failure. There's no limit on log file size or the number of log files created. For routine logging in an ASP.NET Core app, use a logging library that limits log file size and rotates logs. For more information, see . Troubleshoot on IISApplication Event Log (IIS)Access the Application Event Log:
Run the app at a command promptMany 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 deploymentIf the app is a :
Self-contained deploymentIf the app is a :
ASP.NET Core Module stdout log (IIS)To enable and view stdout logs:
Disable stdout logging when troubleshooting is complete:
For more information, see . Warning Failure to disable the stdout log can lead to app or server failure. There's no limit on log file size or the number of log files created. For routine logging in an ASP.NET Core app, use a logging library that limits log file size and rotates logs. For more information, see . 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:
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 . Enable the Developer Exception PageThe
5 to run the app in the Development environment. As long as the environment isn't overridden in app startup by
1 on the host builder, setting the environment variable allows the Developer Exception Page to appear when the app is run.
Setting the environment variable for
5 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 . Obtain data from an appIf 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 . 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 exceptionObtain and analyze a dump from Windows Error Reporting (WER):
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. Warning Crash dumps might take up a large amount of disk space (up to several gigabytes each). App hangs, fails during startup, or runs normallyWhen an app hangs (stops responding but doesn't crash), fails during startup, or runs normally, see to select an appropriate tool to produce the dump. Analyze the dumpA dump can be analyzed using several approaches. For more information, see Analyzing a User-Mode Dump File. Clear package cachesA 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:
Additional resources
Azure documentation
Visual Studio documentation
Visual Studio Code documentation
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: Explains common startup HTTP status code scenarios. Provides troubleshooting advice for apps deployed to Azure App Service. 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. Explains what to do when incoherent packages break an app when performing major upgrades or changing package versions. Lists additional troubleshooting topics. App startup errorsIn 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 ForbiddenThe app fails to start. The following error is logged:
The error is usually caused by a broken deployment on the hosting system, which includes any of the following scenarios:
Perform the following steps:
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 . 500 Internal Server ErrorThe 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 FailureThe 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:
500.0 Out-Of-Process Handler Load FailureThe 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 FailureThe 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
4. 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')
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:
Confirm that there isn't a conflict between a
8 MSBuild property in the project file and the published bitness of the app. Connection resetIf 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 limitsThe 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 . Troubleshoot on Azure App ServiceApplication Event Log (Azure App Service)To access the Application Event Log, use the Diagnose and solve problems blade in the Azure portal:
An alternative to using the Diagnose and solve problems blade is to examine the Application Event Log file directly using Kudu:
Run the app in the Kudu consoleMany 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:
Test a 32-bit (x86) appCurrent release
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.
The console output from the app, showing any errors, is piped to the Kudu console. Test a 64-bit (x64) appCurrent release
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.
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:
Disable stdout logging when troubleshooting is complete:
For more information, see . Warning Failure to disable the stdout log can lead to app or server failure. There's no limit on log file size or the number of log files created. Only use stdout logging to troubleshoot app startup problems. For general logging in an ASP.NET Core app after startup, use a logging library that limits log file size and rotates logs. For more information, see . 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:
Disable debug logging when troubleshooting is complete: To disable the enhanced debug log, perform either of the following:
For more information, see . Warning Failure to disable the debug log can lead to app or server failure. There's no limit on log file size. Only use debug logging to troubleshoot app startup problems. For general logging in an ASP.NET Core app after startup, use a logging library that limits log file size and rotates logs. For more information, see . Slow or hanging app (Azure App Service)When an app responds slowly or hangs on a request, see the following articles:
Monitoring bladesMonitoring 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:
If stdout logging isn't enabled, follow these steps:
Proceed to activate diagnostic logging:
Be sure to disable stdout logging when troubleshooting is complete. To view the failed request tracing logs (FREB logs):
See and the for more information. For more information, see Enable diagnostics logging for web apps in Azure App Service. Warning Failure to disable the stdout log can lead to app or server failure. There's no limit on log file size or the number of log files created. For routine logging in an ASP.NET Core app, use a logging library that limits log file size and rotates logs. For more information, see . Troubleshoot on IISApplication Event Log (IIS)Access the Application Event Log:
Run the app at a command promptMany 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 deploymentIf the app is a :
Self-contained deploymentIf the app is a :
ASP.NET Core Module stdout log (IIS)To enable and view stdout logs:
Disable stdout logging when troubleshooting is complete:
For more information, see . Warning Failure to disable the stdout log can lead to app or server failure. There's no limit on log file size or the number of log files created. For routine logging in an ASP.NET Core app, use a logging library that limits log file size and rotates logs. For more information, see . 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:
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 . Enable the Developer Exception PageThe
5 to run the app in the Development environment. As long as the environment isn't overridden in app startup by
1 on the host builder, setting the environment variable allows the Developer Exception Page to appear when the app is run.
Setting the environment variable for
5 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 . Obtain data from an appIf 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 . 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 exceptionObtain and analyze a dump from Windows Error Reporting (WER):
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. Warning Crash dumps might take up a large amount of disk space (up to several gigabytes each). App hangs, fails during startup, or runs normallyWhen an app hangs (stops responding but doesn't crash), fails during startup, or runs normally, see to select an appropriate tool to produce the dump. Analyze the dumpA dump can be analyzed using several approaches. For more information, see Analyzing a User-Mode Dump File. Clear package cachesA 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:
Additional resources
Azure documentation
Visual Studio documentation
Visual Studio Code documentation
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: Explains common startup HTTP status code scenarios. Provides troubleshooting advice for apps deployed to Azure App Service. 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. Explains what to do when incoherent packages break an app when performing major upgrades or changing package versions. Lists additional troubleshooting topics. App startup errorsIn Visual Studio, an ASP.NET Core project defaults to IIS Express hosting during debugging. A 502.5 Process Failure that occurs when debugging locally can be diagnosed using the advice in this topic. 403.14 ForbiddenThe app fails to start. The following error is logged:
The error is usually caused by a broken deployment on the hosting system, which includes any of the following scenarios:
Perform the following steps:
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 . 500 Internal Server ErrorThe 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. 502.5 Process FailureThe 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
4. 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')
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:
Confirm that there isn't a conflict between a
8 MSBuild property in the project file and the published bitness of the app. Connection resetIf 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 limitsThe 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 . Troubleshoot on Azure App ServiceApplication Event Log (Azure App Service)To access the Application Event Log, use the Diagnose and solve problems blade in the Azure portal:
An alternative to using the Diagnose and solve problems blade is to examine the Application Event Log file directly using Kudu:
Run the app in the Kudu consoleMany 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:
Test a 32-bit (x86) appCurrent release
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.
The console output from the app, showing any errors, is piped to the Kudu console. Test a 64-bit (x64) appCurrent release
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.
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:
Disable stdout logging when troubleshooting is complete:
For more information, see . Warning Failure to disable the stdout log can lead to app or server failure. There's no limit on log file size or the number of log files created. Only use stdout logging to troubleshoot app startup problems. For general logging in an ASP.NET Core app after startup, use a logging library that limits log file size and rotates logs. For more information, see . Slow or hanging app (Azure App Service)When an app responds slowly or hangs on a request, see the following articles:
Monitoring bladesMonitoring 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:
If stdout logging isn't enabled, follow these steps:
Proceed to activate diagnostic logging:
Be sure to disable stdout logging when troubleshooting is complete. To view the failed request tracing logs (FREB logs):
See and the for more information. For more information, see Enable diagnostics logging for web apps in Azure App Service. Warning Failure to disable the stdout log can lead to app or server failure. There's no limit on log file size or the number of log files created. For routine logging in an ASP.NET Core app, use a logging library that limits log file size and rotates logs. For more information, see . Troubleshoot on IISApplication Event Log (IIS)Access the Application Event Log:
Run the app at a command promptMany 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 deploymentIf the app is a :
Self-contained deploymentIf the app is a :
ASP.NET Core Module stdout log (IIS)To enable and view stdout logs:
Disable stdout logging when troubleshooting is complete:
For more information, see . Warning Failure to disable the stdout log can lead to app or server failure. There's no limit on log file size or the number of log files created. For routine logging in an ASP.NET Core app, use a logging library that limits log file size and rotates logs. For more information, see . Enable the Developer Exception PageThe
5 to run the app in the Development environment. As long as the environment isn't overridden in app startup by
1 on the host builder, setting the environment variable allows the Developer Exception Page to appear when the app is run.
7 Setting the environment variable for
5 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 . Obtain data from an appIf 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 . 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 exceptionObtain and analyze a dump from Windows Error Reporting (WER):
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. Warning Crash dumps might take up a large amount of disk space (up to several gigabytes each). App hangs, fails during startup, or runs normallyWhen an app hangs (stops responding but doesn't crash), fails during startup, or runs normally, see to select an appropriate tool to produce the dump. Analyze the dumpA dump can be analyzed using several approaches. For more information, see Analyzing a User-Mode Dump File. Clear package cachesA 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:
Additional resources
Azure documentation
Visual Studio documentation
Visual Studio Code documentation
Collaborate with us on GitHub The source for this content can be found on GitHub, where you can also create and review issues and pull requests. For more information, see our contributor guide. |