Happy Friday AskPerf readers! Today’s post is a short one, in which we’re going to quickly discuss an odd issue that we have seen a few times recently following the installation of Windows Server 2003 Service Pack 2. As the title indicates, this issue revolves around the amount of maximum PagedPool memory available on the server following the SP2 install and the subsequent reboot. In the cases we’ve seen, the systems have been generating the infamous Event ID 333 that we discussed way back in 2007. In addition we’ve also seen the following events reported:
As you can see, the error messages clearly point to some sort of resource issue. However, since no Event 2020 (which indicates a depletion of PagedPool memory) has been generated, nothing immediately indicates that we have a PagedPool issue. As part of our troubleshooting process for memory management issues, we normally request a full dump from the affected server to dig into the resource issues a little deeper. One of the first things we check is the virtual memory information. We can easily do this by running the !vm command in the debugger once we have the dump file loaded. Below is an excerpt from what this information looked like on a Windows Server 2003 SP1 machine for the NonPaged and PagedPool:
As you can see, the values for the maximum available NonPaged (around 256MB) and PagedPool (just over 350MB) look healthy. Now take a look at the output from the server following the Service Pack 2 install:
As you can see, the PagedPool Maximum has dropped all the way down to 48MB. That explains why we’re running out of memory so quickly – there simply isn’t enough PagedPool available to load the registry hives. Armed with this information, it’s time to take a look at the MemoryManagement registry key on a the system to see if there is anything odd going on. Remember that the MemoryManagement information is stored in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management . When we examined this key, nothing initially appeared out of place. The key appeared to be unmodified. Below is a snippet from the registry of a standard SP1 install that we built internally to try to reproduce the customer’s problem:
And here’s what the same section of the registry looked like after our SP2 upgrade:
However, when we looked closer, the customer’s registry had one minor difference on both their SP1 and SP2 machines:
Notice that the value for PagedPoolSize is not present. What this indicates is that at some point, the customer’s registry was modified. That resulted in the value for the PagedPool being set to the default minimum . If the value is present, the default value is 0x000000 (System managed). In some instances we may recommend manually changing the value to 0xFFFFFFFF (Maximum value). In this specific instance, we knew that we had something not quite standard in place. We added the PagedPool value to an SP1 machine that did not have the value present and set the value to 0x00000000. After the SP2 upgrade, the registry key was still present, and the PagedPool maximum memory was correctly set to just over 350MB.
As you can see, this was definitely an interesting case. If you run into an odd issue with insufficient resources being reported following your SP2 upgrade, check and see if the registry is missing the PagedPoolSize value – from what we’ve described above, the fix is relatively straightforward and should get your systems back up and running with minimal effort. Until next time …
|Share this post :||
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.