C#进阶-IIS应用程序池崩溃的解决方案

IIS是微软开发的Web服务器软件，被广泛用于Windows平台上的网站托管。在使用IIS过程中，可能会遇到应用程序池崩溃的问题，原因可能有很多，包括代码错误、资源不足、进程冲突等。本文将为大家介绍IIS应用程序池崩溃的问题分析和解决方案。如果您在IIS的Events日志下观察到以下任一事件，那么本文适合您。

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

https://www.damon-liu.cn/wp-content/uploads/2023/05/iis_000.png

https://www.damon-liu.cn/wp-content/uploads/2023/05/iis_000.png

一、确认程序池崩溃原因

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下查看，这里是有报错的。

https://www.damon-liu.cn/wp-content/uploads/2023/05/iis_001.png

https://www.damon-liu.cn/wp-content/uploads/2023/05/iis_001.png

二、查找问题来源并修复

1、下载 DebugDiag 插件

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

https://www.damon-liu.cn/wp-content/uploads/2023/05/iis_002.png

https://www.damon-liu.cn/wp-content/uploads/2023/05/iis_002.png

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

https://www.damon-liu.cn/wp-content/uploads/2023/05/iis_003.png

https://www.damon-liu.cn/wp-content/uploads/2023/05/iis_003.png

2、配置 DebugDiag 的断点信息

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

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

https://www.damon-liu.cn/wp-content/uploads/2023/05/iis_004.jpg

https://www.damon-liu.cn/wp-content/uploads/2023/05/iis_004.jpg

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

https://www.damon-liu.cn/wp-content/uploads/2023/05/iis_005.png

https://www.damon-liu.cn/wp-content/uploads/2023/05/iis_005.png

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

https://www.damon-liu.cn/wp-content/uploads/2023/05/iis_006.png

https://www.damon-liu.cn/wp-content/uploads/2023/05/iis_006.png

选择“Breakpoint (断点)”

https://www.damon-liu.cn/wp-content/uploads/2023/05/iis_007.jpg

https://www.damon-liu.cn/wp-content/uploads/2023/05/iis_007.jpg

点击“添加断点”

https://www.damon-liu.cn/wp-content/uploads/2023/05/iis_008.jpg

https://www.damon-liu.cn/wp-content/uploads/2023/05/iis_008.jpg

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

https://www.damon-liu.cn/wp-content/uploads/2023/05/iis_009.png

https://www.damon-liu.cn/wp-content/uploads/2023/05/iis_009.png

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

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

https://www.damon-liu.cn/wp-content/uploads/2023/05/iis_010.jpg

https://www.damon-liu.cn/wp-content/uploads/2023/05/iis_010.jpg

单击“Finish”以激活规则。

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

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

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

https://www.damon-liu.cn/wp-content/uploads/2023/05/iis_012.png

https://www.damon-liu.cn/wp-content/uploads/2023/05/iis_012.png

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

https://www.damon-liu.cn/wp-content/uploads/2023/05/iis_013.png

https://www.damon-liu.cn/wp-content/uploads/2023/05/iis_013.png

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

https://www.damon-liu.cn/wp-content/uploads/2023/05/iis_014.png

https://www.damon-liu.cn/wp-content/uploads/2023/05/iis_014.png

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

文章来源： https://damon.blog.csdn.net/article/details/135219983
版权声明： 本文为博主原创文章，遵循CC 4.0 BY-SA 知识共享协议，转载请附上原文出处链接和本声明。