ASP.NET应用程序转到500.21 ...直到重置IIS +清除Tempoary ASP.NET缓存 [英] ASP.NET Application Goes to 500.21 ... until IIS Reset + Clear Tempoary ASP.NET Cache

问题描述

我们看到在我们的质量保证实验室一个奇怪的图案。我们有两个ASP.NET应用程序，每一个部署在同一个Windows 2008 SP2 +包装盒。我们有我们的应用程序池在域帐户下运行，并设置为永不重新循环。同样1的应用程序池是由两个应用程序使用。

We're seeing an odd pattern in our QA Lab. We have two ASP.NET applications, each deployed on the same Windows 2008 SP2+ box. We have our App Pool running in a Domain Account, and set to never re-cycle. The same 1 App Pool is used by both applications.

几个小时运行良好，新增用户冲浪到在我们的应用程序得到IIS7错误页面一个页面，以500.21的错误后。

After several hours of running fine, new users surfing to a page in our application get the IIS7 Error Page, with a 500.21 error.

如果我们什么都不做，但是：

If we do nothing but:

1）IISRESET
2）更改文件夹C：\\ WINDOWS \\ Microsoft.NET \\ Framework64 \\ V2.0.50727 \\临时ASP.NET文件和RD2应用

1) IISRESET 2) Change folder to c:\Windows\Microsoft.NET\Framework64\v2.0.50727\Temporary ASP.NET Files and "rd" the 2 applications.

和冲浪，然后到我们的Web应用程序，一切都很好。

And then surf to our web applications, all is fine.

然后几个小时后，然而，500.21错误返回。

Then several hours later, however, the 500.21 errors return.

什么令我奇怪的是清除临时ASP.NET文件文件夹，并走开问题之间的关系似乎。我已经安装我们的应用程序（S）的新版本时，清除临时ASP.NET文件文件夹的做法，而不是其他。

What strikes me as odd is the seeming relationship between clearing the "Temporary ASP.NET Files" folders and the problem going away. I've a practice of clearing the "Temporary ASP.NET Files" folders when installing a new version of our application(s), but not otherwise.

这是否关系圈熟悉的人？有没有一些新的杂交IIS7功能在这里工作？

Does this relationship ring familiar to anyone? Is there some new-ish IIS7 feature at work here?

错误的文字：

中的服务器错误应用程序默认Web站点/国家报

Internet信息服务7.0

错误摘要

HTTP错误500.21 - 内部服务器错误

在其模块列表

详细的错误信息
模块IIS Web核心

通知ExecuteRequestHandler

处理器PageHandlerFactory-集成

错误code 0x8007000d

请求的URL 的http：//本地主机：80 / PAIS / Admin.aspx

Server Error in Application "DEFAULT WEB SITE/PAIS"
Internet Information Services 7.0
Error Summary
HTTP Error 500.21 - Internal Server Error
Handler "PageHandlerFactory-Integrated" has a bad module "ManagedPipelineHandler" in its module list
Detailed Error Information
Module IIS Web Core
Notification ExecuteRequestHandler
Handler PageHandlerFactory-Integrated
Error Code 0x8007000d
Requested URL http://localhost:80/PAIS/Admin.aspx

物理路径C：\\ 0_Georgia \\ GA_IS_100142 \\ PortfolioArchiveImageServer \\ Admin.aspx

登录方法匿名

登录用户匿名

最可能的原因：

•ASP.NET未安装或未完全安装。

•一个配置排印出错。

•不利pre-状况的评价存在。

您可以尝试：

•如果ManagedPipelineHandler丢失，确保：

ØManagedEngine在不在。

ØManagedPipelineHandler是，用正确的pre-条件。

•安装ASP.NET。

•确保所有system.webServer/handlers@modules在system.webServer/modules@name。

•审查pre-条件中和节。

链接和更多信息IIS核心无法识别模块。

查看更多信息»

Physical Path C:\0_Georgia\GA_IS_100142\PortfolioArchiveImageServer\Admin.aspx
Logon Method Anonymous
Logon User Anonymous
Most likely causes:
• ASP.NET is not installed or incompletely installed.
• A configuration typographical error occured.
• Unfavourable pre-condition evaluation exists.
Things you can try:
• If ManagedPipelineHandler is missing, ensure that:
o ManagedEngine is in .
o ManagedPipelineHandler is in , with correct pre-conditions.
• Install ASP.NET.
• Ensure all system.webServer/handlers@modules are in system.webServer/modules@name.
• Review pre-conditions in the and sections.
Links and More Information IIS core does not recognize the module.
View more information »

由于提前，

霍华德·霍夫曼

推荐答案

