Sorry, but all of these answers miss the mark.
The short answer: the
VM size column does not reflect the total virtual address space (“v.a.s.”) defined by the process. It is only a subset of that. Specifically, it is the "private committed" address space (also known as the process's "commit charge").
Mem Usage column shows the subset of the process's total virtual address space which is "valid" for the process, i.e. can be accessed without incurring a page fault.
(It's common, but inaccurate, to say that it's the subset that's "in RAM". "Valid" - i.e. in the process working set - means it's in memory and it can be accessed without incurring a page fault. But due to the action of the page caches (standby and modified page lists), plus shared memory, there is usually quite a bit of the process's v.a.s. that's in RAM but requires a page fault to access... but it'll be a "soft" page fault, i.e. one that does not involve disk I/O. Once resolved the page is in the process working set and further references to it won't incur faults... unless it is later aged out of the working set.)
VM size is not all of the process's virtual size, where's the rest of it? The other major contributor to a process's total virtual address space is mapped address space. The difference between them is that private committed v.a.s. - I'll just call it private from now on; there is no such thing as private non-committed - is backed by the pagefile, whereas mapped v.a.s. is backed by the files it's mapped to.
"Backed by" means that the portion that can't be kept in RAM is kept in those files.
There is also nonpaged virtual space (very small) and, possibly, "physically mapped" memory (very uncommonly used).
The total of all of these could be called the total accessible virtual address space of the process, because all of it can be referenced without incurring a memory access violation (but, for the pageable parts, could incur a page fault, but that doesn't mean they're not accessible; it just means the first access takes a little longer).
The first two portions, private committed and mapped address space, could be called the total pageable virtual address space.
Mem Usage column should have been called "Working Set (total)". It will normally be smaller than the total pageable v.a.s. Unfortunately XP's Task Manager doesn't have a counter for the latter. But anyway, the
Mem Usage column shows how much of the total pageable virtual address space can be referenced by the process without incurring a page fault. Some of this will be physical pages associated with private committed pages, and some with mapped pages.
If XP's task manager had a few more columns available, you would see the relationships you expect to see: Total pageable v.a.s. (for which there is not now a counter) should never be smaller than total working set (called
Mem Usage in XP); and the private committed v.a.s. should never be smaller than the private portion of the process working set.
Task manager in later versions of Windows does have a few more of these counters. The Process Explorer tool from Sysinternals has even more. In Process Explorer:
"Working Set" is the process' total working set
"WS Shareable" is the subset of the total that is potentially shared with other processes (it's a subset of the mapped v.a.s.)
"WS Shared" is the subset of "WS Shareable" that actually is being shared with other processes, i.e. it's in some other processes' working sets too.
"WS Private" is the subset of "Working Set" that is not shareable with other processes. It's associated and a subset of the process's private committed v.a.s.
"Private Bytes" is the process's private committed v.a.s. You'll notice it's always larger than "WS Private", which is the relationship you're looking for.
"Virtual Size" is the total amount of not-free v.a.s. in the process. This includes private and shared v.a.s., but also "reserved" address space. "Reserved" is not accessible, occupies almost no physical space anywhere, but does reserve ranges of virtual addresses. It does not include physically mapped regions (aka "AWE" memory). On x64 under Win 8.1 and later it may also include a gargantuan area (2,147,483,648 K, or 2 TiB) set aside for a new feature called "Control Flow Guard". For information on that, see this entry at Alex Ionescu's blog.