As a follow up to my previous post “When Page Output Caching Does Not Output” I have recorded a video which actually walks you through the steps and issues which I documented in this previous post. So for those of you whom don’t like to read all that much you may watch this video and/or refer back to my previous post on the same subject.
Recently I left Microsoft where I worked for almost 15 years and where about 10 of those years were spent in Escalation Services where my daily routine was debugging failing or faulting applications. This all began with user and kernel mode Windows processes and then once the .Net Framework shipped I move to the ASP.Net and CLR teams and began debugging more managed processes. Normally customers would send my team crash dumps or memory dumps of the offending process(s) and we would use tools such as WinDbg or CDB to dig deeper into the process to determine what was happening. There are several challenges when doing this type of work and one of the most painful is locating and referencing the correct symbols files (*.pdb).
In my previous post I documented a bug in SharePoint where a memory leak can greatly impact that amount of memory you SharePoint WFE will use during the normal processing of web request. The SharePoint PG just recently released the 2010 April CU for WSS 3.0 and MOSS 2007. It requires you have Service Pack 2 before installing these cumulative updates but I can tell you that is something you want to invest in.
Recently Mark Arend and I were helping out a co-worker setup Session State on SharePoint 2010 and he pointed out something very important; while I was providing the means to enable the “State Service” I was not providing the method to turn on ASP.Net session state. At first I was not clear on the distinction however once I read his email for the 3rd time after my second cup of coffee I finally got it..while I was using New-SPStateServiceDatabase to setup the State Service DB he was suggesting to use Enable-SPSessionStateService. Yea it looks pretty clear now that these are two very different commands however in my stupor after working on User Profile Sync issues over the past couple of days these were equal in my feeble mind.
I have been working with SharePoint for a few years now and have run into many nasty high memory or Out of Memory (OOM) issues. To date many of SharePoint’s memory problems have been discussed as problems with developers not using the Dispose pattern properly when using the SharePoint OM. And while I have found this to be the case I always had a feeling that there was something more, another larger leak which could not be explained simply by not calling Dispose. Sure not calling dispose will keep the SPRequest COM object (which is fairly large) around longer than necessary however ref-counting will clean these up eventually but even with using the correct coding patterns and practices the w3wp processes still seem larger than necessary; even on my development machine when I run stress against an out of the box installation. So there must be something else going on here; and so started my search for Big Foot.