Azure负载平衡虚拟机上的IIS应用程序池崩溃

本文关键字：应用 应用程序 程序池 崩溃 IIS 负载 平衡 虚拟机 Azure | 更新日期: 2023-09-27 18:20:18

我们有一个新的ASP.NET网站在一对负载平衡的Azure虚拟机上运行。该网站相当简单，使用Kentico CMS。在启用后的24小时内，两台web服务器上的应用程序池两次突然停止（在5-10分钟内），导致503: Service unavailable错误。

查看Windows系统日志，我看到了导致问题的错误：

由于为该应用程序池提供服务的进程中的一系列故障。

导致这种情况的是一系列警告：

为应用程序池"[[NAME]]"提供服务的进程发生致命错误与Windows Process Activation Service的通信错误。这个进程id为"[[process id]]"。数据字段包含错误数字

显然，这是IIS的快速故障保护。目前尚不清楚的是如何找到这个"致命通信错误"的原因。

经过一些网络搜索，我安装了调试诊断工具，它帮助我确定在任何情况下相关的进程都是IIS工作进程（w3wp.exe）。这个工具对我来说是新的，不幸的是，这是我安装它以来唯一一次出现问题，没有生成转储。然而，它的日志包含很多这样的消息：

第一次机会异常-0xe043352，由系统ID为的线程引起：

令人沮丧的是，我不知道该采取什么步骤来复制错误条件。在UAT中，即使在负载测试下，也从未在非常相似的环境中发生过这种情况。以下是关于我的设置的一些事实：

  • ASP.NET版本=4.5.2
  • 应用程序池在标识设置为对网站目录具有修改权限的域帐户的情况下运行
  • 最多有一个工作进程的应用程序集

非常感谢任何建议。

*更新1*

我现在有由"致命通信错误"警告事件生成的DebugDiag转储。转储摘要读取：

Dump Summary
------------
Process Name:   w3wp.exe : C:'Windows'SysWOW64'inetsrv'w3wp.exe
Process Architecture:   x86
Exception Code: 0xC00000FD
Exception Information:  The thread used up its stack.
Heap Information:   Present

Azure负载平衡虚拟机上的IIS应用程序池崩溃

最后，我在代码中发现了一个错误。在非常边缘的情况下，CMS返回的是空的Guid，而不是实际的ID，这导致了递归方法中的堆栈溢出。

我上面发布的0xC00000FD异常代码实际上是一个堆栈溢出异常，所以一旦我知道了这一点并下载了调试诊断转储文件，我就可以在本地复制崩溃场景。顺便说一句，这个工具非常强大，能够证明坠机的确切情况。

我能对那些带着类似问题来到这里的人说的就是——首先，不要认为问题不在你的代码上！其次，使用调试诊断。

首先，你的应用程序池定期回收时间间隔设置是什么；IIS中的重叠设置？-如果在计划回收并禁用重叠时发生这些事件，则这种行为是意料之中的。即使启用了重叠，我猜这在一定程度上与应用程序池的自动回收有关，因为两个实例在cca中同时受到影响&它每天发生两次，可能会导致记录您提到的警告（在这里，您可以找到如何禁用记录此警告，以防它是由自动回收引起的）

如果这毫无结果，您可以在此处找到有关警告事件的更多详细信息：IIS应用程序池可用性

关于此处的调试诊断工具：如何使用调试诊断工具对意外停止的IIS进程进行故障排除

相关文章：