Access Checker crashes application pool

Jul 16, 2009 at 1:10 PM

For the past several months, we've had multiple instances where CPU would become pegged on one of our web front end servers. All sites hosted by a particular application pool would become unresponsive and return "Server is too busy" in the browser. After working with Microsoft support, they identified several memory leaks with the Access Checker web part and believe that this is the root cause of the app pool crashes. We were running Access Checker v1.2 but this web part has now been uninstalled until we can be certain that the memory leaks have been fixed. Have these been fixed in the 1.3 release?

Per Microsoft support:

*******************************
Reviewing the dumps we could notice there is memory pressure. This is normally related to memory leak in one or more custom modules. Reviewing the modules in memory contained in the dump, and using SP Dispose Check tool (available in Codeplex), we could identify the modules and points of memory leak. The list contains two categories: memory leaks for sure and memory leak candidates (they are most certainly memory leaks but they may also be false positives). If you follow the link in any indication you will see the reason and how to fix it.

Points of Memory Leaks for sure:
==========================
ID: SPDisposeCheckID_120
Module: AccessCheckerWebPart.dll
Method: TomShirley.WebParts.AccessChecker.AccessCheckerWebPart.BuildTreeView
Statement: this._SharepointTreeView.{System.Web.UI.WebControls.TreeView}get_Nodes().{System.Web.UI.WebControls.TreeNodeCollection}Add(this.{TomShirley.WebParts.AccessChecker.AccessCheckerWebPart}ExpandWeb(this._CurrentSite.{Microsoft.SharePoint.SPSite}OpenWeb(this._CurrentWeb.{Microsoft.SharePoint.SPWeb}get_ID()), 0, 30, 1))
Notes: Call to Microsoft.SharePoint.SPSite.OpenWeb and no variable to catch return value
More Information: http://blogs.msdn.com/rogerla/archive/2008/02/12/sharepoint-2007-and-wss-3-0-dispose-patterns-by-example.aspx#SPDisposeCheckID_120
----------------------------------------------------------


ID: SPDisposeCheckID_130
Module: AccessCheckerWebPart.dll
Method: TomShirley.WebParts.AccessChecker.AccessCheckerWebPart.ExpandWeb(Microsoft.SharePoint.SPWeb,System.Int32,System.Int32,System.Boolean)
Statement: local0 := this._CurrentSite.{Microsoft.SharePoint.SPSite}OpenWeb(currentWeb.{Microsoft.SharePoint.SPWeb}get_Webs().{Microsoft.SharePoint.SPWebCollection}get_Item(local3).{Microsoft.SharePoint.SPWeb}get_ID())
Notes: Call to Microsoft.SharePoint.SPWebCollection.get_Item and no variable to catch return value
More Information: http://blogs.msdn.com/rogerla/archive/2008/02/12/sharepoint-2007-and-wss-3-0-dispose-patterns-by-example.aspx#SPDisposeCheckID_130
----------------------------------------------------------


ID: SPDisposeCheckID_130
Module: AccessCheckerWebPart.dll
Method: TomShirley.WebParts.AccessChecker.AccessCheckerWebPart.ExpandWebAsAdmin
Statement: this._webTreeNode := this.{TomShirley.WebParts.AccessChecker.AccessCheckerWebPart}ExpandWeb(local1.{Microsoft.SharePoint.SPWeb}get_Webs().{Microsoft.SharePoint.SPWebCollection}get_Item(this._subWebIndex.{System.Collections.Generic.Stack`1}Peek()), 0, 30, 0)
Notes: Call to Microsoft.SharePoint.SPWebCollection.get_Item and no variable to catch return value
More Information: http://blogs.msdn.com/rogerla/archive/2008/02/12/sharepoint-2007-and-wss-3-0-dispose-patterns-by-example.aspx#SPDisposeCheckID_130
----------------------------------------------------------


ID: SPDisposeCheckID_230
Module: AccessCheckerWebPart.dll
Method: TomShirley.WebParts.AccessChecker.UpdateLayoutsSitemap.#ctor(Microsoft.SharePoint.Administration.SPWebApplication,System.String,System.Boolean)
Statement: this._siteUri := WebApp.{Microsoft.SharePoint.Administration.SPWebApplication}get_Sites().{Microsoft.SharePoint.Administration.SPSiteCollection}get_Item(0).{Microsoft.SharePoint.SPSite}get_RootWeb().{Microsoft.SharePoint.SPWeb}get_Url()
Notes: Call to Microsoft.SharePoint.Administration.SPSiteCollection.get_Item and no variable to catch return value
More Information: http://blogs.msdn.com/rogerla/archive/2008/02/12/sharepoint-2007-and-wss-3-0-dispose-patterns-by-example.aspx#SPDisposeCheckID_230
----------------------------------------------------------


Strong Candidates of memory leak:
===========================
ID: SPDisposeCheckID_120
Module: AccessCheckerWebPart.dll
Method: TomShirley.WebParts.AccessChecker.AccessCheckerWebPart.ExpandWeb(Microsoft.SharePoint.SPWeb,System.Int32,System.Int32,System.Boolean)
Statement: local0 := this._CurrentSite.{Microsoft.SharePoint.SPSite}OpenWeb(currentWeb.{Microsoft.SharePoint.SPWeb}get_Webs().{Microsoft.SharePoint.SPWebCollection}get_Item(local3).{Microsoft.SharePoint.SPWeb}get_ID())
Notes:  Disposable type not disposed: Microsoft.SharePoint.SPWeb
                 ***This may be a false positive depending on how the type was created or if it is disposed outside the current scope
More Information: http://blogs.msdn.com/rogerla/archive/2008/02/12/sharepoint-2007-and-wss-3-0-dispose-patterns-by-example.aspx#SPDisposeCheckID_120
----------------------------------------------------------

Coordinator
Jul 17, 2009 at 12:01 AM
This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.
Coordinator
Jul 17, 2009 at 1:47 AM

Hi,
 I've identified these issues in both v1.2.0 and v1.3.0, and added a work item to get them fixed asap. Tonights check-in will plug these holes.

In the past, i've required Microsoft's support services to resolve a SharePoint alert issue, so i understand the time and effort that you've put into investigating a problem like this before bringing Microsoft in.

The best approach would be to grab the latest build directory after tonights check-in, install it into a testing environment and run the 'Check User Access' operation over roughly the same number of subwebs as in your prod environment.

I would of thought that memory leaking problems would culminate in the app pool being recycled once it reached a set memory limit, has this happened in your case?

Tom.

 

Coordinator
Jul 18, 2009 at 9:09 AM

Check-In 24376 fixes the aforementioned memory leaks.

Tom.