排查云服务虚拟机上的应用程序池崩溃问题
本文讨论如何在Microsoft Azure 云端服务中解决虚拟机（VM）上的应用程序池崩溃问题。 如果应用程序池崩溃，应用程序将停止响应。
步骤 1：检查为应用程序池提供服务的进程中的错误
在事件查看器中，如果选择控制台树中的 Windows 日志>系统，则可能会看到以下事件之一：
服务应用程序池“%1”的进程与 Windows 进程激活服务发生严重通信错误。 进程 ID 为“%2”。 数据字段包含错误号。
为应用程序池“%1”提供服务的进程意外终止。 进程 ID 为“%2”。 进程退出代码为“%3”。
这些事件清楚地表明应用程序池崩溃。 由于应用程序中出现错误，因此必须终止应用程序池。 应用程序池终止后，其相应的 w3wp.exe 进程也会终止。 将清除在w3wp.exe进程中保存的任何基于缓存或基于会话的信息。
步骤 2：检查应用程序池是否因相关进程失败而自动禁用
理想情况下，当应用程序池崩溃时，会自动生成新的 w3wp.exe 进程以遵守传入的请求。 但是，如果应用程序池在五分钟内崩溃五次以上，则应用程序池进入停止状态。 必须手动重启应用程序池才能启动并运行应用程序池。 如果出现类似情况，你将在事件查看器中的系统日志下观察到以下事件：
由于进程（es）中为该应用程序池提供服务的一系列故障，应用程序池“%1”会自动禁用。
可以在该应用程序池的高级设置对话框中的“快速失败保护”部分下配置这些设置。 Enabled 属性的默认值为 True。 如果 Enabled 属性为 True，则应用程序池将在达到故障限制后在特定时间内停止。 失败限制由 “最大故障数 ”属性表示。 此属性的默认值为 5。 时间跨度由 “失败间隔”（分钟） 属性表示。 此属性也默认为 5。
步骤 3：捕获w3wp.exe进程转储文件
确定应用程序崩溃后，请确切确定它崩溃的原因。 在w3wp.exe进程终止之前，必须捕获w3wp.exe进程的转储文件。 有多种方法可以捕获此文件。 可以设置Windows 错误报告（WER）、ProcDump 和 DebugDiag 来捕获故障转储文件。 本文仅讨论捕获数据的 DebugDiag 方法。
若要下载并安装 DebugDiag，请执行以下步骤：
转到 调试诊断工具 v2 站点，然后选择“ 下载”。
对于 “选择所需的下载”，请选择适用于计算机体系结构的相应Microsoft Windows Installer （MSI） 文件版本，然后选择“ 下一步”。
打开下载的 文件。 在安装向导中，接受默认选项，然后完成应用安装。
若要设置 DebugDiag 2 集合 应用程序，请执行以下步骤：
选择“开始”，输入 DebugDiag 2 集合，然后从结果列表中打开新安装的应用。
在 “选择规则类型 ”对话框中，选择 “崩溃 ”选项，然后选择“ 下一步”。
在 “选择目标类型 ”对话框中，选择 特定的 IIS Web 应用程序池 选项，然后选择“ 下一步”。
在 “选择目标 ”对话框中，选择崩溃的特定应用程序池，然后选择“ 下一步”。 如果打开一个窗口，指出未安装 Internet Information Services （IIS） 管理，并且应用程序池不会列出，请选择“确定”，然后手动输入应用程序名称。
在“高级配置”对话框中，选择“断点添加断点>”。
进行以下选择以创建新的断点，然后选择“ 确定”。
字段 说明 值 偏移表达式 要捕获的过程 Ntdll！ZwTerminateProcess 操作类型 捕获的转储类型 完全用户dump 操作限制 要捕获的转储数 10 在 “配置断点 ”对话框中，验证是否显示新的 断点表达式 项。 选择“保存并关闭”以返回到“高级配置”对话框，然后选择“下一步”以激活断点。
在“选择转储位置和规则名称（可选）”对话框中，输入规则名称，然后将 Userdump 位置更改为具有足够可用磁盘空间的驱动器和目录（如有必要）。 （每个转储文件的大小将与内存中w3wp.exe进程使用的内容匹配。
选择下一步。
若要激活规则，请选择“ 完成”。
现在，崩溃规则处于活动状态， Userdump 计数 为 0。 出现问题时，转储计数将立即增加，并生成相应的转储文件。
注意
应用程序池的正常回收还可以触发转储文件。 发生这种情况的原因是，当应用程序池回收时，应用程序池的相应 w3wp.exe 进程 ID（PID）发生更改。 这会生成转储文件。 此文件为误报。 因此，它不会帮助你分析应用程序池崩溃。 每当看到用户转储计数递增时，请检查事件日志以查看是否发生了预期的崩溃事件。 如果事件按预期方式发生，则捕获的转储是正确的。
步骤 4：分析w3wp.exe进程转储文件
捕获转储文件后，可以打开 Start>DebugDiag 2 Analysis。 此应用程序允许分析捕获的故障转储文件。
请确保正确设置了符号路径。 这是一个由两部分构成的过程。 在 DebugDiag 2 分析中，选择“设置”（齿轮图标）。 在用于分析的符号搜索路径下，验证是否选择了_NT_SYMBOL_PATH和公共符号服务器Microsoft。
重新打开 DebugDiag 2 集合，然后选择“ 工具>选项和设置”。 然后，在 “选项和设置” 对话框中，确保符号 搜索调试路径（即崩溃规则） 框设置为 srv*c：\symcache*https://msdl.microsoft.com/download/symbols。 此路径会导致 DebugDiag 根据需要从Microsoft公共符号服务器下载符号，然后将其存储在 c：\symcache 目录中。
更改或验证符号路径设置后，可以分析捕获的转储文件。 若要启动分析，请返回到 DebugDiag 2 Analysis，然后双击转储文件的名称。 生成报表后，可以在浏览器中打开它，并了解触发断点表达式的线程的调用堆栈。 从下到上读取调用堆栈，然后确定哪个方法或组件触发应用程序池崩溃。 如果找不到精确的异常调用堆栈，请进一步查看同一转储文件分析中的 .NET 调用堆栈。
步骤 5：检查w3wp.exe或WaWorkerHost.exe进程中是否有未经处理的异常
若要检查导致 w3wp.exe 或 WaWorkerHost.exe 进程停止的任何未经处理的异常，请参阅 未经处理的异常导致 ASP。基于 NET 的应用程序在 .NET Framework 中意外退出。
第三方信息免责声明
本文中提到的第三方产品由 Microsoft 以外的其他公司提供。 Microsoft 不对这些产品的性能或可靠性提供任何明示或暗示性担保。
联系我们寻求帮助
如果你有任何疑问或需要帮助，请创建支持请求或联系 Azure 社区支持。 你还可以将产品反馈提交到 Azure 反馈社区。