記一次IIS應用程序域崩潰的緣由

在平常工做中，每次新的功能上線前，咱們會搭建一個測試環境提供給客戶測試使用，肯定無誤後纔會更新到正式環境上。這一次也不例外，在約定好時間地點，客戶進行集中化測試的過程當中，反應網站系統打不開，報500錯誤。打開測試服務器後發現應用程序池崩潰自動關閉了。因此習慣性的右鍵-重啓，查日誌。但是好景不長，這邊問題還沒找到，又崩潰了。沒辦法先穩住再說，對應用程序池進行以下設置：

這樣能夠防止應用程序池崩潰的過於頻繁。但是治標不治本，再次崩潰是早晚的問題。

經過服務器的日誌查看器，只能看到下面的信息

雖然不能看到更多信息，可是經過搜索異常代碼: 0xc00000fd基本上能夠判斷是內存泄漏致使的應用程序池崩潰。

爲了進一步瞭解具體狀況，須要分析一下dmp文件。如何生成dmp文件？看下面

開啓 Windows Error Reporting Service 服務

 ，

 （將上面的狀態改爲「已啓動」）

設置w3wp.exe 崩潰時自動抓取dmp文件，保存在D:\dumps文件夾裏

（將以下腳本保存爲reg文件，雙擊執行便可，這塊如有異議能夠自行百度，我也是百度的）

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

IIS崩潰後，會在D:\dumps裏面生成一個dmp文件，以下

其實這個時候再經過事件查看器查看已經能夠看出問題是棧溢出，和發生的對象信息是MPMS.Domain。

 

雖然知道了發生的具體對象，但惋惜的是並無放在心上，而是認爲一個領域對象，用來映射數據庫字段用的怎麼可能會發生內存溢出呢，又沒有死循環的方法在裏面。事實證實我錯了，先不急。看看我是怎麼折騰本身的。

既然dmp都有了，來分析一波吧。

打開Windbg神器，加載dmp文件，直接查看棧信息，執行!dumpstack （windbg的使用，百度）

 

get_AppFundSh() 被大量的執行調用。問題發生在MPMS.Domain.RequestForm.BuyApprovalForm中的AppFundSh這個字段上。

因而我讓同事幫忙看下這個字段什麼狀況。同事給的結論是，有這個字段，可是數據庫沒有添加相應的字段與之匹配，多是Ibatis.net在映射的時候發生問題。

但是根據堆棧反饋的信息來看，若是發生在ORM上，應該會定位到，但是堆棧信息上沒有任何Ibatis的蹤影。因此讓通知本地調試看看什麼狀況，結論是，沒有任何異常狀況發生，表單能夠正常的提交。

這個時候我已經被帶偏了，我應該親自看一下這個代碼，親自調試一下看看的。不斷的敲着windbg的命名，查看各類對象的內存使用狀況，分析一遍又一遍的重複堆棧信息。雖然我不認爲是字段映射匹配的問題，但必定是哪一個地方的邏輯循環調用致使這個問題的發生。

沒有辦法親自調試看看，把斷點加到出問題的方法裏面，折騰後赫然發現，原來一直與我擦肩而過，被忽視的問題出在

 

Get 返回本身，致使死循環。