Freeware MemCheck displays memory statistics and can commit and lock memory.

Download MemCheck.zip.

The ReadMe.txt files contains:

Memory Check [Version 1.00]Displays information about the system's current memory statistics.  Also allowsyou to commit and lock memory, to experiment with how much virtual and physicalmemory is currently available to new processes.The syntax of this command is:MemCheck [/commit:#] [/lock] /COMMIT: Allows you to commit a specified size of memory (in megabytes).          The maximum value allowed is 4095. /LOCK causes the memory specified with /COMMIT to be locked into physical       memory.  This ensures that subsequent access to the region will       not incur a page fault.Examples:  MemCheck /commit:1024  MemCheck /commit:512 /lockLegend:  1KB=1024 Bytes; 1MB=1024 KB; 1GB=1024 MBAn argument of /? or -? displays this syntax and always returns 1.A successful completion will return 0.Copyright 2004 Marty List, www.optimumx.com===============================================================================System Requirements:Windows Server 2003; Windows XP; Windows 2000; Windows NTRevision History:1.00 07/20/2004Initial release.

Marty also wrote:

Memory management is a large and complicated subject, but here I'll try to explain this portion of it in an easy to understand. Basically a standard 32-bit Windows application can only access (or reference) 4GB of virtual memory. It doesn't matter how much physical memory is installed, or how big the page file is, the largest number you can store with 32 bits is 4294967296:

2^32 = 4294967296
4294967296 / 1024 = 4194304 KB
4294967296 / 1024 / 1024 = 4096 MB
4294967296 / 1024 / 1024 / 1024 = 4 GB

So even if the machine has 6GB of physical and another 2GB of page file (8GB virtual), when a 32-bit app asks the OS for memory, the most it even knows how to ask for is 4GB (even though it could never actually get that much). And of this 4GB, Windows breaks it up into 2GB for user-mode application use and 2GB for OS use (this is global and includes kernel-mode drivers, etc). So a standard 32-bit app on a default OS can not access more than 2GB of virtual memory.

On certain versions of Windows, you can add /3GB to the boot.ini and this 4GB will be broken up into 3GB for user-mode and 1GB for kernel mode (globally). From my testing, these versions of Windows support the /3GB switch:

Windows NT4 Enterprise Edition
Windows 2000 Advanced Server
Windows 2000 Datacenter Server
Windows XP Professional
Windows Server 2003 Standard Edition (also supports /USERVA=)
Windows Server 2003 Enterprise Edition (also supports /USERVA=)
Windows Server 2003 Datacenter Edition (also supports /USERVA=)
* I haven't tested the Web Edition yet

Now even if the OS supports the /3GB option, each application also has to be compiled as "3GB enabled" using the "/LARGEADDRESSAWARE" linker option (or you can change the executable's image header later with imagecfg.exe). So a standard 32-bit app, on any Windows OS, can not access more than 3GB of virtual memory.

I haven't done this yet, but you can also develop applications that can reference more than 4GB of memory using special APIs called AWE (Address Window Extensions). If your system has more than 4GB of physical memory installed you can enable this by adding /PAE to the boot.ini to enable "Physical Address Extensions". But just adding /PAE to a machine with more than 4GB will not change the limit of standard apps, they need to be rewritten and recompiled to access the "extended" address space. SQL Server 2000 is the only app I know of that supports AWE, and it's not enabled by default.

Remember this 2GB or 3GB limit applies to virtual memory, not physical memory. Lets say you have an app that wants to access 3GB of memory, this is possible even if you only have 2GB of physical memory, if you have at least 2GB of page file (4GB virtual memory). Obviously your performance is better if the machine has 4GB of physical memory.

Also remember this 2GB or 3GB limit is from a single process perspective, it doesn't apply to the system as a whole. Lets say you have 5 processes running concurrently and they all want access to 3GB of virtual memory, then this should be possible if you have at least 16GB of total (virtual) memory (3x15=15, +1GB for the OS/kernel). Now obviously you'll get the best performance if the machine has 16GB of physical memory, but it should still work if the machine has 12GB of physical memory and 4GB of page file.

Most of this changes with the 64-bit editions of Windows (but some of it's still true when running 32-bit apps on 64-bit Windows). Let me know if you got this far without falling asleep :)

Further reading:

Inside Memory Management, Part 1 (Mark Russinovich)
http://www.windowsitpro.com/Article/ArticleID/3686/3686.html.

Inside Microsoft Windows 2000, Third Edition (David Solomon and Mark Russinovich)
http://www.sysinternals.com/insidew2k.shtml.