IIS 应用程序池在 Azure 负载平衡 VM 上崩溃
IIS app pool crashing on Azure load-balanced VMs
我们在一对负载平衡的 Azure 虚拟机上有一个新的 ASP.NET 网站 运行。该网站相当简单，并使用 Kentico CMS。自上线后的 24 小时内，两台 Web 服务器上的应用程序池突然停止（彼此相隔 5-10 分钟）两次，导致 503: Service unavailable 错误。
查看 Windows 系统日志，我看到了导致问题的错误：
Application pool '[[NAME]]' is being automatically disabled due to a
series of failures in the process(es) serving that application pool.
导致此的是一系列警告：
A process serving application pool '[[NAME]]' suffered a fatal
communication error with the Windows Process Activation Service. The
process id was '[[PROCESS ID]]'. The data field contains the error
number.
显然这是 IIS 的快速失败保护启动了。不清楚的是如何找到这个 "fatal communication error" 的原因。
经过一些网络搜索后，我安装了调试诊断工具，它帮助我确定在每种情况下相关进程都是 IIS 工作进程 (w3wp.exe)。这个工具对我来说是新的，不幸的是，自从我安装它以来唯一一次出现问题，没有生成转储。但是，它的日志包含很多这样的消息：
First chance exception - 0xe0434352 caused by thread with System ID:
[[ID]]
令人沮丧的是，我不知道要采取什么步骤来复制错误情况。它从未在非常相似的环境中出现在 UAT 中，即使在负载测试下也是如此。以下是关于我的设置的一些事实：
- ASP.NET版本=4.5.2
- 应用程序池运行身份设置为对网站目录具有修改权限的域帐户
- 最多包含一个工作进程的应用程序集
非常感谢任何建议。
* 更新 1 *
我现在有 "fatal communication error" 警告事件生成的 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
首先，您在IIS 中的应用程序池定期回收时间间隔设置和重叠设置是什么？ - 如果这些事件发生在回收计划和重叠被禁用时，这种行为是可以预料的。即使启用了重叠，我猜它也与应用程序池的自动回收有关，因为这两个实例同时在 cca 中受到影响并且它每天发生两次，它可能导致记录您提到的警告（Here you might find how to disable logging this warning in case it is caused by automatic recycling)
如果没有任何结果，您可以在此处找到有关警告事件的更多详细信息：
IIS Application Pool Availability
关于这里的 Debug Diagnostcs 工具：
How to use the Debug Diagnostics tool to troubleshoot an IIS process that stops unexpectedly
最后我将其追踪到我的代码中的一个错误。在非常极端的情况下，CMS 返回一个空的 Guid 而不是实际的 ID，这导致递归方法中的堆栈溢出。
我在上面发布的 0xC00000FD 异常代码实际上是一个堆栈溢出异常，所以一旦我知道并下载了 Debug Diagnostcs 转储文件，我就能够在本地复制崩溃场景。顺便说一句，该工具非常强大，能够演示崩溃的确切情况。
对于来到这里遇到类似问题的人，我只能说 - 首先，不要假设问题不在您的代码中！其次，使用 Debug Diagnostcs。
我们在一对负载平衡的 Azure 虚拟机上有一个新的 ASP.NET 网站 运行。该网站相当简单，并使用 Kentico CMS。自上线后的 24 小时内，两台 Web 服务器上的应用程序池突然停止（彼此相隔 5-10 分钟）两次，导致 503: Service unavailable 错误。
查看 Windows 系统日志，我看到了导致问题的错误：
Application pool '[[NAME]]' is being automatically disabled due to a series of failures in the process(es) serving that application pool.
导致此的是一系列警告：
A process serving application pool '[[NAME]]' suffered a fatal communication error with the Windows Process Activation Service. The process id was '[[PROCESS ID]]'. The data field contains the error number.
显然这是 IIS 的快速失败保护启动了。不清楚的是如何找到这个 "fatal communication error" 的原因。
经过一些网络搜索后，我安装了调试诊断工具，它帮助我确定在每种情况下相关进程都是 IIS 工作进程 (w3wp.exe)。这个工具对我来说是新的，不幸的是，自从我安装它以来唯一一次出现问题，没有生成转储。但是，它的日志包含很多这样的消息：
First chance exception - 0xe0434352 caused by thread with System ID: [[ID]]
令人沮丧的是，我不知道要采取什么步骤来复制错误情况。它从未在非常相似的环境中出现在 UAT 中，即使在负载测试下也是如此。以下是关于我的设置的一些事实：
- ASP.NET版本=4.5.2
- 应用程序池运行身份设置为对网站目录具有修改权限的域帐户
- 最多包含一个工作进程的应用程序集
非常感谢任何建议。
* 更新 1 *
我现在有 "fatal communication error" 警告事件生成的 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
首先，您在IIS 中的应用程序池定期回收时间间隔设置和重叠设置是什么？ - 如果这些事件发生在回收计划和重叠被禁用时，这种行为是可以预料的。即使启用了重叠，我猜它也与应用程序池的自动回收有关，因为这两个实例同时在 cca 中受到影响并且它每天发生两次，它可能导致记录您提到的警告（Here you might find how to disable logging this warning in case it is caused by automatic recycling)
如果没有任何结果，您可以在此处找到有关警告事件的更多详细信息： IIS Application Pool Availability
关于这里的 Debug Diagnostcs 工具： How to use the Debug Diagnostics tool to troubleshoot an IIS process that stops unexpectedly
最后我将其追踪到我的代码中的一个错误。在非常极端的情况下，CMS 返回一个空的 Guid 而不是实际的 ID，这导致递归方法中的堆栈溢出。
我在上面发布的 0xC00000FD 异常代码实际上是一个堆栈溢出异常，所以一旦我知道并下载了 Debug Diagnostcs 转储文件，我就能够在本地复制崩溃场景。顺便说一句，该工具非常强大，能够演示崩溃的确切情况。
对于来到这里遇到类似问题的人，我只能说 - 首先，不要假设问题不在您的代码中！其次，使用 Debug Diagnostcs。