Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>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.</p> <p>The problem consistently occurs in this scenario:</p> <p>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.</p> <p>2) An inbound NetPipe or NetTcp WCF Windows Activation Service request is the initial request that starts the App Domain.</p> <p>3) Application uses an 'Integrated' IIS App Pool (IIS7 or IIS 7.5)</p> <p>4) The application uses HttpServerUtility.Execute during that 1st request.</p> <p>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.</p> <p>Our application is using an 'Integrated' IIS App Pool. </p> <p>The <code>TemplatedMailWebEventProvider</code> is implemented to create an email message body as HTML. It uses the <code>System.Web.HttpServerUtility.Execute(string, TextWriter, Boolean)</code> overload.</p> <p>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.</p> <p>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.</p> <p>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.</p> <p>I'd suggested that MS introduce a new web.config <code>&lt;system.web&gt;</code> boolean setting -- <code>UseIntegrated</code> -- 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 <em>that</em>. </p> <p>The TemplatedMailWebEvent provider is much more user friendly than the SimpleMailWebEventProvider, and we do hope MS addresses the issue.</p> <p>Thanks all for reading,</p> <p>Howard Hoffman</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload