Troubleshooting SPSite/SPWeb leaks in WSS v3 and MOSS 2007

re: Troubleshooting SPSite/SPWeb leaks in WSS v3 and MOSS 2007

Emmanuel Desigaud — Wed, 07 May 2008 17:57:38 GMT

Extremely useful as usual !! Thanks !!

Troubleshooting SPSite/SPWeb leaks in WSS v3 and MOSS 2007

Bobby Habib SharePoint & MOSS Blogging Space — Thu, 15 May 2008 05:18:02 GMT

Just wanted to make the community aware of a new blog just written by Stefan Gobner (EE Engineer at Microsoft

re: Troubleshooting SPSite/SPWeb leaks in WSS v3 and MOSS 2007

Alex Dresko — Thu, 15 May 2008 21:18:19 GMT

I do not have that particular key in my entire registry. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions is there, but HeapSettings is not. Can I safely create that structure?

re: Troubleshooting SPSite/SPWeb leaks in WSS v3 and MOSS 2007

Tim C — Thu, 15 May 2008 21:46:50 GMT

Some of those best practices require you to know that an INTERNAL method call is made which creates a web that you are in charge of disposing of, e.g., SPList.BreakRoleInheritance(). How can you possibly know to call list.ParentWeb.Dispose(); after you call BreakRoleInheritance? Why doesn't SPList just implement IDisposable? If it has objects that need to be disposed? Isn't that the proper pattern for IDisposable?

re: Troubleshooting SPSite/SPWeb leaks in WSS v3 and MOSS 2007

Stefan_Gossner — Thu, 15 May 2008 23:44:25 GMT

Hi Alex,

yes you need to cretae this key and the DWORD value below it.

They do not exist after installing the product.

Cheers,

Stefan

re: Troubleshooting SPSite/SPWeb leaks in WSS v3 and MOSS 2007

Stefan_Gossner — Thu, 15 May 2008 23:45:45 GMT

Hi Tim,

there is always room for improvement.

Cheers,

Stefan

Properly Disposing of SharePoint API Objects

Tony Testa's World — Fri, 16 May 2008 18:23:49 GMT

Properly Disposing of SharePoint API Objects

Troubleshooting SPSite/SPWeb leaks in WSS v3 and MOSS 2007

Shared Points for SharePoint... — Wed, 28 May 2008 08:58:40 GMT

Stefan Gossner has published a great article on the subject: In an earlier article I have discussed that

re: Troubleshooting SPSite/SPWeb leaks in WSS v3 and MOSS 2007

Kristian Kjær — Wed, 28 May 2008 11:19:45 GMT

Hi Stefan

Excellent article. I was going crazy over the intensive logging for no reason! I have a question though regarding the sitemapprovider. I use the standard CurrentNavSiteMapProvider from the publishing infrastructure. How can I limit this to say 2 levels? I can set the StaticDisplayLevels in my Menu control, but as I read your article, this will not reduce the creation of SPWeb objects? I have to make the CurrentNavSiteMapProvider reduce this creation by telling it to go only two levels deep. Or am I missing something?

Regards

re: Troubleshooting SPSite/SPWeb leaks in WSS v3 and MOSS 2007

Stefan_Gossner — Wed, 28 May 2008 13:12:27 GMT

Hi Kristian,

I was talking about the StaticDisplayLevels and DynamicDisplayLevels settings of the navigation controls.

Cheers,

Stefan

re: Troubleshooting SPSite/SPWeb leaks in WSS v3 and MOSS 2007

Kristian Kjær — Wed, 28 May 2008 13:35:13 GMT

But does this mean that by using StaticDisplayLevels and DynamicDisplayLevels I also limits the creation of SPWebs?

re: Troubleshooting SPSite/SPWeb leaks in WSS v3 and MOSS 2007

Stefan_Gossner — Wed, 28 May 2008 14:20:21 GMT

Hi Kristian,

the answer is yes. The site map provider does not create any objects on its own. Only if being asked for nodes from the navigation control it will create these objects. And the navigation control decides to which level this will be retrieved and that means the navigation control decides how many objects are created.

Cheers,

Stefan

re: Troubleshooting SPSite/SPWeb leaks in WSS v3 and MOSS 2007

Kristian Kjær — Wed, 28 May 2008 17:52:16 GMT

Cool. Thanks for the good (and fast!) answers. As I said, it (the answers and the blog) has really clarified things!

SharePoint (Coding) und Speicherverwaltung

Marco Scheel aka GeekDotNet — Sun, 15 Jun 2008 21:25:33 GMT

Folgende Artikel behandeln das Thema oder die Auswirkung: Best Practices: Using Disposable Windows SharePoint Services Objects http://msdn2.microsoft.com/en-us/library/aa973248.aspx Best Practices: Common Coding Issues When Using the SharePoint Object

Troubleshooting SPSite/SPWeb leaks and the Importance of Loadtesting

Mirrored Blogs — Tue, 24 Jun 2008 20:08:36 GMT

Stefan has a good article on troubleshooting leaks in your WSS and MOSS applications. One of the very

re: Troubleshooting SPSite/SPWeb leaks in WSS v3 and MOSS 2007

Markus — Tue, 24 Jun 2008 23:57:59 GMT

Very great article.

But how can i create a complete sitemap if I have a publishing site?

re: Troubleshooting SPSite/SPWeb leaks in WSS v3 and MOSS 2007

Stefan_Gossner — Mon, 30 Jun 2008 15:16:02 GMT

Hi Markus,

you can (e.g.) create a console application which enumerates the whole site structure and creates the XML file which can then be used by the standard ASPNET XML sitemap provider.

Cheers,

Stefan

re: Troubleshooting SPSite/SPWeb leaks in WSS v3 and MOSS 2007

Michael — Mon, 07 Jul 2008 08:49:53 GMT

And what about security trimming about the single sitemapnodes when creating a sitemap in an XML file and use it as sitemap provider? I think this cannot be done easily... :(

re: Troubleshooting SPSite/SPWeb leaks in WSS v3 and MOSS 2007

Stefan_Gossner — Mon, 07 Jul 2008 09:15:22 GMT

Hi Michael,

you are correct. This approach is good for anonymous sites or site where no security trimming is required.

For sites where security trimming is required you either have to ensure that the tree structure is not very complex or you should look for a 64-bit machine where more memory can be made available per worker process.

Cheers,

Stefan

Stefan Goßner : Troubleshooting SPSite/SPWeb leaks in WSS v3 and MOSS 2007

SharePoint Thinks, Links and Clinks — Wed, 30 Jul 2008 17:55:35 GMT

Another holding post that I need to get back to. Excellent read! Stefan Goßner : Troubleshooting SPSite/SPWeb

re: Troubleshooting SPSite/SPWeb leaks in WSS v3 and MOSS 2007

JDP — Tue, 12 Aug 2008 02:14:48 GMT

So what is the GUID in the Allocation ID? Is that a feature GUID?

re: Troubleshooting SPSite/SPWeb leaks in WSS v3 and MOSS 2007

Stefan_Gossner — Tue, 12 Aug 2008 09:51:17 GMT

Hi JDP,

no this is not the feature ID. It is a GUID generated at the momement when the object is allocated in memory. So you cannot use it to track it down to anything on the file system.

Cheers,

Stefan

re: Troubleshooting SPSite/SPWeb leaks in WSS v3 and MOSS 2007

JDP — Thu, 14 Aug 2008 01:27:35 GMT

Thank you, Stefan. A client's server has these errors on rare occasion, and it's quite difficult to pinpoint their origin. It would be quite helpful if some technical information could be included in the error to facilitate analysis.

re: Troubleshooting SPSite/SPWeb leaks in WSS v3 and MOSS 2007

Stefan_Gossner — Thu, 14 Aug 2008 12:19:36 GMT

Hi JDP,

which error do you mean? The SPRequest leak?

Actually using the steps above you have the complete callstack of the allocation! That is all technical information you need to pinpoint the piece of code that causes the problem.

Cheers,

Stefan

re: Troubleshooting SPSite/SPWeb leaks in WSS v3 and MOSS 2007

JDP — Thu, 14 Aug 2008 19:40:18 GMT

To clarify -- it's surprising that event tells you how to get the stack, rather than providing it explicitly.

Adding the reg key does work great, and helps, but IMHO the logging behavior provided by the reg key should be the "out of the box" setting.

And since I haven't said it yet -- thanks for writing this! You're one of the most knowledgeable resources around.

re: Troubleshooting SPSite/SPWeb leaks in WSS v3 and MOSS 2007

Alex Hekstra — Fri, 03 Oct 2008 17:24:55 GMT

Stefan,

Thanks for this great insight. The problem has been nagging me since ages...

I do have a problem. I've developed a webpart that pulls information from the parent web. When the webpart is initialised, I use SPContext.Current to get the web, and from that I get the parent SPWeb. During CreateChildControls, I build a UI with the information. During post back handling, the web references are used too. Probably just after rendering I could dispose the sharepoint objects.

I understand that I cannot Dispose() the current web as it is owned by the webpart manager or page, and I need to Dispose() the parent web because I referenced it.

Now here is my problem. If I have second webpart that also references the parent web, I don't know when to free it.

If I overwrite the Render() method to dispose the parent web after rendering, I get "SPException: Trying to use an SPWeb object that has been closed or disposed and is no longer valid." Apparently the second webpart still references and needs the same object (seems to be quite logical as they both get it from the SPContext), and still needs it after rendering.

If I dispose the parent web in the UnLoad(), it works most of the times, but sometimes I get a message in the log that the object is freed on a different thread then when it was created. It is not on my development machine (single CPU), but I've seen it on a testing environment. But also, UnLoad() seems to be happening only after a while, so that violates the best practice of holding on to SharePoint objects only for a short time.

So what should I do? Would limiting the life span of a ParentWeb be a solution? That would mean that I will have to get/dispose it for 2 to 4 times per page view per webpart. What impact will that have on performance?

So, what _IS_ the best practice handling derefenced SPWebs or SPSites (e.g. through ParentWeb, Site, RootWeb and the like)?

I would like to make a suggestion that the SharePoint development team changes the rules, so that all SPWebs, SPSites etc. that are opened through deferencing (e.g. SPWeb.ParentWeb, SPWeb.Site, SPSite.RootWeb SPSite.AllWebs() etc.) are property of the "owning" object, and will be disposed of by that owning object. For my example, the parent web should be disposed of when the context web (the one I get through SPContext.Current) is disposed of by the webpart page manager.

Or, even better: make sure the GC can do it's work properly. The current system looks like an even bigger mess than badly implemented COM objects. Or please tell me that I am wrong!

Thanks again for the insight, and I hope you can clear things up further for me!

Cheers,

Alex

re: Troubleshooting SPSite/SPWeb leaks in WSS v3 and MOSS 2007

Stefan_Gossner — Mon, 13 Oct 2008 15:14:29 GMT

Hi Alex,

all SPSite/SPWeb objects retrieved through SPContext are not required to be disposed. This also includes SPSite/SPWeb objects created as reference from other SPSite/SPweb objects retrieved through SPContext.

The SPContext object tracks all SPSite/SPWeb objects created from its objects and disposes them as soon as the SPContext object is disposed at the end of the request.

Cheers,

Stefan

re: Troubleshooting SPSite/SPWeb leaks in WSS v3 and MOSS 2007

Robert Standefer — Wed, 22 Oct 2008 16:33:43 GMT

Stefan,

I've made the change in the Registry (added the HeapSettings key and the SPRequestStackTrace DWORD) but the stack trace doesn't appear in my logs. I've checked and double-checked the Registry setting. Am I looking in the wrong place? Is there some kind of reset I need to do?

I've posted about this problem on Stack Overflow: http://stackoverflow.com/questions/218613/proper-disposal-of-sharepoint-objects

re: Troubleshooting SPSite/SPWeb leaks in WSS v3 and MOSS 2007

Stefan_Gossner — Wed, 22 Oct 2008 16:36:19 GMT

Hi Robert,

sounds as if you did not restart the process.

The registry change requires a restart of the services to be catched.

Cheers,

Stefan

re: Troubleshooting SPSite/SPWeb leaks in WSS v3 and MOSS 2007

Jason Riley — Thu, 23 Oct 2008 22:37:00 GMT

Hi Stefan,

I have a SharePoint Publishing site that I created in SharePoint Designer. I'm not using any custom code to my knowledge but my default.aspx page will not load on certain systems resulting in a memory error. Could my publishing site be suffering from memory leak issues? I guess my question is if I didn't use any custom code to create this Publishing Site are the SPweb, SPsite and PublishingWeb objects being properly disposed?

Thanks,

Jason

re: Troubleshooting SPSite/SPWeb leaks in WSS v3 and MOSS 2007

Stefan_Gossner — Fri, 24 Oct 2008 13:10:29 GMT

Hi Jason,

if you did not code anything and did not include any 3rd party component then everything should be properly disposed.

I would suggest to open a support call with Microsoft to get this problem analyzed in more detail.

Cheers,

Stefan

re: Troubleshooting SPSite/SPWeb leaks in WSS v3 and MOSS 2007

Martin — Wed, 12 Nov 2008 02:08:21 GMT

Hi Stefan,

The question I ask myself is why not just expose SiteMapNode properties only (eg Title, Url), until the code actually asks for SPWeb specific data (through PortalWebSiteMapNode.GetProperty)

I appreciate it needs to be security trimmed, but it seems wasteful to create a whole SPWeb object (with 2Mb unmanaged object) just to get lightweight info for navigation.

Is there a roadmap for improving this?

Thanks

Martin

re: Troubleshooting SPSite/SPWeb leaks in WSS v3 and MOSS 2007

Stefan_Gossner — Wed, 12 Nov 2008 12:37:06 GMT

Hi Martin,

in order to fill the SiteMapNode properties you have to read them from the underlaying object. So the SPWeb object has to be created to read the URL and Title from it and fill it into the site map node object.

That's what happens.

Cheers,

Stefan

re: Troubleshooting SPSite/SPWeb leaks in WSS v3 and MOSS 2007

Martin — Wed, 12 Nov 2008 21:57:06 GMT

Hi Stefan,

Thanks for the swift reply. (I hope this isn't a double post)

Would it be wrong to call this a design flaw?

We have objects like SPQuery to get efficient access to other types of SharePoint data without the overhead of the object model, what about something similar for navigation?

Thanks

Martin

re: Troubleshooting SPSite/SPWeb leaks in WSS v3 and MOSS 2007

Stefan_Gossner — Thu, 13 Nov 2008 11:29:26 GMT

Hi Martin,

I'm not sure if you could easily implement the required functionality - e.g. enumeration of child sites with optional security trimming as provided by the site map providers - without instantiating the actual objects.

Cheers,

Stefan

SPDisposeCheck tool has been official announced

Stefan Goßner — Thu, 13 Nov 2008 12:28:03 GMT

I have discussed problems with missing dispose for SPWeb and SPSite objects earlier on my blog (e.g.

Disposing SPWeb and SPSite objects

Stefan Goßner — Fri, 05 Dec 2008 17:36:50 GMT

There are several articles around discussing the dispose of SPWeb and SPSite objects, e.g.: SharePoint

Linki do prezentacji o zarządzaniu obiektami

.neting in the free world — Tue, 16 Dec 2008 01:39:54 GMT

Linki, które posłużyły mi przy tworzeniu prezentacji, z których czerpałem wiedzę, nakładałem ją na to

When to Dispose SharePoint objects

Confluence: SharePoint Development Wiki — Thu, 15 Jan 2009 11:08:32 GMT

SPSite and SPWeb implement the IDisposable interface

re: Troubleshooting SPSite/SPWeb leaks in WSS v3 and MOSS 2007

Peter — Sat, 17 Jan 2009 18:16:33 GMT

Hi stefan,

Thanks for your effort to explain this to us. Specifically, I notice the "Potentially excessive number of SPRequest objects" (max 21 in one thread) only during the first use of a solution after an IISRESET.

After this the use does not generate log entries about excessive sprequest. Is this normal?

Peter.

re: Troubleshooting SPSite/SPWeb leaks in WSS v3 and MOSS 2007

Stefan_Gossner — Sat, 17 Jan 2009 18:25:15 GMT

Hi Peter,

that depends on your solution and what code is executed in the requests. E.g. caching could explain this.

Cheers,

Stefan

re: Troubleshooting SPSite/SPWeb leaks in WSS v3 and MOSS 2007

Peter — Wed, 21 Jan 2009 18:12:01 GMT

Stefan, thanks for the answer.

1. Is it safe to conclude that as long I don't get 8l1n (..object was not disposed before the end of this thread) I can ignore the excessive SPRequest objects entries in the logs?

2. Are 21 SPObjects really excessive for an 64bit environment?

re: Troubleshooting SPSite/SPWeb leaks in WSS v3 and MOSS 2007

Peter — Wed, 21 Jan 2009 18:56:37 GMT

Stefan,

About caching. I use

SPUtility.RunWithElevatedPrivilegies() and the application Pool identity is not local admin.

I read -> "... this will simply revert the current user identity to the identity of the current application pool, and if this identity is not a farm administrator ->then<- your SPSite _will_ be cached in the SPRequestContext" [Understanding SharePoint SPRequest- Hristo Pavlov’s Blog].

What if in an environment the identity pool is local admin. Should I then see the "Potentially excessive number of SPRequest objects" in every consequent use?

Peter

re: Troubleshooting SPSite/SPWeb leaks in WSS v3 and MOSS 2007

Stefan_Gossner — Wed, 21 Jan 2009 19:13:08 GMT

Hi Peter,

1) that depends on how high the number is in the "excessive" message. If it in the range you expect for your application you can ignore them.

2) 21 objects is actually a very small number.

Cheers,

Stefan

re: Troubleshooting SPSite/SPWeb leaks in WSS v3 and MOSS 2007

Stefan_Gossner — Wed, 21 Jan 2009 19:17:06 GMT

Hi Peter,

RunWithElevatedPrivileges will create a new SPSite object - independent from the account.

The caching that happens in some situations is only for the current http request.

From SPRequest perspective there is no difference if the SPSite object is cached or not.

Cheers,

Stefan

re: Troubleshooting SPSite/SPWeb leaks in WSS v3 and MOSS 2007

Kim — Thu, 09 Apr 2009 18:48:54 GMT

Stefan,

Even after setting SPRequestStackTrace to 1 and running iisreset, we are still *not* getting stack traces for the 8l1n messages.

Do you know why this might be ?

Thanks,

Kim

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\HeapSetting]

"SPRequestStackTrace"="1"

re: Troubleshooting SPSite/SPWeb leaks in WSS v3 and MOSS 2007

Stefan_Gossner — Thu, 09 Apr 2009 19:07:27 GMT

Hi Kim,

the registry key above is wrong. You used "HeapSetting" where it should be "HeapSettings". Notice the missing "s" at the end.

Cheers,

Stefan

re: Troubleshooting SPSite/SPWeb leaks in WSS v3 and MOSS 2007

Kim — Thu, 09 Apr 2009 19:36:48 GMT

Stefan,

Sorry, I copied the information from a different site when I wa composing the blog comment. But we actually did use the HeapSettings

Below is what we've set.

Have you actually seen it generate a stack trace for the 8l1n messages ? What's interesting is that we do get stack traces for the SPRequest warning messages. I assume that this one setting controls the stack trace for both sets. So why is a stack trace appearing for one set and not the other ?

Also, I wonder if there's anything else we need to configure to get the stack traces displayed for the 8l1n messages. This is a bit frustrating as it seems to me that these are the actually useful stack traces...

Kim

Windows Registry Editor Version 5.00

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

"SPRequestStackTrace"=dword:00000001

re: Troubleshooting SPSite/SPWeb leaks in WSS v3 and MOSS 2007

Stefan_Gossner — Thu, 09 Apr 2009 20:50:44 GMT

Hi Kim,

yes I use it quite often when working on customer cases. Around 2-3 times a month.

Its always working.

Cheers,

Stefan

re: Troubleshooting SPSite/SPWeb leaks in WSS v3 and MOSS 2007

Kim — Thu, 09 Apr 2009 22:40:34 GMT

Stefan,

Thanks for your help ! I restarted sharepoint services and the www publishing service, and I'm seeing the allocation stack traces for the 8l1n messages. :).

Best,

Kim.

re: Troubleshooting SPSite/SPWeb leaks in WSS v3 and MOSS 2007

Kim — Mon, 13 Apr 2009 17:40:01 GMT

Stefan,

I'm not sure if I'm reading this correctly, but it looks like I am getting stack traces for the 'object was not disposed before the end of this thread.' Interestingly, I *am* getting stack traces for the 'object was reclaimed by the garbage collector instead of being explicitly freed.' I thought both stack traces were controlled by the same registry value ?

Am I misreading this ? Do you have any insight into why this might be ?

Thanks,

Kim.

****************************************************************

04/13/2009 10:19:25.02 : w3wp.exe (0x0CA8) 0x129CWindows SharePoint Services General 8l1nMonitorable

****************************************************************

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: {7B27433F-4E67-491A-BA7F-B274D9048165} To determine where this object was allocated, create a registry key at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\HeapSettings. Then create a new DWORD named SPRequestStackTrace with the value 1 under this key.

****************************************************************

04/13/2009 10:19:25.02 : w3wp.exe (0x0CA8) 0x129CWindows SharePoint Services General 8l1nMonitorable

****************************************************************

An SPRequest object was reclaimed by the garbage collector instead of being explicitly freed. 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. Allocation Id: {A143F475-52DD-45BC-B897-AF4C9BEFFBC1} 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.SPFieldCollection.EnsureFieldsSafeArray(Boolean bGetFullXML)

at Microsoft.SharePoint.SPFieldCollection.Undirty(Boolean bGetFullXML)

at Microsoft.SharePoint.SPFieldCollection.Undirty()

at Microsoft.SharePoint.SPBaseCollection.System.Collections.IEnumerable.GetEnumerator()

at GreyPkgWFApproval.Utils.getMissingFields(SPList spList, String[] listColumns)

re: Troubleshooting SPSite/SPWeb leaks in WSS v3 and MOSS 2007

Stefan_Gossner — Mon, 13 Apr 2009 18:17:57 GMT

Hi Kim,

that is interesting. Haven't seen this.

Anyway: the stack clearly shows the 3rd party control that is causing the leak.

Cheers,

Stefan

re: Troubleshooting SPSite/SPWeb leaks in WSS v3 and MOSS 2007

Kim — Mon, 13 Apr 2009 21:56:28 GMT

This is pretty weird, but it might help other people who may have run into the same issue (stack trace not appearing for the 'object was not disposed before the end of this thread').

I tried configuring the related IIS application pool so that it would recycle the worker process after 1 request. This actually caused the stack trace to start appearing for the above type messages. Then, to double-check, I de-selected the 'Recycle worker process(number of requests)' option and noted that the stack trace no longer appeared. Instead it presented the misleading message about setting the SPRequestStackTrace DWORD value to 1 -- misleading because it had already been set.

Finally, I set the 'Recyle worker process (number of requests)' to 10 and the stack trace appeared again for the above 'end of thread' type messages.

By the way, for all of the above experiments, I had the 'Recycle worker processes(in minutes)' also selected and set to 15 minutes.

So I think this may be a bizarre Microsoft bug, where the 'end of thread' stack traces only appears if the number of requests item is selected.

Between the two log messages below, the only change I made was to select and set the 'Recycle worker process (number of requests')

