解決 IIS 應用程式池 DefaultAppPool 進程關閉超時導致假死問題

伺服器頻繁產生「為應用程式池 'DefaultAppPool' 提供服務的進程關閉時間超過了限制。進程 ID '2068'」錯誤，導致 IIS 假死。經排查為 IIS 應用程式池設定問題，提供四種解決方案。

方案一：優化應用程式池設定（推薦首選）

路徑： IIS 管理員 → 應用程式池 → DefaultAppPool → 右鍵「屬性」

「回收」頁籤：

• 回收工作進程（分鐘）：勾選，值 1740（29 小時，避開業務高峰）。
• 回收工作進程（要求數）：不勾選（原設 35000）。
• 在下列時間回收：不填寫。
• 記憶體過高回收：全不勾選。
  理由：避免高流量時強制回收觸發回應問題導致假死。

「效能」頁籤：

• 僅勾選「閒置逾時 20 分鐘」，其餘不勾選。
• Web 園「最大工作進程數」保持 1（預設）。
  ⚠️ 警告：設為 >1 會導致部分網站後台無法開啟或無限重新整理。

原「要求佇列限制」4000 改為無限制。

「健康狀態」頁籤：

• 前兩項啟用（預設值）：啟動時間限制 90 秒，關閉時間限制 180 秒。
• 取消勾選「啟動快速失敗保護」！
  若擔心真錯誤無提示，可不關閉但擴大保護範圍：如失敗 50 次 / 5 分鐘才關閉對應程式。

關鍵點：「關閉時間限制 180 秒」為必須調整項。預設 90 秒，若進程關閉超過 90 秒即判定超時產生日誌錯誤，適當延長可避免此錯誤。

方案二：註冊表調整共用桌面堆疊

原因： 獨立進程桌面堆疊耗盡，IIS 無法建立更多工作空間。

1. HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\W3SVC
2. 在 Parameters 鍵下新建 DWORD：UseSharedWPDesktop = 1
3. 重啟 IIS

方案三：修正資料庫連線字串釋放連線池

現象： 相同程式碼本地正常，伺服器端資料庫連線無法釋放。

解決： 連線字串加入：

Pooling=true; MAX Pool Size=512; Min Pool Size=50; Connection Lifetime=30

方案四：隔離應用程式池

為不同網站建立獨立應用程式池，避免單一池故障波及全站。

排查建議順序

1. 優先方案一（設定優化），風險最低、效果最直接。
2. 若持續發生，檢查應用程式碼連線釋放邏輯，套用方案三。
3. 方案二為系統層面調整，謹慎操作並備份註冊表。
4. 方案四為架構級隔離，適合多站點共存環境。