針對 Azure App Service 和 IIS 上的 ASP.NET Core 進行疑難排解

作者：Justin Kotalik

本文提供一般應用程式啟動錯誤的相關資訊，以及如何在應用程式部署至 Azure App 服務 或 IIS 時診斷錯誤的指示：

應用程式啟動錯誤
說明常見的啟動 HTTP 狀態碼案例。

針對Azure App 服務進行疑難排解
提供部署至Azure App 服務之應用程式的疑難排解建議。

針對 IIS 進行疑難排解
針對部署到 IIS 或在本機 IIS Express 上執行的應用程式提供疑難排解建議。 本指南同時適用于 Windows Server 和 Windows 桌面部署。

清除套件快取
說明在執行主要升級或變更套件版本時，當不一致套件中斷應用程式時，該怎麼做。

其他資源
列出其他疑難排解主題。

應用程式啟動錯誤

在 Visual Studio 中，ASP.NET Core 專案預設伺服器為 Kestrel 。 Visual Studio 可以設定為使用 IIS Express 。 502.5 - 進程失敗 或 500.30 - 使用 IIS Express 在本機偵錯時發生的啟動失敗 ，可以使用本主題的建議來診斷。

403.14 禁止

應用程式無法啟動。 記錄下列錯誤：

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

錯誤通常是由主控系統上的部署中斷所造成，其中包括下列任何案例：

• 應用程式會部署到主控系統上的錯誤資料夾。
• 部署程式無法將所有應用程式的檔案和資料夾移至主控系統上的部署資料夾。
• 部署中遺漏 web.config 檔案，或 web.config 檔案內容格式不正確。

執行下列步驟：

1. 從主控系統上的部署資料夾刪除所有檔案和資料夾。
2. 使用您一般的部署方法，將應用程式的 publish 資料夾內容重新部署至主控系統，例如 Visual Studio、PowerShell 或手動部署：
   • 確認 部署中有 web.config 檔案，且其內容正確無誤。
   • 在 Azure App 服務 上裝載時，請確認應用程式已部署至 D:\home\site\wwwroot 資料夾。
   • 當應用程式由 IIS 裝載時，請確認應用程式已部署至 IIS 管理員 的基本 設定 中顯示的 IIS 實體路徑 。
3. 藉由比較主控系統上的部署與專案 發佈 資料夾的內容，確認已部署所有應用程式的檔案和資料夾。

如需已發佈 ASP.NET Core 應用程式佈建的詳細資訊，請參閱 ASP.NET Core 目錄結構 。 如需 web.config 檔案的詳細資訊 ，請參閱 適用于 IIS 的 ASP.NET Core Module （ANCM）。

500 內部伺服器錯誤

應用程式啟動，但有錯誤導致伺服器無法完成要求。

此錯誤是在啟動或建立回應時，在應用程式的程式碼內發生。 回應可能未包含任何內容，或是回應可能在瀏覽器中以「500 內部伺服器錯誤」的形式出現。 「應用程式事件記錄檔」通常會指出該應用程式已正常啟動。 從伺服器的觀點來看，這是正確的。 應用程式已啟動，但無法產生有效的回應。 請在伺服器上於命令提示字元中執行應用程式或啟用 ASP.NET Core 模組 stdout 記錄檔，以針對問題進行疑難排解。

安裝 .NET Core 裝載套件組合或損毀時，也可能會發生此錯誤。 安裝或修復 .NET Core 裝載套件組合 （適用于 IIS） 或 Visual Studio （適用于 IIS Express） 的安裝，可能會修正此問題。

500.0 同處理序處理常式載入失敗

背景工作處理序失敗。 應用程式未啟動。

載入 核心模組 元件 ASP.NET 發生未知的錯誤。 請採取下列其中一個動作：

• 連絡 Microsoft 支援服務 (依序選取 [開發人員工具] 和 [ASP.NET Core])。
• 在 Stack Overflow 上詢問問題。
• 在我們的 GitHub 存放庫提出問題。