to 10.

Kim.

****************************************************************

04/13/2009 14:40:31.96 : w3wp.exe (0x1428) 0x1470Windows SharePoint Services General 8l1nMonitorable

****************************************************************

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: {A00EAB6F-6BF1-4A5D-A502-AD330B3C3373} To determine where this object was allocated, create a registry key at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\HeapSettings. Then create a new DWORD named SPRequestStackTrace with the value 1 under this key.

****************************************************************

04/13/2009 14:47:43.22 : w3wp.exe (0x1400) 0x14F0Windows SharePoint Services General 8l1nHigh

****************************************************************

at Microsoft.SharePoint.Library.SPRequest..ctor()

at Microsoft.SharePoint.SPSite.GetSPRequest()

at Microsoft.SharePoint.SPSite.get_Request()

at Microsoft.SharePoint.SPSite.GetReusableAclForScope(Guid scopeId)

at Microsoft.SharePoint.Publishing.AclCache.GetAclForScope(Guid scopeId)

at Microsoft.SharePoint.Publishing.CachedArea..ctor(PublishingWeb area, String id, String parentId, String title, String url, String description, CachedObjectFactory factory)

at Microsoft.SharePoint.Publishing.CachedArea.CreateCachedArea(PublishingWeb area, CachedObjectFactory factory, String parentId)

