MEMORY MANAGEMENT (GENERAL: PRE-WINDOWS VISTA)
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. Using 4GB RAM Tuning (/3GB switch) or USERVA will change this amount.
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 blog post on the 32-bit address space , our 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:
- Are you getting errors stating you are out of a virtual memory or another memory resource?
- Is an application crashing or hanging when using a large amount of memory?
- 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.
You can create the log parameters manually
, or by using the
Performance Monitor Wizard
. 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.
- If your system has a very large amount of RAM or limited disk drive space on the root drive, you may need to use MAXMEM to constrain the memory to a more reasonable size for dumping the system (i.e. constrain a 16GB system to 4GB). If this is not possible, a Kernel Only dump may suffice depending on the circumstances.
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:
- Microsoft® Windows® Internals, Fourth Edition: Microsoft Windows Server™ 2003, Windows XP, and...
- AskPerf Blog: An Overview of Troubleshooting Memory Issues
- AskPerf Blog: Memory Management - x86 Virtual Address Space
- AskPerf Blog: An Overview of Troubleshooting Memory Issues
- AskPerf Blog: An Overview of Troubleshooting Memory Issues - Part Two
- AskPerf Blog: Memory Management - Demystifying /3GB
- Microsoft KB Article 177415: How to use Memory Pool Monitor (Poolmon.exe) to troubleshoot kern...
- Microsoft KB Article 294418: Comparison of 32-bit and 64-bit memory architecture for 64-bit ed...