记一次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 返回本身，致使死循环。