症状

 日志中大量报错，IIS严重错误，此类错误默认情况下5分钟连续出现5次会导致IIS应用程序池直接挂掉，挂掉之后应用基本上是废掉了，访问量越高，挂的越快！

临时补救该错误的一个方法为，调整应用程序池“服务不可用”响应类型为TcpLevel，这样好歹应用程序池不会挂了，但问题依旧存在。

分析症状

0、搜一下，基本都是这个解决方案http://www.landui.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

3、查看dmp文件

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

调试dmp文件

如何调试dmp文件，这就不得不请出宇宙第一IDE，VS了，我用的vs2013来调试，可以直接打开dmp文件

1、双击DMP文件会直接进入VS，可以看到Summary信息

2、可选步骤：设置符号路径

3、设置关联源代码路径（可忽略）

4、一切就绪，点击“调试托管内存”

5、查看具体异常原因，定位异常代码位置

打开局部变量和堆栈调试，异常代码位置里面顿现！然后就是找到这个大bug kill它！事件记录终于清爽了！

二、问题描述，系统报错几次后，系统直接表现程序报错无法使用，重启应用程序就好了。 自己解决思路

1.查看系统日志，system、对应application 如下：

可能的原因：程序存在BUG 

本次根据application中报出的具体问题，忘截图了基本可以判断出问题。再根据报问题的时间，大概推断出可能使用了哪个功能。最后发现是因为用了企业内部邮箱账号，只能向内部邮箱发信息，向外部邮箱发邮件就会卡死。