500.30 同處理序啟動失敗

背景工作處理序失敗。 應用程式未啟動。

ASP.NET Core 模組 會嘗試啟動 .NET Core CLR 進程，但無法啟動。 通常從應用程式事件記錄檔和 ASP.NET Core 模組 stdout 記錄檔中的項目，即可判斷啟動失敗的原因。

常見失敗狀況：

• 應用程式設定錯誤，因為目標為不存在的 ASP.NET Core 共用架構版本。 請檢查安裝在目標機器上的 ASP.NET Core 共用架構版本為何。
• 使用 Azure 金鑰保存庫，缺少金鑰保存庫的許可權。 檢查目標金鑰保存庫中的存取原則，以確保授與正確的許可權。

500.31 ANCM 找不到原生相依性

背景工作處理序失敗。 應用程式未啟動。

ASP.NET Core 模組 會嘗試啟動 .NET Core 執行時間，但無法啟動。 此啟動失敗的最常見原因是當 Microsoft.NETCore.App 或 Microsoft.AspNetCore.App 執行階段未安裝時。 如果應用程式部署至目標 ASP.NET Core 3.0，但電腦上無該版本，就會發生此錯誤。 範例錯誤訊息如下：

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]

錯誤訊息會列出所有已安裝 .NET Core 版本和應用程式所要求的版本。 若要修正此錯誤，請使用以下其中一種方法：

• 在電腦上安裝適當的 .NET Core 版本。
• 將應用程式的目標 .NET Core 版本變更為電腦上版本。
• 將應用程式發佈為自封式部署。

在開發過程中執行時 (ASPNETCORE_ENVIRONMENT 環境變數設定為 Development)，特定的錯誤會寫入至 HTTP 回應。 處理序啟動失敗的原因也會列在應用程式事件記錄檔中。

500.32 ANCM 無法載入 dll

背景工作處理序失敗。 應用程式未啟動。

此錯誤最常見原因是針對不相容的處理器架構發佈應用程式。 如果背景工作處理序執行為 32 位元應用程式，而此應用程式已發佈至目標 64 位元，就會發生此錯誤。

若要修正此錯誤，請使用以下其中一種方法：

• 針對相同的處理器架構，將應用程式重新發佈為背景工作處理序。
• 將應用程式發佈為架構相依部署。

500.33 ANCM 要求處理常式載入失敗

背景工作處理序失敗。 應用程式未啟動。

應用程式未參考 Microsoft.AspNetCore.App 架構。 只有以架構為目標 Microsoft.AspNetCore.App 的應用程式可以由 ASP.NET Core 模組 裝載。

若要修正這個錯誤，請確認應用程式以 Microsoft.AspNetCore.App 架構為目標。 檢查 .runtimeconfig.json 以驗證應用程式是否以該架構為目標。

500.34 ANCM 不支援混合式裝載模型

背景工作處理序無法在相同的程序中執行同處理序應用程式和跨處理序應用程式。

若要修正這個錯誤，請在不同的 IIS 應用程式集區中執行應用程式。

500.35 ANCM 同一程序中有多個同處理序應用程式

背景工作進程無法在同一個進程中執行多個同進程應用程式。

若要修正這個錯誤，請在不同的 IIS 應用程式集區中執行應用程式。

500.36 ANCM 跨處理序處理常式載入失敗

跨處理序要求處理常式 aspnetcorev2_outofprocess.dll 不在 aspnetcorev2.dll 檔案旁邊。 這表示 ASP.NET 核心模組 的損毀安裝 。

若要修正這個錯誤，請修復 .NET Core 裝載套件組合 (適用於 IIS) 或 Visual Studio (適用於 IIS Express) 安裝。

500.37 ANCM 無法在啟動時間限制內啟動

ANCM 無法在提供的啟動時間限制內啟動。 根據預設，逾時值為 120 秒。

