【終極解決方案】爲應用程序池「XXX」提供服務的進程在與 Windows Process Activation Service 通訊時出現嚴重錯誤。該進程 ID 爲「XXXX」。數據字段包含錯誤號。

https://www.cnblogs.com/qidian10/p/6028784.html

 

 

症狀

日誌中大量報錯，IIS嚴重錯誤，此類錯誤默認狀況下5分鐘連續出現5次會致使IIS應用程序池直接掛掉，掛掉以後應用基本上是廢掉了，訪問量越高，掛的越快！

臨時補救該錯誤的一個方法爲，調整應用程序池「服務不可用」響應類型爲TcpLevel，這樣好歹應用程序池不會掛了，但問題依舊存在。

 

分析症狀

0、搜一下，基本都是這個解決方案http://www.cnblogs.com/freeton/archive/2012/08/28/2660585.html，屁用不中

一、按照直接思惟，感受應該是服務器配置上哪裏出了問題，應爲本機調試環境下，歷來沒碰到過這個問題，因而乎更換服務器，winserver08=>winserver2012 r2 無奈問題依舊

二、乖乖分析上述日誌錯誤，在系統日誌和w3p日誌中均未見該異常的描述。上述事件異常中提示，異常代碼爲0xc00000fd ,解釋爲棧溢出，基本判定爲是程序某個位置出了問題，極可能是死循環形成的，可是具體在哪一個問題，無從查起

三、瞭解到還能夠經過dmp文件直接跟蹤iis崩潰的緣由

找到dmp文件

dmp文件是啥？本身百度。簡單的說就是黑匣子，記錄程序崩潰前的操做，那麼如何找到這個黑匣子呢？

一、啓動 Windows Error Reporting Service 服務

 

二、執行下面註冊表腳本，設置w3wp.exe 崩潰時自動抓取dmp文件，保存在D:\dumps文件夾裏

 

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\w3wp.exe]
"DumpFolder"=hex(2):64,00,3a,00,5c,00,64,00,75,00,6d,00,70,00,73,00,00,00
"DumpCount"=dword:00000002
"DumpType"=dword:00000002

 備註，若是沒有D盤，能夠保存到C盤，修改一下DumpFolder。"DumpFolder"=hex(2):63,00,3a,00,5c,00,64,00,75,00,6d,00,70,00,73,00,00,00

三、查看dmp文件

IIS崩潰後，在D:\dumps文件夾能看到dmp文件,能夠用於分析dmp文件，找出IIS崩潰的緣由。

調試dmp文件

如何調試dmp文件，這就不得不請出宇宙第一IDE，VS了，我用的vs2013來調試，能夠直接打開dmp文件

一、雙擊DMP文件會直接進入VS，能夠看到Summary信息

二、可選步驟：設置符號路徑

三、設置關聯源代碼路徑（可忽略）

四、一切就緒，點擊「調試託管內存」

五、查看具體異常緣由，定位異常代碼位置

打開局部變量和堆棧調試，異常代碼位置裏面頓現！而後就是找到這個大bug kill它！事件記錄終於清爽了！

感激宇宙第一IDE！

 

 

 

 

 

 

 

 

 

二、找到下面這個項

HKEY_LOCAL_MACHINE\SOFTWARE

\Microsoft\Windows\Windows Error Reporting\LocalDumps

三、在他下面建立一個項，名字爲你要檢測的程序名。

此項中須要4個值配置

值:DumpFolder, 類型：REG_EXPAND_SZ - 顧名思義，就是存儲dump的位置

值:DumpCount, 類型：REG_DWORD - 最大保留的dump個數，默認爲10.

值:DumpType, 類型：REG_DWORD - Dump類型，0：Custom dump， 1： Mini dump, 2： Full dump. 默認值爲1

值:CustomDumpFlags, 類型：REG_DWORD - 沒怎麼用，暫時不解釋。

b)啓動Windows Error Reporting Server服務

服務啓動後若是相應程序出現了崩潰的狀況，WER就會自動將Crash Dump保存到指定的目錄

 

 

https://www.cnblogs.com/50614090/p/5602657.html