SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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.

share|improve this question
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... – Amadeo Gallardo Mar 7 '12 at 1:42
@Nicholas - Did you get a fix for this? I've got the same problem… – Paul Rowland Dec 18 '13 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. – W0ut Sep 25 '14 at 14:22

Best practices when doing SharePoint development. To prevent memory leaks remember to dispose of your objects.

This tool may help as well

share|improve this answer
how can you use SPDisposeCheck against code written by Microsoft? – Paul Rowland Dec 18 '13 at 23:14
Easily. By disassembling the code. – Paul Strupeikis Feb 22 at 16:59
SPDisposeCheck . – Red Jun 17 at 14:36

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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