排查云服务虚拟机上的应用程序池崩溃问题
本文讨论如何在 Microsoft Azure 云服务 中解决虚拟机 (VM) 上的应用程序池崩溃问题。 如果应用程序池崩溃,应用程序将停止响应。
步骤 1:检查为应用程序池提供服务的进程中的错误
在 事件查看器,如果在控制台树中选择“Windows 日志>系统”,可能会看到以下事件之一:
服务应用程序池“%1”的进程与 Windows 进程激活服务发生严重通信错误。 进程 ID 为“%2”。 数据字段包含错误号。
服务应用程序池“%1”的进程意外终止。 进程 ID 为“%2”。 进程退出代码为“%3”。
这些事件清楚地指示应用程序池崩溃。 由于应用程序中出现了问题,因此必须终止应用程序池。 应用程序池终止后,其相应的 w3wp.exe 进程也会终止。 在 w3wp.exe 进程中保存的任何基于缓存或基于会话的信息都将被删除。
步骤 2:检查应用程序池是否因相关进程失败而自动禁用
理想情况下,当应用程序池崩溃时,系统会自动生成新的 w3wp.exe 进程,以处理传入的请求。 但是,如果应用程序池在五分钟内崩溃五次以上,则应用程序池将进入停止状态。 必须手动重启应用程序池才能启动并运行应用程序池。 如果发生类似情况,你将在 事件查看器 中的系统日志下观察到以下事件:
应用程序池“%1”由于为该应用程序池提供服务的过程中出现一系列故障, (es) 自动禁用。
可以在该应用程序池的“ 高级设置” 对话框中的“ 快速失败保护 ”部分下配置这些设置。 Enabled 属性的默认值为 True。 如果 Enabled 属性为 True,则在特定时间内达到失败限制后,应用程序池将停止。 失败限制由 “最大失败数” 属性表示。 此属性的默认值为 5。 时间跨度由 故障间隔 (分钟) 属性表示。 此属性也默认为 5。
步骤 3:捕获 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) 管理,并且不会列出应用程序池,请选择“ 确定”,然后手动输入应用程序名称。
在“ 高级配置 (可选) ”对话框中,选择“ 断点>添加断点”。
进行以下选择以创建新的断点,然后选择“ 确定”。
字段 说明 值 Offset 表达式 要捕获的过程 Ntdll!ZwTerminateProcess 操作类型 捕获的转储类型 完整用户转储 操作限制 要捕获的转储数 10 在 “配置断点 ”对话框中,验证是否显示了新的 断点表达式 项。 选择“ 保存 & 关闭 ”以返回到“ 高级配置 (可选) ”对话框,然后选择“ 下一步 ”以激活断点。
在 “选择转储位置和规则名称 (可选) ”对话框中,输入 “规则名称”,然后将 “用户转储位置 ”更改为具有足够可用磁盘空间的驱动器和目录(如有必要)。 (每个转储文件的大小将与内存中 w3wp.exe 进程消耗的大小匹配。)
选择“下一步”。
若要激活规则,请选择“ 完成”。
现在,崩溃规则处于活动状态, 用户转储计数 为 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 反馈社区提交产品反馈。