IIS7:服务应用程序池的进程“YYYYY”与 Windows 进程激活服务发生致命通信错误

发布于 2024-12-01 14:00:18 字数 406 浏览 12 评论 0原文

我们正在运行 32 位 Windows Server 2008,IIS 版本为 7。
我们正在尝试发布一个 asp.net 4.0 Web 应用程序,到目前为止,我们的尝试仅在服务器日志中产生了一些警告,甚至没有停止4.0应用程序池

为应用程序池“ASP.NET v4.0”提供服务的进程与 Windows 进程激活服务发生致命通信错误。进程 ID 为“1904”。数据字段包含错误号。

应用程序在 4.0 应用程序池和默认网站下运行。
我们还有一些旧的 .asp 可以完美运行。
即使在尝试发布一个贫瘠的(只读。只有 1 行文本).aspx 文件时,它也惨遭失败......我们长期以来一直不知道该怎么做,因此任何形式的输入都将受到赞赏......

We're running a 32-bit Windows server 2008 with an IIS version of 7.
We're attempting to publish an asp.net 4.0 webapp and so far our attempts have only yielded a few warnings in the serverlog without even stopping the 4.0 application pool

A process serving application pool 'ASP.NET v4.0' suffered a fatal communication error with the Windows Process Activation Service. The process id was '1904'. The data field contains the error number.

The application is running under a 4.0 app-pool and under the default website.
We've also got some older .asp's running flawlessly.
Even when attempting to publish a barren (read. only 1 line of text) .aspx-file it failed miserably... We've since long run out of ideas on what to do so any form of input would be appreciated...

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(7

你对谁都笑 2024-12-08 14:00:18

调试诊断工具 (DebugDiag) 可以成为救星。它创建并分析 IIS 故障转储。当我看到调用堆栈后,我在几分钟内就发现了崩溃的原因。

IIS 应用程序池崩溃和调试诊断

Debug Diagnostics Tool (DebugDiag) can be a lifesaver. It creates and analyze IIS crash dumps. I figured out my crash in minutes once I saw the call stack.

IIS Application Pool Crash and Debug Diag

鸠书 2024-12-08 14:00:18

我在一天的大部分时间里都在调试这个问题,当我快要烧毁建筑物时,我发现了 Sysinternals 的进程监控工具

将其设置为监视 w3wp.exe 并在浏览器中触发请求后退出之前检查最后的事件。希望对更多的读者有所帮助。

I was debugging the problem for the better part of the day and when I was close to burning the building I discovered the Process Monitor tool from Sysinternals.

Set it to monitor w3wp.exe and check last events before it exits after you fire a request in the browser. Hope that helps further readers.

眼泪都笑了 2024-12-08 14:00:18

确保 IIS 中的每个应用程序池的高级设置 下的启用 32 位应用程序 设置为 True

IIS 截图

Make sure that each Application Pool in IIS, under Advanced Settings has Enable 32 bit Applications set to True

IIS screenshot

淡写薰衣草的香 2024-12-08 14:00:18

当我遇到此问题时,我安装了“Visual Studio 2015 远程工具' 来自 MSDN。我将本地VS附加到服务器上进行调试。

我知道有些人可能无法在其他服务器上安装或访问其他服务器,但我想我应该把它作为一种选择。

When I had this problem, I installed 'Remote Tools for Visual Studio 2015' from MSDN. I attached my local VS to the server to debug.

I appreciate that some folks may not have the ability to either install on or access other servers, but I thought I'd throw it out there as an option.

云之铃。 2024-12-08 14:00:18

我最近遇到了这个。我们的组织将运行应用程序池的帐户限制为 Active Directory 中选定的服务器列表。我发现我没有将托管应用程序的计算机之一添加到 AD 中帐户的“登录到”列表中。

I ran into this recently. Our organization restricts the accounts that run application pools to a select list of servers in Active Directory. I found that I had not added one of the machines hosting the application to the "Log On To" list for the account in AD.

姜生凉生 2024-12-08 14:00:18

对我来说,问题是配置文件缺少元素。

For me the problem was a configuration file that was missing an Element.

浮生未歇 2024-12-08 14:00:18

在我们的例子中,问题与在 Configuration(IAppBuilder app) 方法中使用 app.UseCors(corsOptions) 相关。
该问题还伴随着 IIS 响应时间的增加和 502 错误的激增。但我们不知道它到底是如何引起这个问题的。

In our case, the issue was related to using of app.UseCors(corsOptions) in Configuration(IAppBuilder app) method.
The issue also was accompanied by increase in IIS response times and spike of 502 errors. We don't know how exactly it caused the issue though.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文