Zach Rosenfield

Today I’m posting about a rather dense technology issue—so please bear with me!  Those of you who read my blog know that I am a huge fan of PowerShell and on occasion talk about various ways to use PowerShell for managing SharePoint deployments.  Additionally I’ve seen projects and people around the web discuss it.  However, it wasn’t until learning about some of the most in-depth inner-workings of PowerShell did an important realization come about.  In short: There was a potential for PowerShell users to constantly leak memory without knowing it!  While this is not a common situation and it would be hard to do so in such large volume to really cause real harm—it is possible, and thus, everyone should know about it.

So first, what’s the issue?  Well, first of all it is important to know that SharePoint does an amazing amount of work in relation to the SPSite and SPWeb objects to make sure that they are running for optimal performance—which in terms of native code means working to improve memory allocation.  Thus there is some special code in these objects, but this also comes with some unique requirements—one that should not be new to SharePoint developers: the need to Dispose of these objects.  So what’s changed you ask?  Well—did you know that SPSite and SPWeb objects should never be used across threads?

Usually this is not important.  Multiple threads can safely access the same SPSite or SPWeb simultaneously, so there’s no reason for a developer to open a reference to one of these objects and pass it to another thread.  However, if you did try this, the unmanaged Heap (which is thread specific) will be “lost” and a new Heap will be allocated in the new thread.  So if you did this endlessly your machine will eventually run out of memory (though this memory is freed if you close the PowerShell process).

So on to the specific PowerShell concern.  I only recently learned that every time a new ‘pipe’ in PowerShell is executed (essentially every time you press ‘enter’), that command is run in a unique thread.  So what does this mean for SharePoint?  Well, it means that saving an SPSite or an SPWeb to a variable will cause memory leaks—no matter what you do. 

As an example, let’s take the following syntax:

PS>  $S = New-Object Microsoft.SharePoint.SPSite(“http://sharepoint”)

PS>  $S.Title

My SharePoint Site

PS> $S.Dispose()

Looks fine, right?  Unfortunately, since each “PS>” line is executed in a new thread, the final $S.Dispose() does not dispose of the unmanaged heap (before you go try to prove me wrong, realize that the managed code is properly disposed—so you will recover some memory).

Well, as it turns out this is a simple problem to mitigate.  Since each PowerShell ‘sentence’ is run in a single thread, any loaded function or script is run as a single thread!  So while the syntax above was not healthy, the exact same lines of code run in script work fine.  Or even this is line works great:

PS>  $S = New-Object Microsoft.SharePoint.SPSite(“http://sharepoint”);  $S.Title; $S.Dispose()

Keep your eye out on this blog for other potential workarounds in the future. 

With that in mind, happy scripting!

Zach Rosenfield
Program Manager, Microsoft Office SharePoint Server