at Microsoft.SharePoint.Publishing.CachedObjectFactory.CreateObject(PublishingWeb area, String parentUrl)

at Microsoft.SharePoint.Publishing.CachedObjectFactory.CreateObject(PublishingWeb area)

re: Troubleshooting SPSite/SPWeb leaks in WSS v3 and MOSS 2007

Kim — Mon, 13 Apr 2009 22:21:46 GMT

Stefan,

Just an update -- this might be useful to other people as well:

Basically, it looks like the IIS application pool property 'Recycle worker process (number of requests)' is the critical property to set, and the only one that generates a stack trace for the 'object was not disposed before the end of this thread' message. It's best to leave the other recycle options deselected, as if they trigger, they actually won't generate a stack trace. I've verified this for the 'Recycle worker processes (in minutes)' option.

I have not verified whether the Memory recycling options also generate a stack trace for the 'object was not disposed before the end of this thread' message(s).

Best,

Kim.

re: Troubleshooting SPSite/SPWeb leaks in WSS v3 and MOSS 2007

Kim — Mon, 13 Apr 2009 22:41:11 GMT

Stefan,

Just an update -- this might be useful to other people as well:

I have not verified whether the Memory recycling options also generate a stack trace for the 'object was not disposed before the end of this thread' message(s).

Best,

