困擾我大半年的錯誤，今天偶然間被解決了，特此分享給被同樣問題糾結的朋友們！
之前的求助帖，無人應答：
http://www.cnblogs.com/freeton/archive/2012/08/28/2660585.html
http://bbs.csdn.net/topics/391988642
症狀
日志中大量報錯，IIS嚴重錯誤，此類錯誤默認情況下5分鍾連續出現5次會導致IIS應用程序池直接掛掉，掛掉之后應用基本上是廢掉了，訪問量越高，掛的越快！
臨時補救該錯誤的一個方法為，調整應用程序池“服務不可用”響應類型為TcpLevel，這樣好歹應用程序池不會掛了，但問題依舊存在。
分析症狀
0、搜一下，基本都是這個解決方案http://www.cnblogs.com/freeton/archive/2012/08/28/2660585.html，屁用不中
1、按照直接思維，感覺應該是服務器配置上哪里出了問題，應為本機調試環境下，從來沒碰到過這個問題，於是乎更換服務器，winserver08=>winserver2012 r2 無奈問題依舊
2、乖乖分析上述日志錯誤，在系統日志和w3p日志中均未見該異常的描述。上述事件異常中提示，異常代碼為0xc00000fd ,解釋為棧溢出，基本斷定為是程序某個位置出了問題，很可能是死循環造成的，但是具體在哪個問題，無從查起
3、了解到還可以通過dmp文件直接跟蹤iis崩潰的原因
找到dmp文件
dmp文件是啥？自己百度。簡單的說就是黑匣子，記錄程序崩潰前的操作，那么如何找到這個黑匣子呢？
1、啟動 Windows Error Reporting Service 服務
2、執行下面注冊表腳本，設置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
PS：把上面這段代碼保存在記事本中，保存后把后綴名改為“.reg”，雙擊執行即可。
3、查看dmp文件
IIS崩潰后，在D:\dumps文件夾能看到dmp文件,可以用於分析dmp文件，找出IIS崩潰的原因。
調試dmp文件
如何調試dmp文件，這就不得不請出宇宙第一IDE，VS了，我用的vs2013來調試，可以直接打開dmp文件
1、雙擊DMP文件會直接進入VS，可以看到Summary信息
2、可選步驟：設置符號路徑
3、設置關聯源代碼路徑（可忽略）
4、一切就緒，點擊“調試托管內存”
5、查看具體異常原因，定位異常代碼位置
打開局部變量和堆棧調試，異常代碼位置里面頓現！然后就是找到這個大bug kill它！事件記錄終於清爽了！
感激宇宙第一IDE！
本文轉載自：https://www.cnblogs.com/qidian10/p/6028784.html