I found many 8l1n warnings of undisposed objects in the SharePoint ULS logs. The interesting thing is that the entire stack trace does not show anything in my code. I am not sure what to look for in that case? Can it be some configuration error that led to that?

How can I avoid this warning?

ULS log below:

An SPRequest object was not disposed before the end of this thread.  To avoid wasting system resources, dispose of this object or its parent (such as an SPSite or SPWeb) as soon as you are done using it.  This object will now be disposed.  Allocation Id: {DBFA1F95-40DF-4AB6-BE88-3AE39F7E4E1F}  This SPRequest was allocated at    at Microsoft.SharePoint.Library.SPRequest..ctor()     at Microsoft.SharePoint.SPGlobal.CreateSPRequestAndSetIdentity(Boolean bNotGlobalAdminCode, String strUrl, Boolean bNotAddToContext, Byte[] UserToken, String userName, Boolean bIgnoreTokenTimeout, Boolean bAsAnonymous)     at Microsoft.SharePoint.SPWeb.InitializeSPRequest()     at Microsoft.SharePoint.SPWeb.EnsureSPRequest()     at Microsoft.SharePoint.SPWeb.get_Request()     at Microsoft.SharePoint.SPWeb.get_All...  
06/03/2009 10:21:05.10* w3wp.exe (0x170C)                       	0x10F8	Windows SharePoint Services   	General                       	8l1n	High    	...Properties()     at Microsoft.SharePoint.ApplicationPages.PermissionSetupPage.GetParentWebAssociatedGroups()     at Microsoft.SharePoint.ApplicationPages.PermissionSetupPage.OnLoad(EventArgs e)     at System.Web.UI.Control.LoadRecursive()     at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)     at System.Web.UI.Page.ProcessRequest(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)     at System.Web.UI.Page.ProcessRequest()     at System.Web.UI.Page.ProcessRequestWithNoAssert(HttpContext context)     at System.Web.UI.Page.ProcessRequest(HttpContext context)     at ASP._layouts_permsetup_aspx.ProcessRequest(HttpContext context)     at System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.H...
06/03/2009 10:21:05.10* w3wp.exe (0x170C)                       	0x10F8	Windows SharePoint Services   	General                       	8l1n	High    	...ttpApplication.IExecutionStep.Execute()     at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)     at System.Web.HttpApplication.ApplicationStepManager.ResumeSteps(Exception error)     at System.Web.HttpApplication.System.Web.IHttpAsyncHandler.BeginProcessRequest(HttpContext context, AsyncCallback cb, Object extraData)     at System.Web.HttpRuntime.ProcessRequestInternal(HttpWorkerRequest wr)     at System.Web.HttpRuntime.ProcessRequestNoDemand(HttpWorkerRequest wr)     at System.Web.Hosting.ISAPIRuntime.ProcessRequest(IntPtr ecb, Int32 iWRType)

2 Answers 2


Yea, sometimes microsoft doesn't follow it's own best practices. I mentioned it here: Disposal of spwebs created using spsite openweb

There is nothing really you can do about it.

  • Steve are you not reffering to the "Potentially excessive number of SPRequest objects" error which is just a warning that you can mitigate by setting higher treshold (as i mention in my answer)? The above error (8l1n) means you are not disposing your SPRequests as you should. This should not be ignored Jan 20, 2010 at 14:47
  • Ok, good call. I still don't see in his stack trace above any custom code being called. Jan 20, 2010 at 15:37
  • And this issue is not fixed in any Cumulative update or Hotfix for Sharepoint? Jan 21, 2010 at 7:58

You should review your code and properly dispose the SPSite, SPWeb (and others) you create yourself (as in "new SPObject(url)" and sites.OpenWeb()). These objects contains unmanaged SPRequest objects that will not automatically be disposed.

To assis you in this process you should use SPDisposeCheck (i usually set SPDisposeCheck to run automatically when i build my code).

Theres a whitepaper on MSDN that can assist you futher. Be aware that not all SPSite and SPWeb objects should be disposed. The SPSite's and SPWeb's taken from SPContext.Current should normally not be disposed. For further guidance on when not to dispose, see Roger Lambs "Do not dispose guidance".

Note: the above warning should not be confused with the "Potentiallt excessive number of SPRequest objects.." warning in ULS log. This warning does not necessarily indicate your objects are not being disposed, just that you have opened alot of them (like when doing a loop through current webs). This warning can be mitigated by setting up the treshold to a larger value:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\HeapSettings

    LocalSPRequestWarnCount = 50

Further reading:

Best Practices: Using Disposable Windows SharePoint Services Objects

Automate SharePoint Dispose() code reviews with SPDisposeCheck

SharePoint 2007/2010 “Do Not Dispose Guidance” + SPDisposeCheck

Troubleshooting SPSite/SPWeb leaks in WSS v3 and MOSS 2007

SharePoint 2007 and WSS 3.0 Dispose Patterns by Example

hth Anders Rask

  • 1
    I understand what you are saying. My Problem is that it is in SharePoint Code written by microsoft as you can see in the stack trace above.. the entire trace is within Microsoft.* and System.* namespaces :) Jan 20, 2010 at 12:39
  • try setting the following setting in registry to see where object was allocated: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\HeapSettings. Create a new DWORD named SPRequestStackTrace with the value 1 under this key (you might already have done this since you got full stack trace) or search for Allocation Id: {DBFA1F95-40DF-4AB6-BE88-3AE39F7E4E1F}in the ULS log. Jan 20, 2010 at 18:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.