process serving application pool 'www.mydomain.com' suffered a fatal communication error with the Windows Process Activation Service. The process id was '22852'. The data field contains the error number.
Going through the crash dump I found that the error was a double free error on the heap.
I had to get help form Microsoft support to find out where the error originated, and they found that the code that caused the error was this code in the UmbracoModule.cs file in the Umbraco.web project:
//disable asp.net headers (security)
app.PreSendRequestHeaders += (sender, args) =>
{
var httpContext = ((HttpApplication)sender).Context;
try
{
httpContext.Response.Headers.Remove("Server");
//this doesn't normally work since IIS sets it but we'll keep it here anyways.
httpContext.Response.Headers.Remove("X-Powered-By");
}
catch (PlatformNotSupportedException ex)
{
// can't remove headers this way on IIS6 or cassini.
}
};
As Microsoft support explained "The
Umbraco module is the one removing headers and it does it in
PreSendRequestHeaders event. This event is not a good place to remove the
headers."
I have tried removing this code an buld the umbraco .dll-files again and this removed the heap error. Unfortunatly it seams that this might have spawned a new error that I haven't quite managed to pinpoint yet, but I suspect that I introduces some new error in the dll because they werent buildt correct.
So I'm wondering about two things.
Could someone help me build correct dll-files with the code above which removes the headers?
If this is something that can cause this kind of error, who can look into it and remove them from future Umbraco releases?
I just got another reply form Microsoft support that said that "Instead of PreSentRequestHeaders event, use PostReleaseRequestState event to modify the headers. That should work for you." and I verified with them that they also meant that this was a better place than in the "BeginRequest".
Great, thanks for getting that bit of info. I'll update the source - however it is currently BeginRequest in 7.2.6 but I don't think that will cause issues.
Heap error from header manipulation
Hi
I'm using Umbraco version 7.2.2 assembly: 1.0.5529.18522 on a Windows 2012 server with IIS 8.5.
After we started getting some load on the servers we sterted to see this error in the windows application log:
and this in the windows system log:
Going through the crash dump I found that the error was a double free error on the heap.
I had to get help form Microsoft support to find out where the error originated, and they found that the code that caused the error was this code in the UmbracoModule.cs file in the Umbraco.web project:
As Microsoft support explained "The Umbraco module is the one removing headers and it does it in PreSendRequestHeaders event. This event is not a good place to remove the headers."
I have tried removing this code an buld the umbraco .dll-files again and this removed the heap error. Unfortunatly it seams that this might have spawned a new error that I haven't quite managed to pinpoint yet, but I suspect that I introduces some new error in the dll because they werent buildt correct.
So I'm wondering about two things.
I've fixed this in the core in 7.2.6 now:
https://github.com/umbraco/Umbraco-CMS/commit/744ee39904957e52e1227c83781ad91a7ee84911
This was released after we had implemented our code based on the various articles on the Internet that showed the use of PreSendRequestHeaders.
http://www.asp.net/aspnet/overview/web-development-best-practices/what-not-to-do-in-aspnet,-and-what-to-do-instead#presend
Have moved the code to BeginRequest based on this updated SO article:
http://stackoverflow.com/questions/12803972/removing-hiding-disabling-excessive-http-response-headers-in-azure-iis7-without
I've tested this and it is working.
Hi Shannon
Thanks for the quick reply.
I just got another reply form Microsoft support that said that "Instead of PreSentRequestHeaders event, use PostReleaseRequestState event to modify the headers. That should work for you." and I verified with them that they also meant that this was a better place than in the "BeginRequest".
Great, thanks for getting that bit of info. I'll update the source - however it is currently BeginRequest in 7.2.6 but I don't think that will cause issues.
is working on a reply...