Kim.

SharePOint: Excessive SPRequests Objects

Dennis J. Bottjer | MVP ASP.NET — Wed, 15 Apr 2009 00:55:42 GMT

Issue: SharePoint Sites may log “Excessive SPRequest Objects,” under normal use. When I first saw this

re: Troubleshooting SPSite/SPWeb leaks in WSS v3 and MOSS 2007

Cornelius J. van Dyk — Wed, 04 Nov 2009 19:31:30 GMT

Hey Stefan,

We implemented your recommended changed on our QA SharePoint WFE server and then the WFE started throwing the following error for some unknown reason:

Server Error in '/' Application.

--------------------------------------------------------------------------------

Specified cast is not valid.

Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.

Exception Details: System.InvalidCastException: Specified cast is not valid.

Source Error:

An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.

Stack Trace:

[InvalidCastException: Specified cast is not valid.]

Microsoft.SharePoint.SPRequestManager.get_SPRequestsPerThreadWarning() +588

Microsoft.SharePoint.SPRequestManager.Add(SPRequest request, Boolean shareable) +695

Microsoft.SharePoint.SPGlobal.CreateSPRequestAndSetIdentity(Boolean bNotGlobalAdminCode, String strUrl, Boolean bNotAddToContext, Byte[] UserToken, String userName, Boolean bIgnoreTokenTimeout, Boolean bAsAnonymous) +2626

