VMMap is an excellent tool within the system, it can be visualized virtual memory for a specific process, and to help understand use of memory. It has a thread stack, a specific report image, Win32 heap and GC heap. Sometimes, VMMap report will not be used for virtual memory, which is memory available different. Here is a 32-bit process (a total of 2GB of virtual memory) of VMMap report Example:
This "not available" memory come from, why not use? Windows virtual memory manager has a particle size distribution of 64KB. When directly VirtualAlloc allocate memory and requires less than 64KB (such as 16KB), VirtualAlloc return address on the 64KB boundary. Then partitioned first four pages (16KB), the remaining 48KB marked as unused. This memory can not be obtained by performing another assignment, because the return address VirtualAlloc will always reside on 64KB boundaries. Well, this memory is not available.
VMMap fragmentation view of the problem is more obvious. In the screenshot below, the yellow dot is 4KB region, it can be allocated and used, and the gray rectangle is 60KB region, can not be used. When the entire area of these address spaces are not available, you get virtual memory is not so much as you think.
Fortunately, it's easy to find the source of illegal distribution. Essentially, we are looking for an allocation size is less than 64KB (or better: You can not be divisible by an average of 64KB) calls VirtualAlloc. You can use VMMap itself (it has a tracking mode) to track these assignments, you can also attach WinDbg and set breakpoints:
0:000> bm kernelbase!VirtualAlloc* "r $t0 = poi(@esp+8); .if (@$t0 % 0x10000 != 0) { .printf \"Unusable memory will emerge after allocating %d bytes\", @$t0; kb 4 } .else { gc }"
1: 76c03e8a @!"KERNELBASE!VirtualAllocExNuma"
2: 76bcd532 @!"KERNELBASE!VirtualAlloc"
3: 76c03e66 @!"KERNELBASE!VirtualAllocEx"
0:000> g
Unusable memory will emerge after allocating 4096 bytes
ChildEBP RetAddr Args to Child
00defd48 010a4e34 00000000 00001000 00003000 KERNELBASE!VirtualAlloc
00defe2c 010a5f25 00000000 00000000 7eaa7000 FourKBLeak!allocate_small+0x34
00deff18 010a6989 00000001 012ba870 012bae98 FourKBLeak!main+0x35
00deff68 010a6b7d 00deff7c 7529919f 7eaa7000 FourKBLeak!__tmainCRTStartup+0x199
This breakpoint is passed to ensure that the size distribution may be 64KB VirtualAlloc divisible. Otherwise, the breakpoint will stop and print out the assignment in question and the call stack; otherwise, it will continue. This will capture the small allocation of sources becomes very easy, and is expected to fix them.