I posted on the msdn forums here and an administrator advised me to ask my question here. I've been trying to make a library that uses the System.Diagnostics.PerformanceCounters to monitor perfmon on a variety of machines in C#. While the system seems to run fine, I've noticed after three weeks or so of polling that I just started receiving the error: "Not enough server storage is available to process this command" on Windows Server 2003 machines which the stack trace identifies as being from: at System.Diagnostics.PerformanceMonitor.GetData(String item) at System.Diagnostics.PerformanceCounterLib.GetPerformanceData(String item) at System.Diagnostics.PerformanceCounterLib.get_CategoryTable() at System.Diagnostics.PerformanceCounterLib.GetCategories() at System.Diagnostics.PerformanceCounterLib.GetCategories(String machineName) at System.Diagnostics.PerformanceCounterCategory.GetCategories(String machineName) The same error occurs when I try hitting System.Diagnostics.Process.GetProcesses(). I can "fix" the issue by restarting the Remote Registry, but it's not really a long term solution since I won't be able to do this going forward on all of the machines. I've noticed that on the machines that fail, around the time the failure occurs, I start to see warnings in the event viewer like: The configuration information of the performance library "C:\WINDOWS\system32\aspperf.dll" for the "ASP" service does not match the trusted performance library information stored in the registry. The functions in this library will not be treated as trusted. Followed by warnings like: Windows cannot load extensible counter DLL CcmFramework, the first DWORD in data section is the Windows error code. Reading online, the best help I can find for these issues is this reference: http://support.microsoft.com/kb/106167 It mentions the idea that the IRPStackSize is not a large enough value and recommends the fix of changing this value. However, I'm not really keen on this idea because again, it seems if the boxes function fine for a few weeks and then don't return to functioning okay until I restart remote registry, that something is just not interacting well and that the value itself isn't the problem. Checking the registry on one of my servers, I don't see a variable for IRPStackSize in the described location. What happens when I increase that value that will make the work on the machine magically work? Or are there other solutions that people can recommend?

Hi, check this http://support.microsoft.com/kb/177078/en-us HTHEdoardo Benussi - Microsoft MVP Management Infrastructure - Systems Administration https://mvp.support.microsoft.com/Profile/Benussi Windows Server Italian Forum Moderator edo[at]mvps[dot]org

Hey Edoardo, That's basically the same link as I mentioned in my post. As I stated there, I'm interested in getting a little more than "make this value bigger, magic happens!" especially when that change requires restarting machines that are used for other purposes. If this value is the cause, why does querying machines work for a while and then stop? Is it affecting something else that eventually pushes a machine to levels that exceed the counters? If that's the case, what are they and maybe there's a way to reduce them instead. Looking up that key, it's described as: The IRPStackSize parameter specifies the number of stack locations in I/O request packets (IRPs) that are used by Windows 2000 Server, by Windows Server 2003, and by Windows XP. You may have to increase this number for certain transports, for media access control (MAC) drivers, or for file system drivers. Each stack uses 36 bytes of memory for each receive buffer. So is there a way to release stack locations that are being used once they're done? It sounds like the issue is that the number of available packets drops after a while, so there's no longer any left for incoming queries. Can these be freed in some way?

Hey Edoardo, That's basically the same link as I mentioned in my post. As I stated there, I'm interested in getting a little more than "make this value bigger, magic happens!" especially when that change requires restarting machines that are used for other purposes. why don't you try ? if it fails then we re-analyze the problem.Edoardo Benussi - Microsoft MVP Management Infrastructure - Systems Administration https://mvp.support.microsoft.com/Profile/Benussi Windows Server Italian Forum Moderator edo[at]mvps[dot]org

I'll see if I have a non-production box that I might be able to restart in order to test the proposed solution. The problem is many of these boxes run vital processes and can't simply be restarted on a whim. The reason I asked if there's other solutions is that restarting the Remote Registry service "fixes" the problem until it appears again two weeks later. As such, I'm curious if it's just an issue of things not getting resolved properly on the system when it's exposed to a lot of remote access. At the very least, can you provide further detail on what exactly IRPStackSize is/does and why it would break over time?

take a look at this link http://www.webopedia.com/TERM/I/IRPStackSize.htmlEdoardo Benussi - Microsoft MVP Management Infrastructure - Systems Administration https://mvp.support.microsoft.com/Profile/Benussi Windows Server Italian Forum Moderator edo[at]mvps[dot]org

Thanks, I remember reading that a few weeks ago, it must have slipped my mind. Out of curiosity, when the I/O is finished, Windows should release the stack location it's using right? So increasing that number would increase the number of active receive buffers? If it starts saying it doesn't have enough server storage after a few weeks, and increasing that value will fix it, does that mean that some things are holding onto their allocated buffers indefinitely/longer than they're supposed to be?

exactlyEdoardo Benussi - Microsoft MVP Management Infrastructure - Systems Administration https://mvp.support.microsoft.com/Profile/Benussi Windows Server Italian Forum Moderator edo[at]mvps[dot]org

I'd like to run some tests to see if I can diagnose this better. Is there a way to monitor how many of those stacks are being used at any moment?

read here http://social.msdn.microsoft.com/forums/en/vsdebug/thread/974655bc-af01-4da5-9c20-37a013caf973 hthEdoardo Benussi - Microsoft MVP Management Infrastructure - Systems Administration https://mvp.support.microsoft.com/Profile/Benussi Windows Server Italian Forum Moderator edo[at]mvps[dot]org