Microsoft.SharePoint.SPRequestManager.GetContextRequest(SPRequestAuthenticationMode authenticationMode) +192

Microsoft.SharePoint.Administration.SPFarm.get_RequestNoAuth() +25

Microsoft.SharePoint.ApplicationRuntime.SPHttpHandler.get_Hash() +162

Microsoft.SharePoint.ApplicationRuntime.SPHttpHandler.get_AppDomainIdHeader() +152

Microsoft.SharePoint.ApplicationRuntime.SPHttpHandler.OverrideExecuteUrlPath() +507

System.Web.DefaultHttpHandler.BeginProcessRequest(HttpContext context, AsyncCallback callback, Object state) +83

System.Web.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() +8677954

System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) +155

--------------------------------------------------------------------------------

Version Information: Microsoft .NET Framework Version:2.0.50727.3603; ASP.NET Version:2.0.50727.3082

The only way to get the WFE back online was to removed the registry entries and restart the services.

Researching the particular error yielded nothing except one Google cached paged that had the same problem on 9/29/09.

Do you have any ideas what might have caused the server to behave like that? (I'm not expecting you to miraculously know or be able to resolve the problem, but I'm hoping you might have seen a server do that before when applying these entries)

Thanks

re: Troubleshooting SPSite/SPWeb leaks in WSS v3 and MOSS 2007