在同一部電腦上啟動大量的應用程式時，就會發生此錯誤。 檢查伺服器在啟動期間是否出現 CPU/記憶體的使用量尖峰。 多個應用程式的啟動程序可能需要交錯進行。

500.38 找不到 ANCM 應用程式 DLL

ANCM 找不到應用程式 DLL，該 DLL 應該位於可執行檔旁邊。

使用同進程裝載模型將應用程式封裝為單一 檔案可執行檔 時，就會發生此錯誤。 進程內模型需要 ANCM 將 .NET Core 應用程式載入現有的 IIS 進程。 單一檔案部署模型不支援此案例。 使用 應用程式專案檔中的下列其中一 種方法來修正此錯誤：

1. 將 MSBuild 屬性設定為 false ，以 PublishSingleFile 停用單一檔案發佈。
2. 將 MSBuild 屬性 OutOfProcess 設定 AspNetCoreHostingModel 為 ，以切換至跨進程裝載模型。

502.5 處理序失敗

背景工作處理序失敗。 應用程式未啟動。

ASP.NET Core 模組嘗試啟動背景工作處理序，但無法啟動。 通常從應用程式事件記錄檔和 ASP.NET Core 模組 stdout 記錄檔中的項目，即可判斷啟動失敗的原因。

因為目標 ASP.NET Core 共用架構的版本不存在，導致應用程式設定錯誤是常見的失敗狀況。 請檢查安裝在目標機器上的 ASP.NET Core 共用架構版本為何。 「共用的架構」是一組安裝於電腦上且由 Microsoft.AspNetCore.App 之類的中繼套件所參考的組件 (.dll 檔案)。 中繼套件參考可以指定最低必要版本。 如需詳細資訊，請參閱共用的架構 \(英文\)。

當裝載或應用程式設定錯誤造成背景工作處理序發生失敗時，會傳回 [502.5 處理序失敗] 錯誤頁面：

無法啟動應用程式 (ErrorCode '0x800700c1')

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

應用程式無法啟動，因為無法載入應用程式的組件 (.dll)。

當已發行的應用程式與 w3wp/iisexpress 處理序之間出現位元不符的情況時，就會發生此錯誤。

確認應用程式集區的 32 位元設定正確：

1. 在 IIS 管理員的 [應用程式集區] 中，選取應用程式集區。
2. 在 [動作] 面板中，選取 [編輯應用程式集區] 下的 [進階設定]。
3. 設定 啟用 32 位應用程式 ：
   • 如果部署 32 位元 (x86) 應用程式，請將值設定為 True。
   • 如果部署 64 位元 (x64) 應用程式，請將值設定為 False。

確認專案檔中的 MSBuild 屬性與應用程式的已發佈位之間 <Platform> 沒有衝突。

無法啟動應用程式 （ErrorCode '0x800701b1'）

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

應用程式無法啟動，因為 Windows 服務無法載入。

需要啟用的一個常見服務是「Null」服務。 下列命令會啟用 null Windows 服務：

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](xref:fundamentals/logging/index) can help troubleshoot these types of errors.

### Default startup limits

