I've been trying to locate some memory leaks we've noticed in our ULS (EventID: nask, An SPRequest object was not disposed ... etc).

On my dev environment, and at least 2 other cleaner installs, the taxonomy receivers seem to be the source of these entries.

Steps to replicate without code:

  1. Create a custom list
  2. Open uls and filter for 'nask' events.
  3. Add an item and verify no entry in ULS
  4. Edit the item and verify no entry in uls.
  5. Add an MMS column to the list
  6. Add an item and verify an SPRequest is reported as not disposed
  7. Edit the item and verify an SPRequest is reported as not dsiposed.

To me, this looks like it's caused by SPItemEventProperties.List being called from a synchronous handler. To test, I created a new list and added ItemAdding, ItemUpdating, ItemAdded and ItemAdding handlers containing;

public override void ItemX(SPItemEventProperties properties)
    SPList list = properties.List

On edit and update, one 'nask' event is logged. If i then change the asynchronous events to synchronous via powershell, I suddenly get 2 'nask' events for adds\edits to the list.

After checking reflector I'm guessing that properties.List is actually null for synchronous handlers, leading to a call to site.OpenWeb(), which is causes the message in ULS.

Is anyone else able to replicate this or am I missing something blindingly obvious?

EDIT: So after a little sleep I attached the debugger to properties.list on one of the synchoronous handlers. At this point the list is not null, although the line is definitely the culprit.

  • I too do recall having the debugger throw exceptions while on debug mode, and behave erratically when working with Taxonomy. Things like events firing in weird order, lines of code skipped, etc... Commented Mar 7, 2012 at 1:42
  • @Nicholas - Did you get a fix for this? I've got the same problem sharepoint.stackexchange.com/questions/84726/… Commented Dec 18, 2013 at 23:12
  • FYI. Make sure you install all the latest SP updates. There were some memory leak issues in the initial SP2013 release, although I believe these were mainly search related. Maybe the updates resolve your issue as well.
    – Wout
    Commented Sep 25, 2014 at 14:22

1 Answer 1


Best practices http://msdn.microsoft.com/en-us/library/aa973248(v=office.12).aspx when doing SharePoint development. To prevent memory leaks remember to dispose of your objects.

This tool may help as well http://archive.msdn.microsoft.com/SPDisposeCheck

  • 4
    how can you use SPDisposeCheck against code written by Microsoft? Commented Dec 18, 2013 at 23:14
  • Easily. By disassembling the code. Commented Feb 22, 2016 at 16:59
  • SPDisposeCheck .
    – Red
    Commented Jun 17, 2016 at 14:36

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.