Stefan_Gossner — Thu, 05 Nov 2009 08:21:50 GMT

Hi Cornelius,

I have never seen this.

But the error indicates that you entered the registry value with the incorrect type. Did you use DWORD or string?

It should be a DWORD.

Cheers,

Stefan

re: Troubleshooting SPSite/SPWeb leaks in WSS v3 and MOSS 2007

Subhasis — Fri, 13 Nov 2009 10:20:02 GMT

I have a strange error here.I have a content source. Whenever crawl runs,SQL connections goes too high. and only thing i got in the ULS logs is below

Potentially excessive number of SPRequest objects (12) currently unreleased on thread 9. Ensure that this object or its parent (such as an SPWeb or SPSite) is being properly disposed. Allocation Id for this object: {329BFC8D-6CB9-4C18-8048-72166ABE4E08} Stack trace of current allocation: at Microsoft.SharePoint.SPRequestManager.Add(SPRequest request, Boolean shareable) 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.SetMondoPr...

...ocHint(Int32 hint) at Microsoft.SharePoint.SPSite.OpenWeb(Guid gWebId, Int32 mondoHint) at Microsoft.SharePoint.SoapServer.CWebChange.CheckDB() at Microsoft.SharePoint.SoapServer.CWebChange..ctor(CChange parentChange, String strID, Boolean fDeleteEvent) at Microsoft.SharePoint.SoapServer.CSiteChange.GetWeb(String strID, Boolean fDeleteEvent) at Microsoft.SharePoint.SoapServer.SiteDataImpl.ProcessChanges(CChange change, SPChangeCollection spChangeCollection, SPChangeToken& spLastChangeToken, Int64& lTimeLeft) at Microsoft.SharePoint.SoapServer.SiteDataImpl.GetChanges(CChange change, SPChangeToken& spChangeToken_Start, SPChangeToken spChangeToken_End, Int64 lTimeout) at Microsoft.SharePoint.SoapServer.SiteDataImpl.GetChanges(ObjectType objectType, String contentDa...

1...tabaseId, String& startChangeId, String& endChangeId, Int32 Timeout, Boolean& moreChanges) at Microsoft.SharePoint.SoapServer.SiteData.GetChanges(ObjectType objectType, String contentDatabaseId, String& LastChangeId, String& CurrentChangeId, Int32 Timeout, Boolean& moreChanges) at System.RuntimeMethodHandle._InvokeMethodFast(Object target, Object[] arguments, SignatureStruct& sig, MethodAttributes methodAttributes, RuntimeTypeHandle typeOwner) at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture, Boolean skipVisibilityChecks) at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture) at System.Web.Services... Windows SharePoint Services General 0 Medium ....Protocols.LogicalMethodInfo.Invoke(Object target, Object[] values) at System.Web.Services.Protocols.WebServiceHandler.Invoke() at System.Web.Services.Protocols.WebServiceHandler.CoreProcessRequest() at System.Web.Services.Protocols.SyncSessionlessHandler.ProcessRequest(HttpContext context) at System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.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(HttpWo...

...rkerRequest wr) at System.Web.HttpRuntime.ProcessRequestNoDemand(HttpWorkerRequest wr)

Looks like the same error. But it happnes with crawl ? Any pointers. we have custom webparts. But RendertoIndexer property is already set to false. So webparts are not loaded during crawl. So what might be the reason of such high number of SP Requests ?

re: Troubleshooting SPSite/SPWeb leaks in WSS v3 and MOSS 2007

Stefan_Gossner — Fri, 13 Nov 2009 10:35:05 GMT

Hi Subhasis,

this is expected and by design. During crawl the same happens as if you would browse to the website. Except that crawl puts a pretty high load on the site. Every single instantiated SPWeb objects maintains its own SQL connection. As the crawler uses multiple threads to crawl the site it is like a load test against your site. All the navigation controls on the pages will get instantiated and will instantiate SPWeb objects.

So the only way to reduce the number of SQL connections would be to reduce the number of threads the crawler is using.

Cheers,

Stefan