Mark Russinovich’s technical blog covering topics such as Windows troubleshooting, technologies and security.
This is the first blog post in a series I'll write over the coming months called Pushing the Limits of Windows that describes how Windows and applications use a particular resource, the licensing and implementation-derived limits of the resource, how to measure the resource’s usage, and how to diagnose leaks. To be able to manage your Windows systems effectively you need to understand how Windows manages physical resources, such as CPUs and memory, as well as logical resources, such as virtual memory, handles, and window manager objects. Knowing the limits of those resources and how to track their usage enables you to attribute resource usage to the applications that consume them, effectively size a system for a particular workload, and identify applications that leak resources.
Here’s the index of the entire Pushing the Limits series. While they can stand on their own, they assume that you read them in order.
Pushing the Limits of Windows: Physical Memory Pushing the Limits of Windows: Virtual Memory Pushing the Limits of Windows: Paged and Nonpaged Pool Pushing the Limits of Windows: Processes and Threads Pushing the Limits of Windows: Handles Pushing the Limits of Windows: USER and GDI Objects – Part 1 Pushing the Limits of Windows: USER and GDI Objects – Part 2
Pushing the Limits of Windows: Physical Memory
Pushing the Limits of Windows: Virtual Memory
Pushing the Limits of Windows: Paged and Nonpaged Pool
Pushing the Limits of Windows: Processes and Threads
Pushing the Limits of Windows: Handles
Pushing the Limits of Windows: USER and GDI Objects – Part 1
Pushing the Limits of Windows: USER and GDI Objects – Part 2
One of the most fundamental resources on a computer is physical memory. Windows' memory manager is responsible with populating memory with the code and data of active processes, device drivers, and the operating system itself. Because most systems access more code and data than can fit in physical memory as they run, physical memory is in essence a window into the code and data used over time. The amount of memory can therefore affect performance, because when data or code a process or the operating system needs is not present, the memory manager must bring it in from disk.
Besides affecting performance, the amount of physical memory impacts other resource limits. For example, the amount of non-paged pool, operating system buffers backed by physical memory, is obviously constrained by physical memory. Physical memory also contributes to the system virtual memory limit, which is the sum of roughly the size of physical memory plus the maximum configured size of any paging files. Physical memory also can indirectly limit the maximum number of processes, which I'll talk about in a future post on process and thread limits.
Windows support for physical memory is dictated by hardware limitations, licensing, operating system data structures, and driver compatibility. The Memory Limits for Windows Releases page in MSDN documents the limits for different Windows versions, and within a version, by SKU.
You can see physical memory support licensing differentiation across the server SKUs for all versions of Windows. For example, the 32-bit version of Windows Server 2008 Standard supports only 4GB, while the 32-bit Windows Server 2008 Datacenter supports 64GB. Likewise, the 64-bit Windows Server 2008 Standard supports 32GB and the 64-bit Windows Server 2008 Datacenter can handle a whopping 2TB. There aren't many 2TB systems out there, but the Windows Server Performance Team knows of a couple, including one they had in their lab at one point. Here's a screenshot of Task Manager running on that system:
The maximum 32-bit limit of 128GB, supported by Windows Server 2003 Datacenter Edition, comes from the fact that structures the Memory Manager uses to track physical memory would consume too much of the system's virtual address space on larger systems. The Memory Manager keeps track of each page of memory in an array called the PFN database and, for performance, it maps the entire PFN database into virtual memory. Because it represents each page of memory with a 28-byte data structure, the PFN database on a 128GB system requires about 980MB. 32-bit Windows has a 4GB virtual address space defined by hardware that it splits by default between the currently executing user-mode process (e.g. Notepad) and the system. 980MB therefore consumes almost half the available 2GB of system virtual address space, leaving only 1GB for mapping the kernel, device drivers, system cache and other system data structures, making that a reasonable cut off:
That's also why the memory limits table lists lower limits for the same SKU's when booted with 4GB tuning (called 4GT and enabled with the Boot.ini's /3GB or /USERVA, and Bcdedit's /Set IncreaseUserVa boot options), because 4GT moves the split to give 3GB to user mode and leave only 1GB for the system. For improved performance, Windows Server 2008 reserves more for system address space by lowering its maximum 32-bit physical memory support to 64GB.
The Memory Manager could accommodate more memory by mapping pieces of the PFN database into the system address as needed, but that would add complexity and possibly reduce performance with the added overhead of map and unmap operations. It's only recently that systems have become large enough for that to be considered, but because the system address space is not a constraint for mapping the entire PFN database on 64-bit Windows, support for more memory is left to 64-bit Windows.
The maximum 2TB limit of 64-bit Windows Server 2008 Datacenter doesn't come from any implementation or hardware limitation, but Microsoft will only support configurations they can test. As of the release of Windows Server 2008, the largest system available anywhere was 2TB and so Windows caps its use of physical memory there.
64-bit Windows client SKUs support different amounts of memory as a SKU-differentiating feature, with the low end being 512MB for Windows XP Starter to 128GB for Vista Ultimate and 192GB for Windows 7 Ultimate. All 32-bit Windows client SKUs, however, including Windows Vista, Windows XP and Windows 2000 Professional, support a maximum of 4GB of physical memory. 4GB is the highest physical address accessible with the standard x86 memory management mode. Originally, there was no need to even consider support for more than 4GB on clients because that amount of memory was rare, even on servers.
However, by the time Windows XP SP2 was under development, client systems with more than 4GB were foreseeable, so the Windows team started broadly testing Windows XP on systems with more than 4GB of memory. Windows XP SP2 also enabled Physical Address Extensions (PAE) support by default on hardware that implements no-execute memory because its required for Data Execution Prevention (DEP), but that also enables support for more than 4GB of memory.
What they found was that many of the systems would crash, hang, or become unbootable because some device drivers, commonly those for video and audio devices that are found typically on clients but not servers, were not programmed to expect physical addresses larger than 4GB. As a result, the drivers truncated such addresses, resulting in memory corruptions and corruption side effects. Server systems commonly have more generic devices and with simpler and more stable drivers, and therefore hadn't generally surfaced these problems. The problematic client driver ecosystem led to the decision for client SKUs to ignore physical memory that resides above 4GB, even though they can theoretically address it.
While 4GB is the licensed limit for 32-bit client SKUs, the effective limit is actually lower and dependent on the system's chipset and connected devices. The reason is that the physical address map includes not only RAM, but device memory as well, and x86 and x64 systems map all device memory below the 4GB address boundary to remain compatible with 32-bit operating systems that don't know how to handle addresses larger than 4GB. If a system has 4GB RAM and devices, like video, audio and network adapters, that implement windows into their device memory that sum to 500MB, 500MB of the 4GB of RAM will reside above the 4GB address boundary, as seen below:
The result is that, if you have a system with 3GB or more of memory and you are running a 32-bit Windows client, you may not be getting the benefit of all of the RAM. On Windows 2000, Windows XP and Windows Vista RTM, you can see how much RAM Windows has accessible to it in the System Properties dialog, Task Manager's Performance page, and, on Windows XP and Windows Vista (including SP1), in the Msinfo32 and Winver utilities. On Window Vista SP1, some of these locations changed to show installed RAM, rather than available RAM, as documented in this Knowledge Base article.
On my 4GB laptop, when booted with 32-bit Vista, the amount of physical memory available is 3.5GB, as seen in the Msinfo32 utility:
You can see physical memory layout with the Meminfo tool by Alex Ionescu (who's contributing to the 5th Edition of the Windows Internals that I'm coauthoring with David Solomon). Here's the output of Meminfo when I run it on that system with the -r switch to dump physical memory ranges:
Note the gap in the memory address range from page 9F0000 to page 100000, and another gap from DFE6D000 to FFFFFFFF (4GB). However, when I boot that system with 64-bit Vista, all 4GB show up as available and you can see how Windows uses the remaining 500MB of RAM that are above the 4GB boundary:
What's occupying the holes below 4GB? The Device Manager can answer that question. To check, launch "devmgmt.msc", select Resources by Connection in the View Menu, and expand the Memory node. On my laptop, the primary consumer of mapped device memory is, unsurprisingly, the video card, which consumes 256MB in the range E0000000-EFFFFFFF:
Other miscellaneous devices account for most of the rest, and the PCI bus reserves additional ranges for devices as part of the conservative estimation the firmware uses during boot.
The consumption of memory addresses below 4GB can be drastic on high-end gaming systems with large video cards. For example, I purchased one from a boutique gaming rig company that came with 4GB of RAM and two 1GB video cards. I hadn't specified the OS version and assumed that they'd put 64-bit Vista on it, but it came with the 32-bit version and as a result only 2.2GB of the memory was accessible by Windows. You can see a giant memory hole from 8FEF0000 to FFFFFFFF in this Meminfo output from the system after I installed 64-bit Windows:
Device Manager reveals that 512MB of the over 2GB hole is for the video cards (256MB each), and it looks like the firmware has reserved more for either dynamic mappings or because it was conservative in its estimate:
Even systems with as little as 2GB can be prevented from having all their memory usable under 32-bit Windows because of chipsets that aggressively reserve memory regions for devices. Our shared family computer, which we purchased only a few months ago from a major OEM, reports that only 1.97GB of the 2GB installed is available:
The physical address range from 7E700000 to FFFFFFFF is reserved by the PCI bus and devices, which leaves a theoretical maximum of 7E700000 bytes (1.976GB) of physical address space, but even some of that is reserved for device memory, which explains why Windows reports 1.97GB.
Because device vendors now have to submit both 32-bit and 64-bit drivers to Microsoft's Windows Hardware Quality Laboratories (WHQL) to obtain a driver signing certificate, the majority of device drivers today can probably handle physical addresses above the 4GB line. However, 32-bit Windows will continue to ignore memory above it because there is still some difficult to measure risk, and OEMs are (or at least should be) moving to 64-bit Windows where it's not an issue.
The bottom line is that you can fully utilize your system's memory (up the SKU's limit) with 64-bit Windows, regardless of the amount, and if you are purchasing a high end gaming system you should definitely ask the OEM to put 64-bit Windows on it at the factory.
Regardless of how much memory your system has, the question is, is it enough? Unfortunately, there's no hard and fast rule that allows you to know with certainty. There is a general guideline you can use that's based on monitoring the system's "available" memory over time, especially when you're running memory-intensive workloads. Windows defines available memory as physical memory that's not assigned to a process, the kernel, or device drivers. As its name implies, available memory is available for assignment to a process or the system if required. The Memory Manager of course tries to make the most of that memory by using it as a file cache (the standby list), as well as for zeroed memory (the zero page list), and Vista's Superfetch feature prefetches data and code into the standby list and prioritizes it to favor data and code likely to be used in the near future.
If available memory becomes scarce, that means that processes or the system are actively using physical memory, and if it remains close to zero over extended periods of time, you can probably benefit by adding more memory. There are a number of ways to track available memory. On Windows Vista, you can indirectly track available memory by watching the Physical Memory Usage History in Task Manager, looking for it to remain close to 100% over time. Here's a screenshot of Task Manager on my 8GB desktop system (hmm, I think I might have too much memory!):
On all versions of Windows you can graph available memory using the Performance Monitor by adding the Available Bytes counter in the Memory performance counter group:
You can see the instantaneous value in Process Explorer's System Information dialog, or, on versions of Windows prior to Vista, on Task Manager's Performance page.
Out of CPU, memory and disk, memory is typically the most important for overall system performance. The more, the better. 64-bit Windows is the way to go to be sure that you're taking advantage of all of it, and 64-bit Windows can have other performance benefits that I'll talk about in a future Pushing the Limits blog post when I talk about virtual memory limits.
why not have the OS make a ramdrive at the extra memory and use it for speeding-up the system, similar to how Vista can use flash memory devices for system speedup?
Recently I have installed Windows 2008 32bits on my board and it reports 1.34GB of Installed System Memory (RAM) and physically I have 1GB of Memory.
I have checked Physically Memory field from msInfo.exe tool and it indicates that system has ~ 1GB.
Do you know how I can figurate why windows increase the RAM installed?
Jaz, you likely have only 1GB (too little, btw) RAM installed, but I suspect you also have a video card with onboard RAM.
This extra RAM on the video card receives an address for mapping, and may be what you are seeing as reported/used memory mapped.
If you were to install further RAM to the full limit of 4GB, you would find that your memory in the machine can be discovered by utility tools and found to total perhaps ~4.3 GB, including both RAM and video, but only 3.5 GB will be available to the system due to this same video card taking up some of the RAM addresses.
Here is my experience and I am looking for the answer.
Base: Asus T3-P5G965
Proc: Intel E6600
Video: Asus X1350
Mem: Corsair Twin2X 800 DDR2 4x1GB
BIOS: memory remap feature is enabled
(If enabled, only 2GB memory is available without PAE kernel. With this option, PAE is available.
If disabled, 2.8GB memory is available without PAE kernel. With this option, PAE is not available.)
Windows XP 32bit is not able to manage the whole physical memory, altough PAE is working as you can see in the following screenshots:
I tried Fedora 9 and 10 x86 distribution, and the basic install OS can show 2GB memory. However, I change to the PAE versioned kernel, the whole 4GB memory is available.
Windows 2003 Server R2 Enterprise:
This Windows edition can manage the whole 4GB memory like the PAE enabled linux.
Here is the boot.ini with the default switches:
multi(0)disk(0)rdisk(0)partition(4)\WINDOWS="Windows Server 2003, Enterprise" /noexecute=optout /fastdetect
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP Professional" /fastdetect /NoExecute=OptIn
So it is sure my hardware is capable to manage 4GB RAM on the 32 bit OSs (Fedora linux, Win2K3R2Ent32)
Why the Windows XP 32bit cannot give me the whole memory while the PAE versioned kernel is used automatically as shown in the first screenshot?
Have somebody ever seen Windows XP 32bit with 4GB RAM? Or Have somebody ever seen anybody to experience this?
Thank you for your response!
Yes -- I have similar problems.
The part mark seems to be unaware of is that consumer versions of XP-32-bit disabled memory above 3GB in SP2 due to driver problems. Used to be documented in some KB article -- supposedly, in SP1, it wasn't broken -- but something else was -- which you could have gotten a patch for at that time if you wanted the full 4GB. But they never ported the patch to SP3 and left it with a 3G limit. Doesn't seem to matter whether I use the map-3G-to-user-space switch or not. I also have a PAE processor that has no problem with seeing 4GB of memory under linux, but MS seemed determine to cripple XP -- apparently they were afraid of some drivers not handling I/O to devices over 4G -- but in Linux they solved that with 'bounce' buffers. A bit slower -- as it's like "paging" memory pages in and out of 'high-memory', but if your option is to limit the memory to 3G and have 4G of memory page on and off of a 1GB-disk page file, vs. paging the 'usable' memory between low<->high memory, guess which is ALOT faster and better use of the hardware? Sigh. If only WinXP was open source and could be fixed. (*hint*? -- hey, the impossible sometimes happens; Bush is staying out Obama's way and letting him deal with the financial crisis even though Obama isn't president yet. If we can get that type of cooperation out of Bush, Microsoft open-sourcing XP should be a comparative slam-dunk :-))
I've got a Toshiba M400 Tablet PC with Vista Ultimate (32-bit), 4 Gigs of 667 MHz RAM, and 45% free on a 7200 RPM, 180 GB hard drive. When it was brand new it responded much more quickly and videos played smoothly. However, it has become rather pokey of late. It's sloooow to respond to mouse clicks (especially the Start Menu), and videos of all formats stutter in WMP (but not as much in WMC).
Someone recommended that I downgrade to Windows XP Tablet 2005. Their rationale was that as an offshot XP Pro, XP Tablet 2005 can make better use of my Gigs of RAM. I don't need all the features Vista has such as Aero and better handwriting recognition (the tablet function is usualy used to illustrate during PowerPoint presentations).
Does this recommendation make sense?
re: Athena's comment: "The part mark seems to be unaware of is that consumer versions of XP-32-bit disabled memory above 3GB in SP2 due to driver problems"
WRONG. There is no such limitation in XP 32-bit.
Mark's article is correct - re-read the sentence "While 4GB is the licensed limit for 32-bit client SKUs, the effective limit is actually lower and dependent on the system's chipset and connected devices."
So XP 32-bit will not access PHYSICAL MEMORY that happens to fall above the 4GB PHYSICAL ADDRESS barrier. So depending on placement of device memory in the physical address range (such as video cards, PCI addresses), you might get 3.1, 3.2, 3.3, close to 4GB - who knows. But there is no 3GB limit!
I have the same issue that nagyandor has with WinXP SP 3. I have 4GB RAM but windows only reports 2GB. Why only 2GB compared to others showing over 3GB?
"I have the same issue that nagyandor has with WinXP SP 3. I have 4GB RAM but windows only reports 2GB. Why only 2GB compared to others showing over 3GB?"
Because your motherboard chipset has decided to reserve 2GB, and theirs hasn't. If you update your chipset drivers, you could see more.
I still cannot find the answer to my question in the title.
Why can I see the whole 4GB memory in linux and Win2k3r2 with PAE and why not in WinXP with PAE?
(see my previous comment)
I am using xp, sp 2, media centre edition, i upgraded my memory to 4G, now it shows me 2.99G in system properties, and 4096Mb in system info, i-e physical memory,
Same problem, i just need solution, i installed 4 gb of ram, and it shows 2.99 Gb in system properties, while in system info it displays 4 Gb, help plz
do you have 32 or 64 bit xp version?
Is there any way of actually finding out why a system is claiming much more ram in use than shown by currently running processes? In this case, I have a sql server running on windows 2003, with 8GB of ram installed. I had to add the /PAE and /3GB switches to the boot ini to get the system to see the full 8GB. In the task manager, I see the full 8GB of ram available, with about 10GB of swap. Now, as far as ram in use, it was roughly 7GB, with another 6GB of swap commited. Digging through the task manager's process list, I could only add up about 3GB of ram in use. Is there anyway of finding out where that additional ram is? or is this a case of just having to reboot the system to reclaim it?
I recently purchased a "economic"Packard Bell PC overseas.It has a Pentium dual core E2180 2.0 GhZ with a Sis 671 chipset with Mirage3(32bit/64Mb)video card and 1Gb DDR2-667MhZ RAM and 32-bit Windows Vista "starter".This OS was the most OBSURD thing ive ever seen.It limited me to 3 programs open at once and didnt have nor support over half the features of Vista home basic.I found out that this Os was intended for entry level,low-cost PC´s in developing countries.Furthermore,the Os was NOT upgradable.So,i went and got myself Vista ultimateSP1 32-bit and Formatted my drive including the 8gig partition for recovery and the Os works fine,better than expected.I also noticed the 980Mb instead of the full 1gb RAM issue as everyone else,so i decided to get myself 4GB of RAM(x2-2GB)and a 128 bit,512 MB 9500 GT.I went to the SiS Page and the motherboard and proccesor support 64-bitOS.So my question is,if I buy the video card and the 4GB of RAM am I going to see a performance increase or should I upgrade to 64Bit first?