Question

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.

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) Change folder to c:\Windows\Microsoft.NET\Framework64\v2.0.50727\Temporary ASP.NET Files and “rd” the 2 applications.

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

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

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.

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

Text of Error:

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

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 »

Thanks in advance,

Howard Hoffman

Answer 1

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 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) An inbound NetPipe or NetTcp WCF Windows Activation Service request is the initial request that starts the App Domain.

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

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

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.

Our application is using an ‘Integrated’ IIS App Pool.

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

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.

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 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.

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.

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

Thanks all for reading,

Howard Hoffman