Processes are not aware of physical hardware. Each process is given its own, private, virtual address space which is a finite amount of virtual memory. This allows the Windows operating system to more efficiently manage physical memory resources (RAM and disk (page file)). If a process attempts to exceed it's virtual address space, then it will crash with an out of memory exception.
Each process has a finite amount of virtual address space that it cannot exceed. The amount of virtual memory per process depends on if it was compiled as 32-bit or 64-bit. x86 is the 32-bit implementation of Windows. x64 is the current 64-bit implementation of Windows.
Important: Use caution before implementing the /3GB operating switch because it takes away virtual memory from the Windows kernel and can result in system-wide hangs.
Dumpbin.exe (Windows SDK) can determine if a 32-bit executable (EXE) supports large address spaces with the following command:
dumpbin /headers <path to EXE>
The following WMI command will show the maximum virtual address space that a process can have on the computer. This command will work on Windows XP/2003 and greater:
wmic PATH Win32_OperatingSystem GET MaxProcessMemorySize
Sample output of this command for a Windows 7 x64 computer is:
VMMap.exe (SysInternals) can attach to a live process and show the virtual memory usage. This can tell you the maximum amount of virtual memory the process can address and is helpful in diagnosing virtual memory fragmentation. When the virtual address space of a process does not have enough contiguous memory to accommodate a virtual memory allocation request, then it will crash. For example, a process might have 500 MB of free virtual memory, but might not have a contiguous block of 64 MB to accommodate a new Gen 0 memory block request from the .NET memory manager.
When the Windows operating system reports that it is low on "virtual memory" and mentions increasing the paging file, then it means that the System Commit Charge has reached the System Commit Limit. The paging file is commonly referred to as "virtual" RAM, hense this reference. Unfortunately, the concept of process and kernel virtual memory is unrelated to the system commit limit. If you suspect a system commit issue, then go to "PerfGuide: Out of System Committed Memory" to troubleshoot.
If the "\Process(*)\Virtual Bytes" performance counter shows more than 80% of the maximum amount of virtual address space of a process, then the process is likely close to running out of virtual memory with a few exceptions - processes like 32-bit SQL Server commonly consume nearly 100% of its virtual address space on purpose. Also, out of [virtual] memory crashes might be logged to the Application event log such as System.OutOfMemory exceptions for .NET applications. To troubleshoot this issue:
If all of the above troubleshooting steps have been exhausted, then the symptoms of process out of virtual memory issues can be treated with one or more of the following:
Note: Keep in mind that processes are not aware of physical resources, so changing the amount of RAM or page file size has no effect on process virtual address space.
Vital Signs Workshop: Microsoft Services offers an instructor led workshop called, "Vital Signs", which goes in depth into Windows architecture focused on Windows performance analysis. If you are interested, then contact your Microsoft Technical Account Manager (TAM). If you do not have a Microsoft Premier Support contract, then consider the great benefits of having one by going to our Microsoft Services Premier Support web site at: http://www.microsoft.com/microsoftservices/en/us/support_premier.aspx