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

作者：Justin Kotalik

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

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

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

針對 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. 使用您一般的部署方法 (例如 Visual Studio、PowerShell 或手動部署)，將應用程式的 publish 資料夾內容重新部署至主控系統：
   • 確認部署中有 web.config 檔案，且其內容正確無誤。
   • 在 Azure App Service 上主控時，請確認應用程式已部署至 D:\home\site\wwwroot 資料夾。
   • 當應用程式由 IIS 主控時，請確認應用程式已部署至 [IIS 管理員] 的 [基本設定] 中顯示的 IIS [實體路徑]。
3. 比較主控系統上的部署與專案 publish 資料夾的內容，以確認所有應用程式的檔案和資料夾皆已部署。

如需已發佈 ASP.NET Core 應用程式配置的詳細資訊，請參閱 ASP.NET Core 目錄結構。 如需關於 web.config 檔案詳細資訊，請參閱適用於 IIS 的 ASP.NET Core 模組 (ANCM)。

500 內部伺服器錯誤

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

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

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

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

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

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

• 連絡 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 Key Vault 時，缺少 Key Vault 的權限。 檢查目標 Key Vault 中的存取原則，以確保授與正確的權限。

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 架構。 ASP.NET Core 模組只裝載以 Microsoft.AspNetCore.App 架構為目標的應用程式。

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

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

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

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

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

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

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

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

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

若要修正這個錯誤，請修復 .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. 將 PublishSingleFile MSBuild 屬性設定為 false，以停用單一檔案發佈。
2. 將 AspNetCoreHostingModel MSBuild 屬性設定為 OutOfProcess，以切換至跨處理序主控模型。

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。

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

