ASP.NET Requests and .NET 4.5 - Strange Behavior

Question

We are getting some strange behavior on our site after upgrading the product to .NET 4.5. I will try to be as specific as possible but the problem is vague, so please bear with me. Also, for this scenario, work under the assumption that no best practices have been followed.

The user is coming to a page that makes a number of jquery ajax calls, asynchronously, to a webservice. Because of the poor design/coding on this page, it can take forever to load, but it does provide a sub menu that the user needs access to. Once the page begins to load, they click one of the menu options to go to another page. Nothing too special so far.

When we use perfmon on a box with .NET 4.0 only installed, we can see the ASP.NET Requests go up and down, as you would expect:

When we install it on a box with .NET 4.5 installed we get this:

After executing the workflow I described above, the request get hung up. Not queued; they just sit there.

After further research, we are noticing that the clicking between the two different pages is not just a simple href, but is actually using Response.Redirect(url);

Also, this is only happening when using IE. This is not an issue when using Firefox and Chrome.

Here is what we have tried so far:

1. We have contacted M$ and sent them out DebugDiag dumps. Still waiting.
2. I have gone to IIS, set the site to trace failed requests, and have set up a failed request filter to give me everything. Once the site locks, I clear the logs, and then examine what comes in after the site locks. Everytime it is getting hung between the AspNetSessionDataBegin and the AspNetSessionDataEnd events.
3. We do have an HttpHandler that reads/writes to the session, and disabling it does seem to fix the problem for the most part, but no explanation as to why.
4. jquery's onunload handler, which should clean up and abort all remaining xmlhttp requests, appears to not be executing constantly.
5. Installed this patch, still didn't help.
6. We are currently changing the Response.Redirect(url) methods in this navigation logic to be Response.Redirect(url, false); (See above).

Also as requested, here is the HttpHandler code:

public class KeepSessionAliveHttpHandler : IHttpHandler, IRequiresSessionState
{
    public bool IsReusable
    {
        get { return true; }
    }

    public void ProcessRequest(HttpContext context)
    {

        if (context.Session.IsNewSession)
        {
            string redirectUrl = context.Request.Url.AbsoluteUri.Replace(context.Request.Url.AbsolutePath, VirtualPathUtility.ToAbsolute(Constant.Page_Logout));
            context.Response.Clear();
            context.Response.ContentType = "application/json; charset=utf-8";
            context.Response.Flush();
            context.Response.Write("{\"IsSessionAlive\": \"false\", \"RedirectUrl\": \"" + redirectUrl + "\"}");
        }
        else
        {
            context.Session["KeepSessionAlive"] = TimeZoneHelper.GetCurrentUtcDateTime();

            context.Response.Clear();
            context.Response.ContentType = "application/json; charset=utf-8";
            context.Response.Flush();
            context.Response.Write("{\"IsSessionAlive\": \"true\"}");
        }
    }
}

Any suggestions on where we should look next?

Answer 1

The following patch has now been released by Microsoft that appears to fix the issue without requiring web.config or IIS configuration changes. http://support.microsoft.com/kb/2828841/en-us http://support.microsoft.com/kb/2828842/en-us

Former Answer

After further investigation and insight/solutions provided by the .NET compatibility team, I am editing this answer.

The solution found at ManagedPipelineHandler for an AJAX POST crashes if an IE9 user navigates away from a page while that call was in progress does seem to be working more reliably for us. This is behavior we were experiencing in IE8-10, and not just 9 however.

I am going to keep the old answer here, as it hopefully may point people in another direction if the first answer is not relevant.

Former Former Answer

The source ended up being session locking. The AspNetSessionDataBegin and the AspNetSessionDataEnd events should have been a dead giveaway. For anyone that stumbles on this same problem, look to see when and how you are writing to the session. These links also helped.

Replacing ASP.Net's session entirely

I just discovered why all ASP.Net websites are slow, and I am trying to work out what to do about it