I ve a a customer using IIS and an application, developed by us, in ASP.NET 1.1. Monday, for 4 times in a row the following error has appeared:
一个名为XXXX的应用程序池在与万维网发布服务通信时遇到致命错误。 进程ID为yyyy。 数据字段包含错误编号。
您有没有任何诊断此问题的主意？我所找到的唯一链接讲解了安装低级别调试工具，但在进行这种低级别分析之前，我想知道是否有更好的想法或适当的替代方案。
问题（据我所见）可能是客户环境中的某些问题，因为同一应用程序已经安装在至少20到30个不同服务器的其他客户站点上，但问题并未发生。
在 IIS 7 上出现了相同的问题，有几个报表都可以工作，但有一个非常长的报表在 IIS7 上从未工作（在低配置服务器上很好）。
在IIS7的应用程序池高级设置中，我将"启用32位应用程序"设置为真，并且一切运作得很好。
我收到了相同的错误信息，以下是更多的细节：
running: Windows Server 2003, IIS 6.0 / ASP 3.0, 2.13 GHz, 1 GB ram
我的网站处于测试版阶段，所以我几乎没有任何访问者来到这个网站。
According to the event viewer I m getting this warning 3 times every 3 minutes, then it stops for a few hours.
有时我会遇到错误：
一个为应用程序池 DefaultAppPool 提供服务的进程意外终止。进程 ID 为 3900。进程退出代码为 0x800703e9。
跟随：
由于服务该应用程序池的进程出现一系列故障，应用程序池 DefaultAppPool 正在自动禁用。
这会导致浏览网站时出现“服务不可用”的消息。
阅读了太多关于这个问题的帖子后，我执行了以下步骤：
我读到可能是注册表访问权限问题，所以我安装了一个监视器并追踪了所有的W3SVC访问被拒绝错误并授予权限。
I read that the 0x800703e9 error means stack over flow which causes a w3wp.exe crash and I should install a Debug tool and try to get a memory dump. I did that but I didn t get any dump, so I installed a new debugging tool, but didn t got a crash yet.
我的网站正在进行一些数据挖掘，它使服务器很忙。
结论：
我不知道那里发生了什么……但我知道我的服务器机器资源太慢了，所以我要升级和重新安装它，我相信这会解决问题……
这个问题一直存在，即使我的.NET代码处于空闲状态，因此它是服务器问题，而不是我的代码问题。
I think that the first warnning “A process serving application pool ..." happens every some time, and every now and then it causes the Application Pool to restart, therefore a attaching a debugger doesn t help - the process keeps restarting and the debugger is not effective any longer... I think that the 0x800703e9 error (which causes the Service Unavailable) maybe happens when the app pool restart, I guess that it needs a lot of resource and since my machine is too slow it gets the 0x800703e9 ... as said before this is a stack over flow, but I think that it is caused by low resource and not by an endless recursion.
我认为微软声称的注册表访问权限是个问题是无稽之谈，但因为我没有再遇到“服务不可用”的问题，所以可能有所帮助（尽管我仍会收到警告：“一个为应用程序池服务的进程…”）。
希望这能帮助到某人...
我相信你已经知道了，但App Pool只包含1.1应用程序是吧？我不记得当池试图混合框架而死掉时会得到什么错误（类似于服务器不可用），但这种情况在实践中比我想象的更常见，所以我会再次确认。
虽然可能不是这种情况，但这是一个出发点。
编辑：此 KB文章也包含了与注册表权限相关的错误消息，客户端运行的是哪个版本的IIS？
当网站部署到客户的Web服务器上时，我遇到了同样的问题。这篇Microsoft支持文章说：
如果NT AUTHORITYNETWORK SERVICE帐户没有所需的注册表键的权限，则可能会出现此问题。
并且解决方案是：“将权限设置为所需的注册表键，然后重新启动IIS 6.0。”
这篇文章包含了实现此操作的步骤。
更受欢迎的原因之一（就像我的情况一样）是Windows日志已满。
