Copied to clipboard

Flag this post as spam?

This post will be reported to the moderators as potential spam to be looked at


  • Petter Christie 5 posts 26 karma points
    Jun 02, 2015 @ 11:28
    Petter Christie
    1

    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:

    Faulting application name: w3wp.exe, version: 8.5.9600.16384, time stamp: 0x5215df96
    Faulting module name: ntdll.dll, version: 6.3.9600.17736, time stamp: 0x550f4336
    Exception code: 0xc0000374
    Fault offset: 0x00000000000f0f20
    Faulting process id: 0x5944
    Faulting application start time: 0x01d09cad7e0cc476
    Faulting application path: c:\windows\system32\inetsrv\w3wp.exe
    Faulting module path: C:\Windows\SYSTEM32\ntdll.dll
    Report Id: 99f0ac38-08a5-11e5-80c4-00155d0ea910
    Faulting package full name: 
    Faulting package-relative application ID: 

    and this in the windows system log:

     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.

    1. Could someone help me build correct dll-files with the code above which removes the headers?
    2. If this is something that can cause this kind of error, who can look into it and remove them from future Umbraco releases?

     

     

     

     

  • Shannon Deminick 1526 posts 5272 karma points MVP 3x
    Jun 02, 2015 @ 22:47
    Shannon Deminick
    1

    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.

  • Petter Christie 5 posts 26 karma points
    Jun 04, 2015 @ 08:52
    Petter Christie
    0

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

     

  • Shannon Deminick 1526 posts 5272 karma points MVP 3x
    Jun 04, 2015 @ 10:48
    Shannon Deminick
    0

    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.

Please Sign in or register to post replies

Write your reply to:

Draft