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:
Event Type: Error
Date: date
Time: time
Event ID: 1505
Source: Userenv
User: Example\Username
Computer: ServerName
Description: Windows cannot load the user's profile but has logged you on with the
default profile for the system.
DETAIL - Insufficient system resources exist to complete the requested service.
Event Type: Error
Date: date
Time: time
Event ID: 1508
Source: Userenv
User: NT AUTHORITY\SYSTEM
Computer: ServerName
Description: Windows was unable to load the registry. This is often caused by
insufficient memory or insufficient security rights.
DETAIL - Insufficient system resources exist to complete the requested service. for
C:\Documents and Settings\Username\ntuser.dat
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:
NonPagedPool Max: 65279 ( 261116 Kb)
PagedPool Usage: 0 ( 0 Kb)
PagedPool Maximum: 90112 ( 360448 Kb)
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:
NonPagedPool Max: 65279 ( 261116 Kb)
PagedPool Usage: 0 ( 0 Kb)
PagedPool Maximum: 12288 ( 49152 Kb)
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:
"ClearPageFileAtShutdown"=dword:00000000
"DisablePagingExecutive"=dword:00000000
"LargeSystemCache"=dword:00000001
"NonPagedPoolQuota"=dword:00000000
"NonPagedPoolSize"=dword:00000000
"PagedPoolQuota"=dword:00000000
"PagedPoolSize"=dword:00000000
And here’s what the same section of the registry looked like after our SP2 upgrade:
"ClearPageFileAtShutdown"=dword:00000000
"DisablePagingExecutive"=dword:00000000
"LargeSystemCache"=dword:00000001
"NonPagedPoolQuota"=dword:00000000
"NonPagedPoolSize"=dword:00000000
"PagedPoolQuota"=dword:00000000
"PagedPoolSize"=dword:00000000
However, when we looked closer, the customer’s registry had one minor difference on both their SP1 and SP2 machines:
"ClearPageFileAtShutdown"=dword:00000000
"DisablePagingExecutive"=dword:00000000
"LargeSystemCache"=dword:00000001
"NonPagedPoolQuota"=dword:00000000
"NonPagedPoolSize"=dword:00000000
"PagedPoolQuota"=dword:00000000
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 : |
|
|
|
|
|
|
|
|