How to debug Potentially excessive number of SPRequest objects error message

You may have seen this error message in your SharePoint log file.

“Potentially excessive number of SPRequest objects (10) currently unreleased on thread 5. Ensure that this object or its parent (such as an SPWeb or SPSite) is being properly disposed. This object will not be automatically disposed.”

Now this means that you have some (custom) code in your SharePoint installation that doesn’t dispose its memory allocation correctly. You have code that leak memory.

The error message in the log doesn’t say much on where this memory leak happens, which makes it a little bit difficult to trouble shoot. However, there is a way to tell SharePoint to tell you more on where this happens by also writing out the stack trace in the log file.

Open RegEdit and browse to the

HKEY_LOCAL_MACHINESOFTWAREMicrosoftShared ToolsWeb Server ExtensionsHeapSettings

key. Edit the SPRequestStackTrace DWORD Entry and set it to 1.

You will now geta full stack trace whenever this error message appears, which makes it so much easier to trouble shoot.

The system cannot boot. The file is possibly corrupt. The file header checksum does not match the computed checksum

Well, isn’t that special. This error was greeting my wife when she booted up Windows Vista on her Sony Vaio laptop the other day. This error message comes up directly after BIOS POST, within milliseconds. No chance to enter safe mode, no chance to press F10 for system recovery.

Booting from the Windows Vista DVD, I can enter the command prompt and run CHKDSK with no errors. Even CHKDSK /R doesn’t find anything out of the ordinary. The Repair option doesn’t find anything. Booting from the DVD, pressing F9 and selecting the memory diagnostics, it ran for 5 passes without finding anything. Just great…

As it turns out, one of the memory modules was the culprit. The laptop has one 2GB SO-DIMM module and one 1GB. Removing the 1GB module, the laptop boots up happily as if nothing has happened. Hmm…. wondering why the memory diagnostics didn’t find this.

DEBUG: Error 2769: Custom Action install did not close 1 MSIHANDLEs.

You may have seen this strange error when trying to install your MSI when you have developed a managed custom action DLL in Visual Studio 2005 / 2008?

If you execute the MSI with detailed logging, like this:
MSIEXEC /i "<YOURMSI>.msi" /L*v "InstallLog.txt"

You end up with an error message that is similar to this in the log file:
DEBUG: Error 2769:  Custom Action _E3EBB591_EA21_438E_AEB9_4442A5A8C483.install did not close 1 MSIHANDLEs.
The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2769. The arguments are: _E3EBB591_EA21_438E_AEB9_4442A5A8C483.install, 1,
Action ended 16:09:12: InstallExecute. Return value 3.

The thing is that you probably have set the Custom Action Data as follows:
/myParameter=”[TARGETDIR]”
The solution to the problem is to add a trailing backslash:
/myParameter=”[TARGETDIR]”

This is actually described in this MSDN article:
http://msdn.microsoft.com/en-us/library/2w2fhwzz.aspx