無法啟動應用程式 (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

連線重設

如果是在傳送標頭之後才發生錯誤，則當發生錯誤時，伺服器已來不及傳送「500 內部伺服器錯誤」。 通常是在將回應的複雜物件序列化的期間發生錯誤時，會發生此錯誤。 這類錯誤會在用戶端上顯示為「連線重設」錯誤。 應用程式記錄可協助針對這些類型的錯誤進行疑難排解。

預設啟動限制

ASP.NET Core 模組上已設定預設的 startupTimeLimit 120 秒。 保留預設值時，在模組記錄處理序失敗之前，應用程式最多可花費兩分鐘來進行啟動。 如需有關設定模組的資訊，請參閱 aspNetCore 元素的屬性。

針對 Azure App Service 進行疑難排解

重要

ASP.NET Core 預覽版本與 Azure App Service

根據預設，ASP.NET Core 預覽版本不會部署至 Azure App Service。 若要裝載使用 ASP.NET Core 預覽版本的應用程式，請參閱將 ASP.NET Core 預覽版本部署至 Azure App Service。

Azure App Services 記錄串流

Azure App Services 記錄串流會在發生時記錄資訊。 若要檢視串流記錄：

1. 在 Azure 入口網站的 [應用程式服務] 中，開啟應用程式。
2. 在左窗格中，瀏覽至 [監視]> [App Service 記錄]。
3. 針對 [Web 伺服器記錄] 選取 [檔案系統]。 選擇性地啟用 [應用程式記錄]。
4. 在左窗格中，瀏覽至 [監視]> [記錄串流]，然後選取 [應用程式記錄] 或 [Web 伺服器記錄]。

下列影像顯示應用程式記錄輸出：

串流記錄有一些延遲，而且可能不會立即顯示。

應用程式事件記錄檔 (Azure App Service)

若要存取「應用程式事件記錄檔」，請使用 Azure 入口網站中的 [診斷並解決問題] 刀鋒視窗：

1. 在 Azure 入口網站的 [應用程式服務] 中，開啟應用程式。
2. 選取 [診斷並解決問題]。
3. 選取 [診斷工具] 標題。
4. 在 [支援工具] 下，選取 [應用程式事件] 按鈕。
5. 檢查 [來源] 資料行中 IIS AspNetCoreModule 或 IIS AspNetCoreModule V2 項目所提供的最新錯誤。

除了使用 [診斷並解決問題] 刀鋒視窗之外，也可以使用 Kudu 來直接檢查「應用程式事件記錄檔」：

1. 在 [開發工具] 區域中，開啟 [進階工具]。 選取 [Go→] 按鈕。 Kudu 主控台會在新的瀏覽器索引標籤或視窗中開啟。
2. 使用頁面頂端的導覽列，開啟 [偵錯主控台]，然後選取 [CMD]。
3. 開啟 [LogFiles] 資料夾。
4. 選取 eventlog.xml 檔案旁的鉛筆圖示。
5. 檢查記錄檔。 捲動至記錄檔的底部以查看最新事件。

在 Kudu 主控台中執行應用程式

許多啟動錯誤不會在「應用程式事件記錄檔」中產生實用的資訊。 您可以在 Kudu「遠端執行主控台」中執行應用程式來探索錯誤：

1. 在 [開發工具] 區域中，開啟 [進階工具]。 選取 [Go→] 按鈕。 Kudu 主控台會在新的瀏覽器索引標籤或視窗中開啟。
2. 使用頁面頂端的導覽列，開啟 [偵錯主控台]，然後選取 [CMD]。

測試 32 位元 (x86) 應用程式

目前的版本

1. cd d:\home\site\wwwroot
2. 執行應用程式：

   • 如果應用程式是架構相依部署：

     dotnet .\{ASSEMBLY NAME}.dll
     

   • 如果應用程式是自封式部署：

     {ASSEMBLY NAME}.exe
     

應用程式的主控台輸出 (顯示任何錯誤) 會以管道傳送至 Kudu 主控台。

在預覽版上執行的架構相依部署

要求安裝 ASP.NET Core {VERSION} (x86) 執行階段網站延伸模組。

1. cd D:\home\SiteExtensions\AspNetCoreRuntime.{X.Y}.x32 ({X.Y} 是執行階段版本)
2. 執行應用程式：dotnet \home\site\wwwroot\{ASSEMBLY NAME}.dll

應用程式的主控台輸出 (顯示任何錯誤) 會以管道傳送至 Kudu 主控台。

測試 64 位元 (x64) 應用程式

目前的版本

• 如果應用程式是 64 位元 (x64) 架構相依部署：
  1. cd D:\Program Files\dotnet
  2. 執行應用程式：dotnet \home\site\wwwroot\{ASSEMBLY NAME}.dll
• 如果應用程式是自封式部署：
  1. cd D:\home\site\wwwroot
  2. 執行應用程式：{ASSEMBLY NAME}.exe

應用程式的主控台輸出 (顯示任何錯誤) 會以管道傳送至 Kudu 主控台。

在預覽版上執行的架構相依部署

要求安裝 ASP.NET Core {VERSION} (x64) 執行階段網站延伸模組。

1. cd D:\home\SiteExtensions\AspNetCoreRuntime.{X.Y}.x64 ({X.Y} 是執行階段版本)
2. 執行應用程式：dotnet \home\site\wwwroot\{ASSEMBLY NAME}.dll

應用程式的主控台輸出 (顯示任何錯誤) 會以管道傳送至 Kudu 主控台。

ASP.NET Core 模組 stdout 記錄 (Azure App Service)

警告

如果無法停用 stdout 記錄檔，可能會造成應用程式或伺服器發生失敗。 因為它並沒有記錄檔大小或數量上的限制。 請只在針對應用程式啟動問題進行疑難排解時，才使用 stdout 記錄。

針對 ASP.NET Core 應用程式啟動後的一般記錄，請使用會限制記錄檔大小並輪替記錄檔的記錄程式庫。 如需詳細資訊，請參閱協力廠商記錄提供者。

ASP.NET Core 模組 stdout 記錄檔通常會記錄「應用程式事件記錄檔」中所沒有的實用訊息。 啟用及檢視 stdout 記錄檔：

1. 在 Azure 入口網站中，瀏覽至 Web 應用程式。
2. 在 [App Service] 刀鋒視窗中，於搜尋方塊中輸入 kudu。
3. 選取 [進階工具]> [前往]。
4. 選取 [偵錯主控台] > [CMD]。
5. 瀏覽至 site/wwwroot
6. 選取鉛筆圖示以編輯 web.config 檔案。
7. 在 <aspNetCore /> 元素中，設定 stdoutLogEnabled="true" 並選取 [儲存]。

透過設定 stdoutLogEnabled="false" 完成疑難排解時，請停用 stdout 記錄。

如需詳細資訊，請參閱適用於 IIS 的 ASP.NET Core 模組 (ANCM)。

ASP.NET Core 模組偵錯記錄 (Azure App Service)

ASP.NET Core 模組偵錯記錄提供 ASP.NET Core 模組中其他且更深入的記錄。 啟用及檢視 stdout 記錄檔：

1. 若要啟用增強型診斷記錄，請執行下列任一動作：
   • 遵循增強型診斷記錄中的指示，來設定應用程式進行增強型診斷記錄。 重新部署應用程式。
   • 使用 Kudu 主控台，將增強型診斷記錄中所顯示的 <handlerSettings> 新增至即時應用程式的 web.config 檔案：
     1. 在 [開發工具] 區域中，開啟 [進階工具]。 選取 [Go→] 按鈕。 Kudu 主控台會在新的瀏覽器索引標籤或視窗中開啟。
     2. 使用頁面頂端的導覽列，開啟 [偵錯主控台]，然後選取 [CMD]。
     3. 將資料夾開啟至路徑 [site]>[wwwroot]。 選取鉛筆圖示來編輯 web.config 檔案。 新增 <handlerSettings> 區段，如增強型診斷記錄中所示。 選取儲存按鈕。
2. 在 [開發工具] 區域中，開啟 [進階工具]。 選取 [Go→] 按鈕。 Kudu 主控台會在新的瀏覽器索引標籤或視窗中開啟。
3. 使用頁面頂端的導覽列，開啟 [偵錯主控台]，然後選取 [CMD]。
4. 將資料夾開啟至路徑 [site]>[wwwroot]。 如果未提供 aspnetcore-debug.log 檔案的路徑，該檔案會顯示在清單中。 如果已提供路徑，請巡覽至記錄檔的位置。
5. 使用檔案名稱旁的鉛筆圖示來開啟記錄檔。

完成疑難排解時，請停用偵錯記錄：

若要停用增強型偵錯記錄，請執行下列任一動作：

• 從 web.config 檔案本機移除 <handlerSettings> 並重新部署應用程式。
• 使用 Kudu 主控台來編輯 web.config 檔案並移除 <handlerSettings> 區段。 儲存檔案。

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

警告

無法停用偵錯記錄，可能會造成應用程式或伺服器發生失敗。 記錄檔大小沒有任何限制。 請只在針對應用程式啟動問題進行疑難排解時，才使用偵錯記錄。

針對 ASP.NET Core 應用程式啟動後的一般記錄，請使用會限制記錄檔大小並輪替記錄檔的記錄程式庫。 如需詳細資訊，請參閱協力廠商記錄提供者。

應用程式緩慢或停止回應 (Azure App Service)

當應用程式針對要求回應緩慢或無回應時，請參閱針對 Azure App Service 中 Web 應用程式效能變慢的問題進行疑難排解。

監視刀鋒視窗

監視刀鋒視窗為本主題稍早所述的方法提供替代的疑難排解體驗。 這些刀鋒視窗可用來診斷 500 系列的錯誤。

請確認已安裝 ASP.NET Core 延伸模組。 如果未安裝這些延伸模組，請手動安裝：

1. 在 [開發工具] 刀鋒視窗區段中，選取 [延伸模組] 刀鋒視窗。
2. [ASP.NET Core 延伸模組] 應該會出現在清單中。
3. 如果未安裝這些延伸模組，請選取 [新增] 按鈕。
4. 從清單中選擇 [ASP.NET Core 延伸模組]。
5. 選取 [確定] 以接受法律條款。
6. 在 [新增延伸模組] 刀鋒視窗上，選取 [確定]。
7. 成功安裝延伸模組時，會有資訊快顯訊息提供指示。

如果未啟用 stdout 記錄，請依照下列步驟進行操作：

1. 在 Azure 入口網站中，選取 [開發工具] 區域中的 [進階工具] 刀鋒視窗。 選取 [Go→] 按鈕。 Kudu 主控台會在新的瀏覽器索引標籤或視窗中開啟。
2. 使用頁面頂端的導覽列，開啟 [偵錯主控台]，然後選取 [CMD]。
3. 將資料夾開啟至路徑 [site]>[wwwroot]，然後向下捲動以顯露位於清單底部的 web.config 檔案。
4. 按一下 web.config 檔案旁邊的鉛筆圖示。
5. 將 stdoutLogEnabled 設定為 true，並將 stdoutLogFile 路徑變更為：\\?\%home%\LogFiles\stdout。
6. 選取 [儲存] 以儲存已更新的 web.config 檔案。

繼續接著啟用診斷記錄：

1. 在 Azure 入口網站中，選取 [診斷記錄檔] 刀鋒視窗。
2. 選取 [應用程式記錄 (檔案系統)] 和 [詳細錯誤訊息].的 [開啟] 開關。 選取刀鋒視窗頂端的 [儲存] 按鈕。
3. 若要包含失敗要求追蹤 (也稱為「失敗要求事件緩衝處理」(FREB) 記錄)，請選取 [失敗要求的追蹤] 的 [開啟] 開關。
4. 選取 [記錄資料流] 刀鋒視窗 (列在入口網站中緊接在 [診斷記錄檔] 刀鋒視窗之下)。
5. 對應用程式發出要求。
6. 在記錄資料流資料內，會指出錯誤的原因。

完成疑難排解時，請務必停用 stdout 記錄。

檢視失敗要求追蹤記錄檔 (FREB 記錄檔)：

1. 在 Azure 入口網站中，瀏覽至 [診斷並解決問題] 刀鋒視窗。
2. 從資訊看板的 [支援工具] 區域中，選取 [失敗要求追蹤記錄檔]。

如需詳細資訊，請參閱＜在 Azure App Service 中針對 Web 應用程式啟用診斷記錄功能＞主題的＜失敗要求追蹤＞一節和Azure Web 應用程式的應用程式效能常見問題集：如何開啟失敗要求追蹤？。

如需詳細資訊，請參閱在 Azure App Service 中針對 Web 應用程式啟用診斷記錄功能。

警告

如果無法停用 stdout 記錄檔，可能會造成應用程式或伺服器發生失敗。 因為它並沒有記錄檔大小或數量上的限制。

針對 ASP.NET Core 應用程式中的例行性記錄，請使用會限制記錄檔大小並輪替記錄檔的記錄程式庫。 如需詳細資訊，請參閱協力廠商記錄提供者。

針對 IIS 進行疑難排解

應用程式事件記錄檔 (IIS)

存取「應用程式事件記錄檔」：

1. 開啟 [開始] 功能表，搜尋事件檢視器，然後選取 [事件檢視器] 應用程式。
2. 在 [事件檢視器] 中，開啟 [Windows 記錄] 節點。
3. 選取 [應用程式] 以開啟「應用程式事件記錄檔」。
4. 搜尋與失敗應用程式相關的錯誤。 錯誤在 [來源] 資料行中的值會是 IIS AspNetCore Module 或 IIS Express AspNetCore Module。

在命令提示字元中執行應用程式

許多啟動錯誤不會在「應用程式事件記錄檔」中產生實用的資訊。 您可以藉由在主控系統上的命令提示字元中執行應用程式，來找出一些錯誤的原因。

架構相依部署

如果應用程式是架構相依部署：

1. 在命令提示字元中，瀏覽至部署資料夾，然後使用 dotnet.exe 來執行應用程式組件以執行應用程式。 在下列命令中，請以應用程式組件的名稱取代 <assembly_name>：dotnet .\<assembly_name>.dll。
2. 來自應用程式的主控台輸出若有顯示任何錯誤，就會寫入至主控台視窗。
3. 如果是在對應用程式發出要求時發生錯誤，請對 Kestrel 進行接聽的主機和連接埠發出要求。 如果使用預設主機和連接埠，請對 http://localhost:5000/ 發出要求。 如果應用程式在 Kestrel 端點位址正常回應，則問題與主機組態有關的機率較大，而與應用程式本身有關的機率較小。

自封式部署

如果應用程式是自封式部署：

1. 在命令提示字元中，瀏覽至部署資料夾，然後執行應用程式的可執行檔。 在下列命令中，請以應用程式組件的名稱取代 <assembly_name>：<assembly_name>.exe。
2. 來自應用程式的主控台輸出若有顯示任何錯誤，就會寫入至主控台視窗。
3. 如果是在對應用程式發出要求時發生錯誤，請對 Kestrel 進行接聽的主機和連接埠發出要求。 如果使用預設主機和連接埠，請對 http://localhost:5000/ 發出要求。 如果應用程式在 Kestrel 端點位址正常回應，則問題與主機組態有關的機率較大，而與應用程式本身有關的機率較小。

ASP.NET Core 模組 stdout 記錄檔 (IIS)

啟用及檢視 stdout 記錄檔：

1. 瀏覽至主控系統上網站的部署資料夾。
2. 如果 [logs] 資料夾不存在，請建立該資料夾。 如需有關如何讓 MSBuild 在部署中自動建立 [logs] 資料夾的指示，請參閱目錄結構主題。
3. 編輯 web.config 檔案。 將 stdoutLogEnabled 設定為 true，並將 stdoutLogFile 路徑變更為指向 [logs] 資料夾 (例如 .\logs\stdout)。 路徑中的 stdout 是記錄檔名稱前置詞。 建立記錄檔時，系統會自動新增時間戳記、處理序識別碼及副檔名。 使用 stdout 作為檔案名稱前置詞時，一般記錄檔會命名為 stdout_20180205184032_5412.log。
4. 請確定您的應用程式集區身分識別具有 logs 資料夾的寫入權限。
5. 儲存已更新的 web.config 檔案。
6. 對應用程式發出要求。
7. 瀏覽至 [logs] 資料夾。 尋找並開啟最新的 stdout 記錄檔。
8. 研究記錄檔以了解錯誤。

完成疑難排解時，請停用 stdout 記錄：

1. 編輯 web.config 檔案。
2. 將 stdoutLogEnabled 設定為 false。
3. 儲存檔案。

如需詳細資訊，請參閱適用於 IIS 的 ASP.NET Core 模組 (ANCM)。

警告

如果無法停用 stdout 記錄檔，可能會造成應用程式或伺服器發生失敗。 因為它並沒有記錄檔大小或數量上的限制。

針對 ASP.NET Core 應用程式中的例行性記錄，請使用會限制記錄檔大小並輪替記錄檔的記錄程式庫。 如需詳細資訊，請參閱協力廠商記錄提供者。

ASP.NET Core 模組偵錯記錄 (IIS)

將下列處理常式設定新增至應用程式的 web.config 檔案，以啟用 ASP.NET Core 模組偵錯記錄：

<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 Core 專案進行疑難排解和偵錯。

回應緩慢或無回應的應用程式 (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 locals all --clear 來清除套件快取。

   您也可以使用 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 Service 中的 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 Core 進行遠端偵錯
• 了解使用 Visual Studio 進行偵錯

Visual Studio Code 文件

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