The [ASP.NET Core Module](xref:host-and-deploy/aspnet-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](xref:host-and-deploy/aspnet-core-module#attributes-of-the-aspnetcore-element).

## Troubleshoot on Azure App Service

[!INCLUDE [Azure App Service Preview Notice](~/includes/azure-apps-preview-notice.md)]

### 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**.
1. In the left pane, navigate to **Monitoring** > **App Service Logs**.
  ![App Service Logs](https://user-images.githubusercontent.com/3605364/183573538-80645002-d1c3-4451-9a2f-91ef4de4e248.png)
1. Select **File System** for **Web Server Logging**. Optionally enable **Application logging**.
  ![enable logging](https://user-images.githubusercontent.com/3605364/183529287-f63d3e1c-ee5b-4ca1-bcb6-a8c29d8b26f5.png)
1. In the left pane, navigate to **Monitoring** > **Log stream**, and then select **Application logs** or **Web Server Logs**.

  ![Monitoring Log stream](https://user-images.githubusercontent.com/3605364/183561255-91f3d5e1-141b-413b-a403-91e74a770545.png)

  The following images shows the application logs output:

  ![app logs](https://user-images.githubusercontent.com/3605364/183528795-532665c0-ce87-4ed3-8e4d-4b374d469c2a.png)

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**.
1. Select **Diagnose and solve problems**.
1. Select the **Diagnostic Tools** heading.
1. Under **Support Tools**, select the **Application Events** button.
1. 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](https://github.com/projectkudu/kudu/wiki):

1. Open **Advanced Tools** in the **Development Tools** area. Select the **Go→** button. The Kudu console opens in a new browser tab or window.
1. Using the navigation bar at the top of the page, open **Debug console** and select **CMD**.
1. Open the **LogFiles** folder.
1. Select the pencil icon next to the `eventlog.xml` file.
1. 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](https://github.com/projectkudu/kudu/wiki) 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.
1. 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`
1. Run the app:
   * If the app is a [framework-dependent deployment](/dotnet/core/deploying/#framework-dependent-deployments-fdd):

     ```dotnetcli
     dotnet .\{ASSEMBLY NAME}.dll
     ```

   * If the app is a [self-contained deployment](/dotnet/core/deploying/#self-contained-deployments-scd):

     ```console
     {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)
1. 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](/dotnet/core/deploying/#framework-dependent-deployments-fdd):
  1. `cd D:\Program Files\dotnet`
  1. Run the app: `dotnet \home\site\wwwroot\{ASSEMBLY NAME}.dll`
* If the app is a [self-contained deployment](/dotnet/core/deploying/#self-contained-deployments-scd):
  1. `cd D:\home\site\wwwroot`
  1. 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)
1. 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)

> [!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 [third-party logging providers](xref:fundamentals/logging/index#third-party-logging-providers).

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.
1. In the **App Service** blade, enter **kudu** in the search box.
1. Select **Advanced Tools** > **Go**.
1. Select  **Debug console > CMD**.
1. Navigate to *site/wwwroot*
1. Select the pencil icon to edit the *web.config* file.
1. 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 <xref:host-and-deploy/aspnet-core-module#log-creation-and-redirection>.

<a name="enhanced-diagnostic-logs"></a>

### 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](xref:host-and-deploy/iis/logging-and-diagnostics#enhanced-diagnostic-logs) to configure the app for an enhanced diagnostic logging. Redeploy the app.
   * Add the `<handlerSettings>` shown in [Enhanced diagnostic logs](xref:host-and-deploy/iis/logging-and-diagnostics#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&rarr;** button. The Kudu console opens in a new browser tab or window.
     1. Using the navigation bar at the top of the page, open **Debug console** and select **CMD**.
     1. 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](xref:host-and-deploy/iis/logging-and-diagnostics#enhanced-diagnostic-logs). Select the **Save** button.
1. Open **Advanced Tools** in the **Development Tools** area. Select the **Go&rarr;** button. The Kudu console opens in a new browser tab or window.
1. Using the navigation bar at the top of the page, open **Debug console** and select **CMD**.
1. 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.
1. 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 <xref:host-and-deploy/iis/logging-and-diagnostics#enhanced-diagnostic-logs>.

> [!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 [third-party logging providers](xref:fundamentals/logging/index#third-party-logging-providers).

### 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](/azure/app-service/app-service-web-troubleshoot-performance-degradation).

### 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.
1. The **ASP.NET Core Extensions** should appear in the list.
1. If the extensions aren't installed, select the **Add** button.
1. Choose the **ASP.NET Core Extensions** from the list.
1. Select **OK** to accept the legal terms.
1. Select **OK** on the **Add extension** blade.
1. 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&rarr;** button. The Kudu console opens in a new browser tab or window.
1. Using the navigation bar at the top of the page, open **Debug console** and select **CMD**.
1. Open the folders to the path **site** > **wwwroot** and scroll down to reveal the *web.config* file at the bottom of the list.
1. Click the pencil icon next to the *web.config* file.
1. Set **stdoutLogEnabled** to `true` and change the **stdoutLogFile** path to: `\\?\%home%\LogFiles\stdout`.
1. Select **Save** to save the updated *web.config* file.

Proceed to activate diagnostic logging:

1. In the Azure portal, select the **Diagnostics logs** blade.
1. Select the **On** switch for **Application Logging (Filesystem)** and **Detailed error messages**. Select the **Save** button at the top of the blade.
1. To include failed request tracing, also known as Failed Request Event Buffering (FREB) logging, select the **On** switch for **Failed request tracing**.
1. Select the **Log stream** blade, which is listed immediately under the **Diagnostics logs** blade in the portal.
1. Make a request to the app.
1. 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.
1. 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](/azure/app-service/web-sites-enable-diagnostic-log#failed-request-traces) and the [Application performance FAQs for Web Apps in Azure: How do I turn on failed request tracing?](/azure/app-service/app-service-web-availability-performance-application-issues-faq#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](/azure/app-service/web-sites-enable-diagnostic-log).

> [!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 [third-party logging providers](xref:fundamentals/logging/index#third-party-logging-providers).

## 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.
1. In **Event Viewer**, open the **Windows Logs** node.
1. Select **Application** to open the Application Event Log.
1. 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](/dotnet/core/deploying/#framework-dependent-deployments-fdd):

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`.
1. The console output from the app, showing any errors, is written to the console window.
1. 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](/dotnet/core/deploying/#self-contained-deployments-scd):

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`.
1. The console output from the app, showing any errors, is written to the console window.
1. 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.
1. 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](xref:host-and-deploy/directory-structure) topic.
1. 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*.
1. Ensure your application pool's identity has write permissions to the *logs* folder.
1. Save the updated *web.config* file.
1. Make a request to the app.
1. Navigate to the *logs* folder. Find and open the most recent stdout log.
1. Study the log for errors.

Disable stdout logging when troubleshooting is complete:

1. Edit the *web.config* file.
1. Set **stdoutLogEnabled** to `false`.
1. Save the file.

For more information, see <xref:host-and-deploy/aspnet-core-module#log-creation-and-redirection>.

> [!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 [third-party logging providers](xref:fundamentals/logging/index#third-party-logging-providers).

### 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:

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

確認為記錄指定的路徑存在，而且應用程式集區的身分識別具有該位置的寫入權限。

如需詳細資訊，請參閱 使用 ASP.NET Core 模組 建立和重新導向記錄。

啟用開發人員例外頁面

在開發環境中，可以將 ASPNETCORE_ENVIRONMENT環境變數新增至 web.config 來執行應用程式。 只要主機產生器上的 UseEnvironment 不會覆寫應用程式啟動內的環境，設定該環境變數便可允許在應用程式執行時顯示開發人員例外狀況頁面。

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

只有在沒有對網際網路公開的暫存和測試伺服器上使用時，才建議為 ASPNETCORE_ENVIRONMENT 設定環境變數。 進行疑難排解之後，請從 web.config 檔案中移除環境變數。 如需有關在 web.config 中設定環境變數的資訊，請參閱 aspNetCore 的 environmentVariables 子元素。

從應用程式取得資料

若應用程式能夠回應要求、請使用終端機內嵌中介軟體從應用程式取得要求、連線與額外資料。 如需詳細資訊和範例程式碼，請參閱 ASP.NET 針對核心專案 進行疑難排解和偵錯。

緩慢或懸掛的應用程式 （IIS）

損 毀傾印 是系統記憶體的快照集，可協助判斷應用程式當機、啟動失敗或緩慢應用程式的原因。

應用程式損毀或發生例外狀況

從 Windows 錯誤報告 (WER) 取得並分析傾印：

1. 在 c:\dumps 中建立資料夾以保存損毀傾印檔案。 應用程式集區必須具備該資料夾的寫入權限。

2. 執行 EnableDumps PowerShell 指令碼：

   • 如果應用程式是使用同處理序主控模型，請執行 w3wp.exe 的指令碼：

     .\EnableDumps w3wp.exe c:\dumps
     

   • 如果應用程式是使用跨處理序主控模型，請執行 dotnet.exe 的指令碼：

     .\EnableDumps dotnet.exe c:\dumps
     

3. 在會導致損毀的情況下，執行應用程式。

4. 發生損毀之後，請執行 DisableDumps PowerShell 指令碼：

   • 如果應用程式是使用同處理序主控模型，請執行 w3wp.exe 的指令碼：

     .\DisableDumps w3wp.exe
     

   • 如果應用程式是使用跨處理序主控模型，請執行 dotnet.exe 的指令碼：

     .\DisableDumps dotnet.exe
     

在應用程式損毀且傾印收集完成之後，即可正常結束應用程式。 PowerShell 指令碼會將 WER 設定為每個應用程式收集最多五個傾印。

警告

損毀傾印可能會佔用大量磁碟空間 (每個高達好幾 GB)。

應用程式停止回應、在啟動期間失敗，或正常執行

當應用程式 停止 回應（停止回應但不會當機）、在啟動期間失敗或正常執行時，請參閱 使用者模式傾印檔案：選擇最佳工具以選取適當的工具 來產生傾印。

分析傾印

您可以使用數種方法來分析傾印。 如需詳細資訊，請參閱分析使用者模式傾印檔案。

清除套件快取

在升級開發電腦上的 .NET Core SDK 或變更應用程式內的套件版本之後，運作中的應用程式可能會立即失敗。 在某些情況下，執行主要升級時，不一致的套件可能會中斷應用程式。 大多數這些問題都可依照下列指示來進行修正：

1. 刪除 [bin] 和 [obj] 資料夾。

2. 藉由執行 dotnet nuget 區域變數來清除套件快取，全都 從命令殼層清除。

   您也可以使用 nuget.exe 工具來完成清除套件快取，並執行 命令 nuget locals all -clear 。 nuget.exe 並未隨附在 Windows 桌面作業系統的安裝中，必須另外從 NuGet 網站取得。

3. 還原並重建專案。

4. 在重新部署應用程式之前，請先刪除伺服器上部署資料夾中的所有檔案。

其他資源

• 使用 Visual Studio 對 .NET 和 ASP.NET Core 原始程式碼進行偵錯
• 針對 ASP.NET Core 專案進行疑難排解和偵錯
• Azure App Service 與 IIS 搭配 ASP.NET Core 時的常見錯誤疑難排解
• 處理 ASP.NET Core 中的錯誤
• 適用於 IIS 的 ASP.NET Core 模組 (ANCM)

Azure 文件

• ASP.NET Core 的 Application Insights \(英文\)
• 使用 Visual Studio 針對 Azure App 服務 中的 Web 應用程式進行疑難排解的遠端偵錯 Web 應用程式一節
• Azure App Service 診斷概觀
• 如何：監視 Azure App Service 中的應用程式
• 使用 Visual Studio 疑難排解 Azure App Service 中的 Web 應用程式
• 對您的 Azure Web 應用程式中「502 不正確的閘道」和「503 服務無法使用」的 HTTP 錯誤進行疑難排解
• 針對 Azure App Service 中 Web 應用程式效能變慢的問題進行疑難排解
• Azure Web 應用程式的應用程式效能常見問題集
• Azure Web 應用程式沙箱 (App Service 執行階段執行限制) \(英文\)

Visual Studio 文件

• Visual Studio 2017 中 Azure 中 IIS 上的遠端偵錯 ASP.NET Core
• Visual Studio 2017 中遠端 IIS 電腦上的遠端偵錯 ASP.NET 核心
• 了解使用 Visual Studio 進行偵錯

Visual Studio Code 文件

• 使用 Visual Studio Code 進行偵錯 \(英文\)