如何诊断 IIS 致命通信错误问题

Posted 2023-03-10

【中文标题】如何诊断 IIS 致命通信错误问题

【英文标题】：How to diagnose IIS fatal communication error problem

【发布时间】：2010-09-17 11:34:15

【问题描述】：

我有一个客户使用 IIS 和一个由我们开发的 ASP.NET 1.1 应用程序。 周一，连续4次出现以下错误：

为应用程序池“xxxx”提供服务的进程与万维网发布服务发生了致命的通信错误。进程 ID 为“yyyy”。数据字段包含错误号。

您知道如何诊断吗？ only link I've found 谈到了安装低级调试工具，但在继续进行这种低级分析之前，我会知道是否有人有更好的想法或合适的替代方案。

问题（据我所见）是客户环境中的问题，因为它在其他客户站点上安装了至少 20 或 30 台不同服务器上的相同应用程序，并且问题不会发生。

【问题讨论】：

就我而言，问题是我的应用程序代码中存在无限递归循环。

【参考方案1】：

我确定您已经知道这一点，但应用程序池仅包含 1.1 应用程序，对吗？我不记得当池因尝试混合框架而死亡时遇到的错误（例如 Server Unavailable），但它比我想象的更常见，所以我会仔细检查。

虽然不太可能，但它是一个开始的地方。

编辑：This KB 文章也有您描述的与注册表权限相关的错误消息，客户端运行的是什么版本的 IIS？

【参考方案2】：

在将网站部署到客户端的 Web 服务器时，我遇到了同样的问题。 This Microsoft support article 说：

“如果 NT AUTHORITY\NETWORK SERVICE 帐户没有所需注册表项的权限，则可能会出现此问题。”

而解决方法是：“将权限设置为所需的注册表项，然后重启IIS 6.0。”

链接的文章有执行此操作的步骤。

【参考方案3】：

一个更常见的原因（如我的情况） - 一个 Windows 日志已满。

【讨论】：

Alsin，你的答案是 4 年前的，所以这有点牵强。但是您还记得您为什么说“日志已满”是一个流行的原因吗？我没有找到其他关于这个失败原因的参考资料，但考虑到我们的 Windows 事件日志的配置方式，这在我的情况下似乎是合理的。

就我而言，问题是我的应用程序代码中存在无限递归循环。

【参考方案4】：

我遇到了同样的错误，这里有更多详细信息：

正在运行：Windows Server 2003、IIS 6.0 / ASP 3.0、 2.13 GHz，1 GB 内存

我的网站处于测试阶段，所以我几乎没有任何访问者访问该网站。

根据事件查看器，我每 3 分钟收到 3 次此警告， 然后它会停止几个小时。

然后有时我会收到错误：

为应用程序池“DefaultAppPool”提供服务的进程意外终止。进程 ID 为“3900”。进程退出代码为“0x800703e9”。

接下来是：

应用程序池“DefaultAppPool”由于服务于该应用程序池的进程中的一系列故障而被自动禁用。

这会在浏览网站时导致“服务不可用”消息。

在阅读了太多关于这个问题的帖子后，我做了以下步骤：

我读到它可能是注册表访问权限，所以我安装了一个监视器并跟踪所有 W3SVC Access Denied 错误并授予许可

我读到 0x800703e9 错误意味着堆栈溢出导致 w3wp.exe 崩溃，我应该安装调试工具并尝试获取内存转储。 我这样做了，但没有得到任何转储，所以我安装了一个新的调试工具，但还没有崩溃。

我的网站正在进行一些数据挖掘，导致服务器繁忙。

结论：

我不知道那里发生了什么......但我知道我的服务器机器的资源速度很慢，所以我要升级并重新安装它，我确定它会解决问题...

这个问题一直存在，即使我的 .net 代码处于空闲状态，因此这是服务器的问题，而不是我的代码。

我认为第一个警告“服务应用程序池的进程...” 每隔一段时间就会发生一次，并且不时会导致应用程序池重新启动，因此附加调试器无济于事 - 进程不断重新启动，调试器不再有效...... 我认为 0x800703e9 错误（导致服务不可用）可能在应用程序池重新启动时发生，我猜它需要大量资源，并且由于我的机器太慢它得到 0x800703e9 ...如前所述，这是一个堆栈溢出，但我认为这是由于资源不足而不是无限递归造成的。

我认为微软声称是问题的“注册表访问权限”是无稽之谈，但我没有得到“服务不可用”，因为它可能会有所帮助（以为我仍然收到警告“为应用程序池提供服务的进程...”）。

希望这对某人有所帮助...

【参考方案5】：

在 IIS 7 上遇到了同样的问题，除了一份很长且在 IIS7 上从未运行过的报告（在低规格服务器上很好）之外，很少有报告都能正常工作。

在应用程序池的高级设置中的 IIS7 上，我 将“启用 32 位应用程序”设置为 true，一切正常

【讨论】：

您能否解释一下为什么这会解决 OP 的问题？我问是因为我在 ASP.NET 2.0 上遇到了同样的问题，并且想知道这个解决方案是否可以推广到我的情况。谢谢！

我最近在将 ODBC 连接产品移至新服务器时遇到了这个问题。将启用 32 位应用程序翻转为 true 解决了该问题。