ASP.NET 应用程序转到 500.21 ...直到 IIS 重置 + 清除临时 ASP.NET 缓存

Posted 2023-02-26

【中文标题】ASP.NET 应用程序转到 500.21 ...直到 IIS 重置 + 清除临时 ASP.NET 缓存

【英文标题】：ASP.NET Application Goes to 500.21 ... until IIS Reset + Clear Tempoary ASP.NET Cache

【发布时间】：2010-12-02 11:39:49

【问题描述】：

我们在 QA 实验室中发现了一种奇怪的模式。我们有两个 ASP.NET 应用程序，每个应用程序都部署在同一个 Windows 2008 SP2+ 机器上。我们的应用程序池在域帐户中运行，并设置为永不循环。两个应用程序使用相同的 1 App Pool。

在正常运行几个小时后，新用户浏览我们应用程序中的某个页面时会收到 IIS7 错误页面，并显示 500.21 错误。

如果我们什么都不做：

1) IISRESET 2) 将文件夹更改为 c:\Windows\Microsoft.NET\Framework64\v2.0.50727\Temporary ASP.NET Files 并“rd”这两个应用程序。

然后浏览我们的网络应用程序，一切都很好。

然而，几个小时后，500.21 错误又回来了。

让我感到奇怪的是清除“临时 ASP.NET 文件”文件夹与问题消失之间的关系。在安装我们的应用程序的新版本时，我会清除“临时 ASP.NET 文件”文件夹，否则不会。

这种关系对任何人来说都很熟悉吗？这里有一些新的 IIS7 功能吗？

错误文本：

应用程序“DEFAULT WEB SITE/PAIS”中的服务器错误 互联网信息服务 7.0 错误摘要 HTTP 错误 500.21 - 内部服务器错误 处理程序“PageHandlerFactory-Integrated”的模块列表中有一个错误模块“ManagedPipelineHandler” 详细的错误信息 模块 IIS Web 核心 通知 ExecuteRequestHandler 处理程序 PageHandlerFactory-Integrated 错误代码 0x8007000d 请求的网址http://localhost:80/PAIS/Admin.aspx

物理路径 C:\0_Georgia\GA_IS_100142\PortfolioArchiveImageServer\Admin.aspx 登录方式匿名 登录用户匿名 最可能的原因： • ASP.NET 未安装或安装不完整。 • 出现配置印刷错误。 • 存在不利的前置条件评估。 您可以尝试的事情： • 如果缺少 ManagedPipelineHandler，请确保： o ManagedEngine 位于 . o ManagedPipelineHandler 在 中，前提条件正确。 • 安装 ASP.NET。 • 确保所有 system.webServer/handlers@modules 都在 system.webServer/modules@name 中。 • 查看和部分中的先决条件。 链接和更多信息 IIS 核心无法识别该模块。 查看更多信息 »

提前致谢，

霍华德霍夫曼

【问题讨论】：

可以贴出错误页面的全文吗？

另外，我会将每个应用程序拆分到自己的 AppPool 中，看看您是否可以缩小问题范围。

请注意，我们采纳了 David 的建议并分成 2 个池。我还可以添加重新循环应用程序池，而不是运行 IISReset + 删除 Temporary ASP.NET Files GAGI 文件夹，似乎也可以解决问题。问题仍然是......为什么？

【参考方案1】：

问题更可能出在应用程序代码中。 Temporary ASP.NET Files 文件夹包含应用程序的预编译副本，每次访问应用程序文件时都会刷新。您可以使用 \Windows\Microsoft.NET\Framework\v2.0.50727\ 文件夹中的 aspnet_compiler.exe 预编译这些文件。使用 -errorstack 选项可以生成有关您遇到的错误的更多信息。长时间运行的不回收的应用程序如果使用大量内存或在 inproc 会话状态中保留大量数据，则会遇到问题。如果您的会话包含大量信息，请考虑使用基于 sqlserver 的会话管理器。

【讨论】：

