為應(yīng)用程序池“XXX”提供服務(wù)的進(jìn)程在與 Windows Process Activation Service 通信時(shí)出現(xiàn)嚴(yán)重錯(cuò)誤。該進(jìn)程 ID 為“XXXX”。數(shù)據(jù)字段包含錯(cuò)誤號(hào)。

癥狀

日志中大量報(bào)錯(cuò)，IIS嚴(yán)重錯(cuò)誤，此類(lèi)錯(cuò)誤默認(rèn)情況下5分鐘連續(xù)出現(xiàn)5次會(huì)導(dǎo)致IIS應(yīng)用程序池直接掛掉，掛掉之后應(yīng)用基本上是廢掉了，訪問(wèn)量越高，掛的越快！

臨時(shí)補(bǔ)救該錯(cuò)誤的一個(gè)方法為，調(diào)整應(yīng)用程序池“服務(wù)不可用”響應(yīng)類(lèi)型為T(mén)cpLevel，這樣好歹應(yīng)用程序池不會(huì)掛了，但問(wèn)題依舊存在。

分析癥狀

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

1、按照直接思維，感覺(jué)應(yīng)該是服務(wù)器配置上哪里出了問(wèn)題，應(yīng)為本機(jī)調(diào)試環(huán)境下，從來(lái)沒(méi)碰到過(guò)這個(gè)問(wèn)題，于是乎更換服務(wù)器，winserver08=>winserver2012 r2 無(wú)奈問(wèn)題依舊

2、乖乖分析上述日志錯(cuò)誤，在系統(tǒng)日志和w3p日志中均未見(jiàn)該異常的描述。上述事件異常中提示，異常代碼為0xc00000fd ,解釋為棧溢出，基本斷定為是程序某個(gè)位置出了問(wèn)題，很可能是死循環(huán)造成的，但是具體在哪個(gè)問(wèn)題，無(wú)從查起

3、了解到還可以通過(guò)dmp文件直接跟蹤iis崩潰的原因

找到dmp文件

dmp文件是啥？自己百度。簡(jiǎn)單的說(shuō)就是黑匣子，記錄程序崩潰前的操作，那么如何找到這個(gè)黑匣子呢？

1、啟動(dòng) Windows Error Reporting Service 服務(wù)

2、執(zhí)行下面注冊(cè)表腳本，設(shè)置w3wp.exe 崩潰時(shí)自動(dòng)抓取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

3、查看dmp文件

IIS崩潰后，在D:\dumps文件夾能看到dmp文件,可以用于分析dmp文件，找出IIS崩潰的原因。

調(diào)試dmp文件

如何調(diào)試dmp文件，這就不得不請(qǐng)出宇宙第一IDE，VS了，我用的vs2013來(lái)調(diào)試，可以直接打開(kāi)dmp文件

1、雙擊DMP文件會(huì)直接進(jìn)入VS，可以看到Summary信息

2、可選步驟：設(shè)置符號(hào)路徑

3、設(shè)置關(guān)聯(lián)源代碼路徑（可忽略）

4、一切就緒，點(diǎn)擊“調(diào)試托管內(nèi)存”

5、查看具體異常原因，定位異常代碼位置

打開(kāi)局部變量和堆棧調(diào)試，異常代碼位置里面頓現(xiàn)！然后就是找到這個(gè)大bug kill它！事件記錄終于清爽了！