目录
- 一、确认程序池崩溃原因
- 二、查找问题来源并修复
IIS是微软开发的Web服务器软件，被广泛用于Windows平台上的网站托管。在使用IIS过程中，可能会遇到应用程序池崩溃的问题，原因可能有很多，包括代码错误、资源不足、进程冲突等。本文将为大家介绍IIS应用程序池崩溃的问题分析和解决方案。如果您在IIS的Events日志下观察到以下任一事件，那么本文适合您。
遇到这个问题是我在升级项目版本的时候，升级后的版本网页功能虽然可以正常使用，但每隔几分钟程序池就会忽然崩溃，导致访问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映射的对象属性没有对上，导致的工厂加载时报错。另一个是空指针异常，因为有个全局变量在全局线程里反复调用，但配置文件里忘记配置了。两个都是因为粗心导致的乌龙问题 = =。
到此这篇关于IIS应用程序池崩溃的解决方案的文章就介绍到这了,更多相关IIS应用程序池崩溃内容请搜索悠久资源以前的文章或继续浏览下面的相关文章希望大家以后多多支持悠久资源！
