排查云服务虚拟机上的应用程序池崩溃问题

  • 项目

本文讨论如何在 Microsoft Azure 云服务 中解决虚拟机 (VM) 上的应用程序池崩溃问题。 如果应用程序池崩溃，应用程序将停止响应。

步骤 1：检查为应用程序池提供服务的进程中的错误

在 事件查看器，如果在控制台树中选择“Windows 日志>系统”，可能会看到以下事件之一：

服务应用程序池“%1”的进程与 Windows 进程激活服务发生严重通信错误。 进程 ID 为“%2”。 数据字段包含错误号。

服务应用程序池“%1”的进程意外终止。 进程 ID 为“%2”。 进程退出代码为“%3”。

这些事件清楚地指示应用程序池崩溃。 由于应用程序中出现了问题，因此必须终止应用程序池。 应用程序池终止后，其相应的 w3wp.exe 进程也会终止。 在 w3wp.exe 进程中保存的任何基于缓存或基于会话的信息都将被删除。

理想情况下，当应用程序池崩溃时，系统会自动生成新的 w3wp.exe 进程，以处理传入的请求。 但是，如果应用程序池在五分钟内崩溃五次以上，则应用程序池将进入停止状态。 必须手动重启应用程序池才能启动并运行应用程序池。 如果发生类似情况，你将在 事件查看器 中的系统日志下观察到以下事件：

应用程序池“%1”由于为该应用程序池提供服务的过程中出现一系列故障， (es) 自动禁用。

可以在该应用程序池的“ 高级设置” 对话框中的“ 快速失败保护 ”部分下配置这些设置。 Enabled 属性的默认值为 True。 如果 Enabled 属性为 True，则在特定时间内达到失败限制后，应用程序池将停止。 失败限制由 “最大失败数” 属性表示。 此属性的默认值为 5。 时间跨度由 故障间隔 (分钟) 属性表示。 此属性也默认为 5。

应用程序池“高级设置”对话框的屏幕截图，Rapid-Fail“保护”部分。

步骤 3：捕获 w3wp.exe 进程转储文件

确定应用程序崩溃后，请确切确定它崩溃的原因。 在进程终止之前，必须捕获 w3wp.exe 进程的转储文件。 有多种方法可以捕获此文件。 可以设置Windows 错误报告 (WER) 、ProcDump 和 DebugDiag 来捕获故障转储文件。 本文仅讨论捕获数据的 DebugDiag 方法。

若要下载并安装 DebugDiag，请执行以下步骤：

  1. 转到 调试诊断工具 v2 站点，然后选择“ 下载”。

  2. 对于 “选择所需的下载”，选择适用于计算机体系结构的 Microsoft Windows Installer (MSI) 文件版本，然后选择“ 下一步”。

  3. 打开下载的文件。 在安装向导中，接受默认选项，然后完成应用安装。

若要设置 DebugDiag 2 集合 应用程序，请执行以下步骤：

  1. 选择 “开始”，输入 “DebugDiag 2 集合”，然后从结果列表中打开新安装的应用。

  2. 在 “选择规则类型 ”对话框中，选择“ 崩溃 ”选项，然后选择“ 下一步”。

  3. 在 “选择目标类型 ”对话框中，选择“ 特定 IIS Web 应用程序池 ”选项，然后选择“ 下一步”。

  4. 在 “选择目标 ”对话框中，选择崩溃的特定应用程序池，然后选择“ 下一步”。 如果打开一个窗口，指出未安装 Internet Information Services (IIS) 管理，并且不会列出应用程序池，请选择“ 确定”，然后手动输入应用程序名称。

  5. 在“ 高级配置 (可选) ”对话框中，选择“ 断点>添加断点”。

  6. 进行以下选择以创建新的断点，然后选择“ 确定”。

    字段 说明 值
    Offset 表达式 要捕获的过程 Ntdll！ZwTerminateProcess
    操作类型 捕获的转储类型 完整用户转储
    操作限制 要捕获的转储数 10

  7. 在 “配置断点 ”对话框中，验证是否显示了新的 断点表达式 项。 选择“ 保存 & 关闭 ”以返回到“ 高级配置 (可选) ”对话框，然后选择“ 下一步 ”以激活断点。

  8. 在 “选择转储位置和规则名称 (可选) ”对话框中，输入 “规则名称”，然后将 “用户转储位置 ”更改为具有足够可用磁盘空间的驱动器和目录（如有必要）。 (每个转储文件的大小将与内存中 w3wp.exe 进程消耗的大小匹配。)

  9. 选择“下一步”。

  10. 若要激活规则，请选择“ 完成”。

现在，崩溃规则处于活动状态， 用户转储计数 为 0。 出现问题时，转储计数会立即增加，并生成相应的转储文件。

注意

应用程序池的正常回收也可以触发转储文件。 这是因为回收时，应用程序池的相应 w3wp.exe 进程 ID (PID) 更改。 这会生成转储文件。 此文件为误报。 因此，它无法帮助你分析应用程序池崩溃。 每当看到用户转储计数增加时，检查事件日志以查看是否发生了预期的崩溃事件。 如果事件与预期一样，则捕获的转储是正确的。

步骤 4：分析 w3wp.exe 进程转储文件

捕获转储文件后，可以打开 “开始>调试”“Diag 2 分析”。 此应用程序允许你分析捕获的故障转储文件。

请确保正确设置了符号路径。 此过程由两部分组成。 在 “调试”“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 反馈社区提交产品反馈。