I have a whole bunch of Windows XP sp2 systems that give me an error when I attempt to connect to their c$ or admin$ shares: “Not enough server storage is available to process this command.”

The remote system’s event log records: Event ID : 2011 Source : Srv Description: The Server’s configuration parameter “IRPStackSize” is too small for the server to use a local device. Please increase the value of this parameter.

I checked a couple of Microsoft Knowledgebase articles and did a bunch of googling searching the Internet. It seems that a lot of people have latched onto as the only cause and concluded if you have the error message “Not enough server storage is available to process this command” than it must be Symantec’s fault. As I searched, I found person after person with this error message being told they needed to uninstall symantec. The person with the issue responded they had another antivirus product, they never had Symantec installed and they still had the issue. The Symantec blame had specifically to do with NAV 7.6 and 8 which hardcoded the IRP stack size to 8, roughly half of its default value in Windows XP. That doesn’t have a lot to do with the issues i’m having. I dont have that registry value at all. is a more helpful article. It describes what the IRP Stack is and why you might have a problem with it. The problem is, you’re left guessing at what “an appropriate value for my network is”. I also wondered if I could configure this setting globally instead of having to manually configure it on systems exhibiting issues.

I spoke with a Microsoft contact and decided that we were having the problems because of the high number of file filtering applications (AV, AS, encryption, backup, etc) and concluded it is safe to adjust this globally. Currently we’re using SMS to change the IRPStackSize to 18 (decimal).

This error is really a big problem. Its not very noticeable by itself. But on the systems with the error, SMS seemed to not be working. This effects software update distribution. It also hurts the vulnerability scanners ability to check file versions. Hopefully we are on are way to fixing this problem on a permanent basis.


  1. We are experiencing this issue with Sophos Antivirus SBE running on Windows XP as well. Sophos has mentioned it in the release notes since 2006, but here we are in 2008 and still having issues. I recieve this message on my machines even with the IRPStackSize set to 18. My question is if I should go even higher. Has anyone tried increasing this value until the error goes away? What are the side effects?

  2. Microsoft has recommended increasing in increments of 3, so I would try 21 next. Hopefully that will work for you. I have only had to go to 21 on one computer, and I haven’t yet validated if it fixed that system.
    I actually don’t know of any side effects. I think it having the larger stack size reserves a very small amount of resources, but I dont think that is an issue on today’s computers.

  3. Hello,
    your article was very helpful.
    I have three computers, of which the latest is a quad amd 9850 on which I cloned succesfully the windows xp prof OS that resided on a uniprocessor machine. I used ntbackup. Only drawback apparantly: I have problems getting all drives on the pc to be accessed on my home network. I use the same sharing and security settings on all drives, yet only drives c: and g: can get accessed on the network. Not so for d:, e:, and f: …and I do not use symantec (I have NOD32), yet the same “not enough memory error message appears, and the event log on the new pc shows all red with 2011 event id’s.
    I had to add the registry IRP entry, edited it to 15, but no improvement. As of this writing it is being set to 18 and I have still to reboot to viewx the results. I hope to get his solved…

  4. We have seen this issue too – caused by the installation of a Symantec DLP solution.
    Setting the IRPStackSize to 18 fixed it for us.
    Note that you do not need to reboot the machine after the change – just stop & restart the server service.

Comments are closed.