It’s obvious looking at the output from VMmap or windbg’s !address command what the largest contiguous block is, e.g.

0:008> !address -summary
....
Largest free region: Base 07300000 - Size 63ed0000 (1637184 KB)

But what if you need that number in order to make a decision at run-time? For instance, to decide whether your process is in a fit state to continue, or if it should instead commit hara-kiri. In that case, you need to access the information programmatically. That’s where the immensely useful VirtualQueryEx function comes in…

VirtualQueryEx gives you information on a single page of your virtual address space at a time. Pages size are dependent on the architecture and OS, but if you just want to iterate over all of them, you don’t need to add any special handling; the function returns the size of the page in an element of the MEMORY_BASIC_INFORMATION structure, so you can simply move to the ‘next’ page regardless of size.

If you’re interested in free space, you’ll need to find all the pages that have a state of MEM_FREE (0×10000), and that’s pretty much all there is to it. By keeping track of how much space falls into a continuous range of MEM_FREE pages you can get to the number reported by VMmap and !address.

Here’s some C++ code that returns the address of the largest free contiguous block in largestFreestartlargestFree. Enjoy!

	MEMORY_BASIC_INFORMATION mbi;
	DWORD start = 0;
	bool recording = false;
	DWORD freestart = 0, largestFreestart = 0;
	__int64 free = 0, largestFree = 0;
	while (true)
	{
		SIZE_T s = VirtualQueryEx(hproc, reinterpret_cast<lpvoid>(start), &mbi, sizeof(mbi));
		if (s != sizeof(mbi))
		{
			if (GetLastError() != ERROR_INVALID_PARAMETER)
				return ReportError(GetLastError(), _T("Failed to VirtualQueryEx at %08x"), start);
			else
				break;
		}
		if (mbi.State == MEM_FREE)
		{
			if (!recording)
				freestart = start;
			free += mbi.RegionSize;
			recording = true;
		}
		else
		{
			if (recording)
			{
				if (free > largestFree)
				{
					largestFree = free;
					largestFreestart = freestart;
				}
			}
			free = 0;
			recording = false;
		}
		start += mbi.RegionSize;
	}

Private data

This is the data that is explicitly allocated by the process, or blocks of memory that contain the allocated data. So when you’re allocating from the heap, for instance, using code like:

char *p = new char[1024*1024];

you can see how the heap manager manages address space; creating reserved segments of a fixed size, then committing parts of them as required.
When a segment is full, it will create a new one of double the size.

Allocate first 256*1024 bytes:

After allocating first 256KB

After allocating another 256KB

And another...

And yet another...

Causes of out of memory errors

Fragmentation

If you’re experiencing out of memory errors, the first thing to check is the largest free block size. Obviously if you’re requesting more than the available size, your allocation will fail. Remember that large requests may be made implicitly by mechanisms that are outside your control. For instance, Windows heaps expand geometrically, attempting to grab a segment of double the previous size each time, e.g. 16, 32, 64, 128MB. As you can see, allocating a single byte when the 64MB segment is full will result in the heap manager trying to reserve a 128MB block.

So once you’ve seen that the largest free block is small, the question then is: why? It’s either due to genuine memory exhaustion or address space fragmentation.

Heap contention

Fragmentation can be due to multiple heaps contending for contiguous address space. This is typically the case when you have a mix of VC++ code that is built using different versions of the runtime libraries (msvcrt.dll, msvcr70.dll, msvcr80.dll, msvcr90.dll), each of which manages it’s own heap.

Remember that heap segments need to be reserved as a contiguous block of address space, but if your virtual memory is fragmented, the heap manager may not be able to obtain one. In this case, it will fall-back to creating segments of smaller sizes. The problem is that there’s a limit to the number of segments that can be created – a measly 32 in Windows XP – so if fragmentation causes it to create more, smaller segments this limit may be reached. If a new segment cannot be created you’ll get out of memory errors.

If you suspect this, you can use !heap -m to see details of the segment count and sizes for each heap. To identity the heap associated with each version of the MSVC runtime, ensure you’ve got the appropriate symbols loaded and then use dd msvcr80!_crtheap L1 to see the address.

Address space exhaustion

It may also be possible that you really have exhausted your 2GB address space. This can happen when your process wastes lots of address space due to allocation granularity. For example calling VirtualAlloc without an address will cause the OS to choose one for you, and as the documentation states, this will be rounded to a multiple of the allocation granularity, 64KB. So if you happen to allocate lots of objects of only a few bytes with direct calls to VirtualAlloc, you will waste almost 64KB a time. Although this might not seem significant in a 2GB address space, it all adds up.

One of the symptoms of address space exhaustion is DLLs failing to load. I noticed recently that a COM CoCreateInstance call was failing because the only address space left to load the DLL into was way up into the area usually reserved for OS DLLs such as ntdll.dll.

Other tips

By default the allocations are ordered by Address (the first column) and, because things are generally allocated in increasingly higher locations in memory, this can serve as a useful “timeline” of the app’s allocations. It’s not guaranteed though: DLLs that have an explicit load address don’t follow this pattern (for example, VBE6.DLL always loads at 0×65000000). You can use it to see roughly when threads and heaps are created and files are mapped though.

Summary

So, I hope you find this information useful in interpreting the output from VMMap. It’s a very good way of getting visibility on the state of your processes and it’s certainly more intuitive than having to use the !address and !heap commands in WinDbg.

Good hunting!