我们发现的实际问题，与MS ASP.NET支持的帮助。这是pretty微妙。我认为MS已经表示，他们将解决这个问题上的应用程序发布面料后续（也就是现在的RTM）。手指交叉。

We found the actual problem, with MS ASP.NET support's help. It's pretty subtle. I think MS has said they will fix the issue in a follow on to the App Fabric release (which is now RTM). Fingers crossed.

问题持续发生在这样的情景：

The problem consistently occurs in this scenario:

1），ASP.NET Web应用程序还没有运行。它包括WCF Net.Pipe和/或绑定的net.tcp。我认为同样会发生的NetMsmq但没有尝试。

1) ASP.NET web application not yet running. It includes WCF Net.Pipe and / or Net.Tcp bindings. I think the same would occur for NetMsmq but did not try it.

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

2) An inbound NetPipe or NetTcp WCF Windows Activation Service request is the initial request that starts the App Domain.

3）申请使用综合IIS应用程序池（IIS7或IIS 7.5）

3) Application uses an 'Integrated' IIS App Pool (IIS7 or IIS 7.5)

4）应用程序，要求一日期间使用HttpServerUtility.Execute。

4) The application uses HttpServerUtility.Execute during that 1st request.

事实证明，我们的申请被烧成非常一号WCF操作过程中ASP.NET运行状况监视事件 - 导致Windows激活服务（WAS）来启动我们的应用程序非常的操作。我们的健康监测配置包括TemplatedMailWebEventProvider上。

It turns out that our application was firing an ASP.NET Health Monitoring event during the very 1st WCF operation -- the very operation that caused Windows Activation Service (WAS) to start our application. Our Health Monitoring configuration includes the TemplatedMailWebEventProvider.

我们的应用程序正在使用的综合IIS应用程序池。

Our application is using an 'Integrated' IIS App Pool.

的 TemplatedMailWebEventProvider上的实施创造一个电子邮件正文为HTML。它使用 System.Web.HttpServerUtility.Execute（字符串的TextWriter，布尔）超载。

The TemplatedMailWebEventProvider is implemented to create an email message body as HTML. It uses the System.Web.HttpServerUtility.Execute(string, TextWriter, Boolean) overload.

对于超载确实错话这种使用情况 - 它初始化了一个经典IIS应用程序池基于HTTP管道。因为这是一个综合IIS应用程序池错误的管道管线被破坏下一个HTTP请求 - 这实际上是第一个入站HTTP请求

For this use case that overload does the wrong thing -- it initializes a 'Classic' IIS App Pool based HTTP pipeline. Because that's the wrong pipeline for an 'Integrated' IIS App Pool the pipeline gets corrupted with the next HTTP request -- which is actually the first inbound HTTP request.

所以，你得到了500.21的错误以后所有的HTTP请求，直到应用程序被重新循环。你并不需要执行IISRESET相对严厉措施，清理临时ASP.NET缓存清理错误 - 只需通过保存web.config中重新启动应用程序，并避免导致错误的特定启动路径

So you get the 500.21 error for all future HTTP requests until the application is re-cycled. You don't need to perform the relatively drastic steps of IISRESET, clearing Temporary ASP.NET cache to clear up the error -- just restart the app via saving web.config and avoid the particular startup path that causes the error.

MS提出了一个解决方法我们 - 使用SimpleMailWebEventProvider代替TemplatedMailWebEventProvider上的。这不工作，因为它需要HttpServerUtility.Execute了第一个请求code路径。

MS suggested a workaround for us -- use the SimpleMailWebEventProvider instead of the TemplatedMailWebEventProvider. That does work, since it takes HttpServerUtility.Execute out of the code path for the first request.

我已经建议MS引入新的web.config ＆LT;＆的System.Web GT; 布尔设置 - UseIntegrated - 它可以让应用程序指定的typeof应用程序池与初始化。显然IIS应用程序池类型不转发到ASP.NET，所以我sugggestion是一个变通来的是的。

I'd suggested that MS introduce a new web.config <system.web> boolean setting -- UseIntegrated -- that let's the application specify the typeof App Pool to initialize with. Evidently IIS does not forward the App Pool type to ASP.NET, so my sugggestion is a work-around to that.

该TemplatedMailWebEvent提供商更方便用户比SimpleMailWebEventProvider友好，我们希望MS解决了上述问题。

The TemplatedMailWebEvent provider is much more user friendly than the SimpleMailWebEventProvider, and we do hope MS addresses the issue.

感谢所有的阅读，

霍华德·霍夫曼

这篇关于ASP.NET应用程序转到500.21 ...直到重置IIS +清除Tempoary ASP.NET缓存的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！