Wolfram|Alpha: Systematic knowledge, immediately computable.

Wednesday, April 14, 2010

Yes, Virginia, 32-Bit Windows can use more than 4GB of physical RAM...

In one of the forums I frequent, a debate broke out in a thread over whether 32-bit editions of Microsoft Windows can in fact handle or otherwise use any physical RAM in a system over 4GB. There is still widespread misinformation posted about this, even after all the time taken by various MS engineers (such as the most amusing Raymond Chen) to clarify the facts.

Let's set the record straight.

YES! 32-bit versions of windows can take advantage of more than 4GB of physical RAM.

Example 1: The server editions.
I refer the reader to Memory Limits for Windows Releases for the canonical document.

On these systems, the application is of course limited to 2GB of userspace virtual address space. Using the (again, oft misunderstood) /3GB switch, applications that are compiled with the appropriate flag can avail themselves of a 3GB virtual address space. Utilizing processor and OS PAE capabilities, and Windows APIs such as AWE, or via Kernel mode drivers, such applications can map whatever physical RAM address space the machine exposes into their particular virtual address space. This is how things like SQL Server can have huge memory use (well over any 4GB limit) on such versions of the OS.

Far too many Internet 'experts' advise readers to use things like the /3GB switch to 'increase how much memory your program can use', completely missing that fact that the application must be compiled using the appropriate flag to do this. This can be done 'after the fact' with EDITBIN or a Hex editor, but unless you're sure the coders of the application were sane, or you've otherwise analysed the binary, you might be asking for trouble. In addition, programs compiled with '/GL' (Whole Optimization) cannot be modified using accepted post-compile methods. The end result is the reader ends up burning 1GB of address space that the OS could use for the Kernel, that ends up just sitting there wasted. I would direct the interested reader to the aforementioned Raymond's blog for an amusing, multi-year expose of this.

Example 2: The 'client' editions.
Things get a little more confusing for the 'client' versions of Windows (the consumer versions.) For these, Microsoft decided after rigorous testing that the problems exhibited by drivers and other low-level code would present too many problems when faced with RAM addresses beyond 4GB, and so disabled the 'awareness' of the OS for these versions of the OS for RAM beyond 4GB.

However, properly coded applications and drivers (e.g., Ram Disk software by SuperSpeed) can in fact utilize RAM beyond 4GB even in the 'client' 32-bit Windows versions. I used to do this every day, until the remaining reasons not to use a 64-bit OS were eliminated for me.

Here's a screenshot of this very application, running on a friend's PC with 6GB of physical RAM, providing a 5GB RAM Disk. Note that the 2GB of physical RAM above 4GB is being used perfectly well by this application running under 32-bit Windows (click to see large original):


There were valid reasons for using such 'work-arounds' for 32-bit systems to use more than 4GB of RAM in the past: driver vendors had not kept up with 64-bit systems, and often had either no drivers, or problematic ones. Those days seem long gone, and at this point, there's really no good reason not to use a fully 64-bit capable operating system, even on consumer PCs.

Nonetheless, the fact remains: Yes, Virginia, 32-bit windows can use more than 4GB of ram.


Finally! Someone at Microsoft read this, perhaps? As of early 2011, the Microsoft Developer Network's canonical document "Memory Limits for Windows Releases" has been properly updated with the correct facts:

X86 client versions with PAE enabled do have a usable 37-bit (128 GB) physical address space. The limit that these versions impose is the highest permitted physical RAM address, not the size of the IO space. That means PAE-aware drivers can actually use physical space above 4 GB if they want. For example, drivers could map the “lost” memory regions located above 4 GB and expose this memory as a RAM disk.

About time...


  1. Actually there is only one flag / bit to set in the PE header to use large address aware with /3GB and in quite a few applications the compiled exe can be modified afterwards for what good it will do.

    Vista and W7 client kernels can be simply modified, if you know what you are doing, to use that ignored memory remapped or otherwise above 4GB and a lot of the time without driver issues but no guarantees of course.

    Be aware that using a RAMDisk with memory mapped above 4GB runs outside the Windows memory manager. There is some risk of corruption as there is no protection. As an example try running 2 RAMDisks from different vendors. You might find that they will both inadvertently use the SAME memory above 4GB.

  2. @anonymous 041410-23:40:
    Thanks for reading and commenting.

    I kept this simple - this is not a hacking blog, but of course the header can be manipulated, either via editbin, or just a simple hex editor. And not so obviously, this is not even really needed with rare exceptions when using the server versions of the OS: witness SQL server which will happily use well over 4GB via AWE with the flag disabled.

    It is also equally simple to modify the PAE kernels on the client 32-bit versions, though strictly speaking this violates MS licensing, I'm sure you're aware.

    Lastly, that is of course obvious but only for the client 32-bit versions, as it would be for anything accessing such functionality directly behind Window's back (since client versions ignore upper memory.) I know of no other commercial RAM disk that uses this technique, so it's not a concern. The server 32-bit versions provide the same general memory protections under PAE/AWE use as when not using these (e.g., page sharing is not even allowed).

    Of course, as I said in closing, all moot, since there really is no reason anymore not to use a 64-bit OS.

    Thanks again for commenting.