在日常工作中，每次新的功能上线前，我们会搭建一个测试环境提供给客户测试使用，确定无误后才会更新到正式环境上。这一次也不例外，在约定好时间地点，客户进行集中化测试的过程中，反应网站系统打不开，报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 返回自己，导致死循环。