我们确实确定问题出在System.Web.HttpServerUtility.Execute(string, TextWriter, Boolean) 过载 - 真的。由于在调用重载时没有 HTTP 管道，它确实会破坏运行时。这是微软的问题。他们证实了这一点。我真希望他们也能修复它……但SimpleMailWebEventProvider 是一种解决方法。

【参考方案2】：

在 MS ASP.NET 支持的帮助下，我们找到了实际问题。这很微妙。我认为 MS 已经表示他们将在 App Fabric 版本（现在是 RTM）的后续版本中解决这个问题。手指交叉。

在这种情况下始终会出现问题：

1) ASP.NET Web 应用程序尚未运行。它包括 WCF Net.Pipe 和/或 Net.Tcp 绑定。我认为 NetMsmq 也会发生同样的情况，但没有尝试过。

2) 入站 NetPipe 或 NetTcp WCF Windows 激活服务请求是启动应用程序域的初始请求。

3) 应用程序使用“集成”IIS 应用程序池（IIS7 或 IIS 7.5）

4) 应用程序在第一个请求期间使用 HttpServerUtility.Execute。

事实证明，我们的应用程序在第一次 WCF 操作期间触发了 ASP.NET Health Monitoring 事件——正是该操作导致 Windows 激活服务 (WAS) 启动我们的应用程序。我们的健康监控配置包括 TemplatedMailWebEventProvider。

我们的应用程序正在使用“集成”IIS 应用程序池。

TemplatedMailWebEventProvider 用于将电子邮件正文创建为 html。它使用System.Web.HttpServerUtility.Execute(string, TextWriter, Boolean) 重载。

对于这个用例，重载会做错事——它会初始化一个基于“经典”IIS 应用程序池的 HTTP 管道。因为对于“集成”IIS 应用程序池来说，这是错误的管道，所以管道会因下一个 HTTP 请求而损坏——这实际上是第一个入站 HTTP 请求。

因此，在重新循环应用程序之前，您会收到所有未来 HTTP 请求的 500.21 错误。您无需执行 IISRESET 等相对激烈的步骤，清除 Temporary ASP.NET 缓存以清除错误——只需通过保存 web.config 重新启动应用程序，并避免导致错误的特定启动路径。

MS 为我们建议了一个解决方法——使用 SimpleMailWebEventProvider 而不是 TemplatedMailWebEventProvider。这确实有效，因为它将 HttpServerUtility.Execute 从第一个请求的代码路径中取出。

我建议 MS 引入一个新的 web.config <system.web> 布尔设置 -- UseIntegrated -- 让应用程序指定要初始化的应用程序池的类型。显然 IIS 不会将 App Pool 类型转发到 ASP.NET，所以我的建议是解决那个。

TemplatedMailWebEvent 提供程序比 SimpleMailWebEventProvider 更加用户友好，我们确实希望 MS 解决这个问题。

感谢大家的阅读，

霍华德霍夫曼

【讨论】：

我注意到 AFAIK Microsoft 从未解决根本原因。他们已经从 ASP.NET 健康监控转向支持对 System Center 和相关技术的投资。 Windows Server 2012 中的问题仍然存在 - 尚未检查 Windows Server 2016 - 解决方法仍然有效。

【参考方案3】：

遇到了同样的问题，解决起来很简单。

1) 打开 Visual Studio 2010 命令提示符。

2) 运行命令aspnet_regiis.exe -i

【讨论】：

你能补充一下“aspnet_regiis.exe -i”的作用吗？

它在 IIS 上安装 ASP.NET。我遇到了这个问题，因为 .Net 4 在 IIS 之前安装在我的机器上。我必须运行这个命令才能让 ASP.NET 在我的机器上运行。

【参考方案4】：

1. IIS 7 抛出异常如下所示 2. 以管理员模式打开visual studio 2010命令提示符，执行aspnet_regiis.exe -i

3. 问题已修复，如下图 ASP.Net Application 和 ASP.Net MCV Application 运行流畅。

【讨论】：

做得很好，清楚地记录了您的解决方案。确实有很多方法可以解决500.19 错误。您的解决方案不能解决我们的特定问题。只有按照接受的答案的步骤解决了我们的特定问题。