IIS应用程序池在Azure负载平衡的VM上崩溃

Question

我们在一对负载平衡的Azure VM上运行了一个新的ASP.NET网站。 该网站相当简单，并使用Kentico CMS。 自上线以来的24小时内，两个Web服务器上的应用程序池突然停止（彼此之间间隔5-10分钟），导致503: Service unavailable错误。

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

由于在为该应用程序池提供服务的进程中发生了一系列故障，因此自动禁用了应用程序池“ [[NAME]]”。

导致此的是一系列警告：

为应用程序池“ [[NAME]]”提供服务的进程与Windows Process Activation Service发生致命的通信错误。 进程ID为“ [[PROCESS ID]]”。 数据字段包含错误号。

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

在进行一些网络搜索之后，我安装了调试诊断工具，该工具可以帮助我确定在每种情况下相关的进程都是IIS工作进程（w3wp.exe）。 该工具对我来说是新工具，很遗憾，自我安装该工具以来，只有该问题发生时，才生成转储。 但是，其日志中包含许多类似以下的消息：

第一次机会异常-0xe0434352由系统ID为[[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

Answer 1

最后，我在代码中找到了一个错误。 在极少数情况下，CMS将返回空的Guid而不是实际的ID，这将导致递归方法中的堆栈溢出。

我上面发布的0xC00000FD异常代码实际上是一个堆栈溢出异常，因此，一旦我知道并下载了Debug Diagnostcs转储文件，便能够在本地复制崩溃方案。 顺便说一句，该工具功能强大，能够演示崩溃的确切情况。

我只能对遇到类似问题的人说：-首先，不要以为代码不是问题！ 其次，使用Debug Diagnostcs。

Answer 2

首先，您在IIS中的应用程序池常规回收时间间隔设置和重叠设置是什么？ -如果在计划回收并禁用重叠时发生这些事件，则应预料到此行为。 即使启用了重叠功能，我也猜测它与应用程序池的自动回收有所关联，因为两个实例在同一时间都受到cca的影响，并且每天发生两次，并且可能导致记录您提到的警告（ 在这里您可能查找如何禁用记录此警告（如果它是由自动回收引起的 ））

如果没有结果，则可以在这里找到有关警告事件的更多详细信息： IIS应用程序池可用性

以及有关Debug Diagnostcs工具的信息，在这里： 如何使用Debug Diagnostics工具对意外停止的IIS进程进行故障排除