IIS是微軟開發(fā)的Web服務器軟件，被廣泛用于Windows平臺上的網站托管。在使用IIS過程中，可能會遇到應用程序池崩潰的問題，原因可能有很多，包括代碼錯誤、資源不足、進程沖突等。本文將為大家介紹IIS應用程序池崩潰的問題分析和解決方案。如果您在IIS的Events日志下觀察到以下任一事件，那么本文適合您。

遇到這個問題是我在升級項目版本的時候，升級后的版本網頁功能雖然可以正常使用，但每隔幾分鐘程序池就會忽然崩潰，導致訪問503報錯，我登陸IIS管理器查看，該應用掛載的應用池狀態(tài)自動變?yōu)榱薙topped。

一、確認程序池崩潰原因

a) 滿足下面兩個特征的IIS程序池崩潰是本文可以解決的，其崩潰原因是應用程序內部反復報錯，一般是短時間超過五次，導致IIS自動關閉程序池。
b) 如果不滿足這兩個條件，那就不是程序報錯導致的，后面的內容也就不用看了。

1、應用池崩潰后，網頁訪問提示503。

2、查看IIS的Events里有無錯誤。

通常報錯為：

A process serving application pool ‘Classic .NET AppPool’ suffered a fatal communication error with the Windows Process Activation Service. The process id was ‘3328’. The data field contains the error number.

我在Server Manager>IIS>Events下查看，這里是有報錯的。

二、查找問題來源并修復

1、下載 DebugDiag 插件

這里我們下載一個插件 Debug Diagnostic Tool (點擊此處跳轉下載頁面)，通過這個插件，我們可以在IIS的錯誤事件發(fā)生時捕獲更加詳細，應用級別的日志。

點擊download下載，選擇32還是64位，下載msi鏡像，下載成功之后安裝。

2、配置 DebugDiag 的斷點信息

安裝成功之后我們打開安裝好的 DebugDiag 2 Analysis 程序，按照下面步驟添加斷點。

選擇“crash (崩潰)”規(guī)則。

選擇“A specific IIS web application pool (特定 IIS Web 應用程序池)”

選擇崩潰的特定應用程序池。

選擇“Breakpoint (斷點)”

點擊“添加斷點”

單擊 Breakpoint 下的“Ntdll!ZwTerminateProcess”，將其選為 Breakpoint Expression。將 Action Type 更改為“Full userdump”并將 Action Limit 設置為 10，然后單擊 OK。

點擊保存并關閉。
點擊下一步以激活斷點。

點擊“Next”，配置日志路徑

單擊“Finish”以激活規(guī)則。

您現(xiàn)在會看到崩潰規(guī)則處于活動狀態(tài)并且“Userdump Count”為0。一旦問題發(fā)生，轉儲計數(shù)就會增加，并會生成相應的轉儲文件。

3、復現(xiàn)崩潰場景，查看問題日志

我們復現(xiàn)了出現(xiàn)問題的場景，IIS應用池再次崩潰，網頁503無法訪問，DebugDiag Tool的“Userdump Count”變?yōu)榱?0，表示程序池崩潰前程序已經出錯了10次。

我們根據剛剛配置的日志路徑，找到對應這個問題應用池的日志文件。

打開日志文件，我們看到了應用運行中的種種報錯，找到反復高頻報錯的點，然后修復即可。

我這里有兩個異常，一個是Ibatis映射的對象屬性沒有對上，導致的工廠加載時報錯。另一個是空指針異常，因為有個全局變量在全局線程里反復調用，但配置文件里忘記配置了。兩個都是因為粗心導致的烏龍問題 = =。

到此這篇關于IIS應用程序池崩潰的解決方案的文章就介紹到這了,更多相關IIS應用程序池崩潰內容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！

最新評論