PRF: Memory Management (General Issues – Windows Vista +)


MEMORY MANAGEMENT (GENERAL: WINDOWS VISTA AND LATER)



Description:  Memory management is the term used to describe how Windows handles the manipulation and allocation of both virtual and physical memory resources.


Physical memory is considered the total of physical RAM and the pagefile or pagefiles configured on the system. A pagefile is a file on a system hard disk that is configured and treated as though it were physical RAM. The pagefile acts like RAM, and applications see it as RAM, but it will typically be slower than physical RAM due to disk throughput and latency.


Virtual memory is the term used to describe the amount of memory space that Windows can use for applications or system use. A 32-bit operating system can address up to 32-bits of memory, which works out to 4 gigabytes of virtual memory (4,294,967,296 bytes). This memory space is by default divided into a 2 gigabyte piece for the kernel and a 2 gigabyte piece for each individual process running on the machine. Use of the IncreaseUserVa setting within Bcdedit may change this amount. The primary difference between Windows Vista or Windows Server 2008 and previous Windows versions is that many of the primary kernel resources are now dynamic instead of static. This allows much more headroom for load and makes most memory issues much less likely.


The amount of virtual memory that is actually being used will typically be much smaller than the amount that is technically available; this is why virtual memory can be larger than physical memory. The concept of virtual memory is unrelated to the amount of physical memory installed; however the amount of physical memory can have an effect on certain memory structures. More information on virtual memory concepts can be found in our post on Windows Server 2008 Kernel Addressing, our first post on Troubleshooting Memory Issues and our second post on Troubleshooting Memory Issues. A 64-bit operating system has a much higher limit on virtual memory structures, with more information available here.


 



Scoping the Issue:  The questions to ask when suspecting a problem with memory management may include:



  1. Are you getting errors stating you are out of a virtual memory or another memory resource?

  2. Is an application crashing or hanging when using a large amount of memory?

  3. Are event log entries being logged that indicate some sort of memory issue?

Both 2019 and 2020 event log errors with a source of SRV are relatively common, and indicate a depletion of non-paged or paged pool memory respectively.


 


Data Gathering:  In all instances, collecting either MPS Reports with the General, Internet and Networking, Business Networks and Server Components diagnostics, or a Performance-oriented MSDT manifest must be done.  Additional data required may include the following:



  • Performance Monitor logs that include the timeframe when the memory issue occurred.  The length of time it takes the server to go from a normal state, to the problem state will determine the Perfmon capture interval. Please use the table below to set the capture interval.  To capture a Performance Monitor log on Windows Vista and later operating systems, follow the steps below:


  1. Click Start, type Perfmon in the Start Search box and then click Perfmon in the programs list.  If you are prompted for a password or for UAC consent, follow the prompts

  2. Expand Data Collector Sets, then click User-Defined

  3. Right-click and choose New – Data Collector Set and follow the wizard.

  4. Required counters include:



  • Cache / All Counters / All Instances

  • Memory / All Counters / All Instances

  • Process / All Counters / All Instances

  • Processor / All Counters / All Instances

  • Physical Disk / All Counters / All Instances















If the average time to issue is: The capture interval should be:
Weekly 14 minutes
Daily 120 seconds
Hourly 5 seconds



  • Pool Monitor (PoolMon) logs that include the timeframe when the memory leak is occurring (if you are experiencing non-paged or paged pool depletion).  As with Perfmon, the poolmon capture interval is set based on the frequency of the symptoms.  The table below provides some guidelines for setting the interval.  We strongly recommend capturing simultaneous Perfmon and Poolmon data simultaneously so we can correlate the events.














If the average time to issue is: The capture interval should be:
Weekly 1 hours
Daily 15 minutes
Hourly 60 seconds



  • It may also be necessary to capture a complete memory dump of the server while it is in the problem state.  In most cases we will capture what is known as a Ctrl-ScrollLock Memory Dump. However, if your system has a “Lights out Management” system (iLO), you will most likely want to capture what is known as an NMI Dump. In either case it is important to ensure that you have a pagefile on the root drive that is equal to the amount of RAM on the system plus about 100MB. 

 


Troubleshooting / Resolution:  After you have gathered this data, review the following:



  • MPS Reports

    • Look for any Event ID 2019 or 2020 events

    • Outdated components, such as device drivers, filter drivers

  • Performance Monitor Logs

    • Look for evidence of any processes whose memory usage is trending upwards.  This may display as either an upward slanging line, or a stair-stepping increase over time

 


Additional Resources: