IIS應用程序池在Azure負載平衡的VM上崩潰

Question

我們在一對負載平衡的Azure VM上運行了一個新的ASP.NET網站。 該網站相當簡單，並使用Kentico CMS。 自上線以來的24小時內，兩個Web服務器上的應用程序池突然停止（彼此之間間隔5-10分鍾），導致503: Service unavailable錯誤。

查看Windows系統日志，我看到導致問題的錯誤：

由於在為該應用程序池提供服務的進程中發生了一系列故障，因此自動禁用了應用程序池“ [[NAME]]”。

導致此的是一系列警告：

為應用程序池“ [[NAME]]”提供服務的進程與Windows Process Activation Service發生致命的通信錯誤。 進程ID為“ [[PROCESS ID]]”。 數據字段包含錯誤號。

顯然，這是IIS的快速故障保護的開始。目前尚不清楚如何找到此“致命通信錯誤”的原因。

在進行一些網絡搜索之后，我安裝了調試診斷工具，該工具可以幫助我確定在每種情況下相關的進程都是IIS工作進程（w3wp.exe）。 該工具對我來說是新工具，很遺憾，自我安裝該工具以來，只有該問題發生時，才生成轉儲。 但是，其日志中包含許多類似以下的消息：

第一次機會異常-0xe0434352由系統ID為[[ID]]的線程引起

令人沮喪的是，我不知道要采取什么步驟來復制錯誤條件。 即使在負載測試下，它也不會在非常相似的環境中的UAT中發生。 以下是有關我的設置的一些事實：

• ASP.NET版本= 4.5.2
• 以身份設置為具有網站目錄修改權限的域帳戶運行的應用程序池
• 具有最多一個工作進程的應用程序集

任何建議，不勝感激。

*更新1 *

我現在有“致命通信錯誤”警告事件生成的DebugDiag轉儲。 轉儲摘要顯示：

Dump Summary
------------
Process Name:   w3wp.exe : C:\Windows\SysWOW64\inetsrv\w3wp.exe
Process Architecture:   x86
Exception Code: 0xC00000FD
Exception Information:  The thread used up its stack.
Heap Information:   Present

Answer 1

最后，我在代碼中找到了一個錯誤。 在極少數情況下，CMS將返回空的Guid而不是實際的ID，這將導致遞歸方法中的堆棧溢出。

我上面發布的0xC00000FD異常代碼實際上是一個堆棧溢出異常，因此，一旦我知道並下載了Debug Diagnostcs轉儲文件，便能夠在本地復制崩潰方案。 順便說一句，該工具功能強大，能夠演示崩潰的確切情況。

我只能對遇到類似問題的人說：-首先，不要以為代碼不是問題！ 其次，使用Debug Diagnostcs。

Answer 2

首先，您在IIS中的應用程序池常規回收時間間隔設置和重疊設置是什么？ -如果在計划回收並禁用重疊時發生這些事件，則應預料到此行為。 即使啟用了重疊功能，我也猜測它與應用程序池的自動回收有所關聯，因為兩個實例在同一時間都受到cca的影響，並且每天發生兩次，並且可能導致記錄您提到的警告（ 在這里您可能查找如何禁用記錄此警告（如果它是由自動回收引起的 ））

如果沒有結果，則可以在這里找到有關警告事件的更多詳細信息： IIS應用程序池可用性

以及有關Debug Diagnostcs工具的信息，在這里： 如何使用Debug Diagnostics工具對意外停止的IIS進程進行故障排除