IIS应用程序池崩溃的解决方案

遇到这个问题是我在升级项目版本的时候，升级后的版本网页功能虽然可以正常使用，但每隔几分钟程序池就会忽然崩溃，导致访问503报错，我登陆IIS管理器查看，该应用挂载的应用池状态自动变为了Stopped。

一、确认程序池崩溃原因

a) 满足下面两个特征的IIS程序池崩溃是本文可以解决的，其崩溃原因是应用程序内部反复报错，一般是短时间超过五次，导致IIS自动关闭程序池。
b) 如果不满足这两个条件，那就不是程序报错导致的，后面的内容也就不用看了。

1、应用池崩溃后，网页访问提示503。

2、查看IIS的Events里有无错误。

通常报错为：

A process serving application pool ‘Classic .NET AppPool’ suffered a fatal communication error with the Windows Process Activation Service. The process id was ‘3328’. The data field contains the error number.

我在Server Manager>IIS>Events下查看，这里是有报错的。

二、查找问题来源并修复

1、下载 DebugDiag 插件

这里我们下载一个插件 Debug Diagnostic Tool  (点击此处跳转下载页面)，通过这个插件，我们可以在IIS的错误事件发生时捕获更加详细，应用级别的日志。

点击download下载，选择32还是64位，下载msi镜像，下载成功之后安装。

2、配置 DebugDiag 的断点信息

安装成功之后我们打开安装好的 DebugDiag 2 Analysis 程序，按照下面步骤添加断点。

选择“crash (崩溃)”规则。

选择“A specific IIS web application pool (特定 IIS Web 应用程序池)”

选择崩溃的特定应用程序池。

选择“Breakpoint (断点)”

点击“添加断点”

单击 Breakpoint 下的“Ntdll!ZwTerminateProcess”，将其选为 Breakpoint Expression。将 Action Type 更改为“Full userdump”并将 Action Limit 设置为 10，然后单击 OK。

点击保存并关闭。
点击下一步以激活断点。

点击“Next”，配置日志路径

单击“Finish”以激活规则。

您现在会看到崩溃规则处于活动状态并且“Userdump Count”为0。一旦问题发生，转储计数就会增加，并会生成相应的转储文件。

3、复现崩溃场景，查看问题日志

我们复现了出现问题的场景，IIS应用池再次崩溃，网页503无法访问，DebugDiag Tool的“Userdump Count”变为了10，表示程序池崩溃前程序已经出错了10次。

我们根据刚刚配置的日志路径，找到对应这个问题应用池的日志文件。

打开日志文件，我们看到了应用运行中的种种报错，找到反复高频报错的点，然后修复即可。

我这里有两个异常，一个是Ibatis映射的对象属性没有对上，导致的工厂加载时报错。另一个是空指针异常，因为有个全局变量在全局线程里反复调用，但配置文件里忘记配置了。两个都是因为粗心导致的乌龙问题 = =。