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!

Like most of my posts, this assumes that it’s not feasible to go through all your source code, and say, replace all instances of new with a version that tracks usage (the approach used by the debug CRT). As well as being logistically infeasible, this also tends to miss allocations that don’t go via new, for example, direct calls to HeapAlloc.

In the past, I’ve seen some code trying to use the Win32 heap functions to try and find out the amount of memory allocated by the process. It used GetProcessHeaps, HeapWalk and HeapSize to sum all the block sizes and get an overall memory in use figure, but in my experience it was extremely slow and unreliable.

What was really required was something that gave a figure similar to the “private bytes” counter in perfmon. If you didn’t know, this is the counter you need to be watching if you’re looking for memory leaks in a process. For goodness sake don’t use the “Mem Usage” column in Task Manager; this is in fact (almost) the working set size and it doesn’t correlate exactly with memory explicitly allocated by the process. It includes additional things including space occupied by the loaded DLLs. Also, the working set will shrink if the app is paged out, although it still has the memory allocated. To see an example of this in action, open Excel and a large spreadsheet, calc it, look in Task manager and you’ll see a large number (if not, you’re obviously not looking at a real spreadsheet). Then minimise the Excel window. You’ll see the mem usage value plummet as the working set is ”trimmed” – probably by a call to SetProcessWorkingSetSize. The OS does this because it expects the app won’t be being used, so it makes sense to free up physical memory for use by other processes.

So essentially what I want to do is get the perfmon “private bytes” value programmatically as my app is running, and this can be achieved using the Performance Data Helper (PDH) library. It provides an API to access the performance counters in a similar way to the perfmon GUI.

It uses the concept of “queries”; you create a query, add a counter to it, then collect the query data as required (not forgetting to remove the counter and close the query when you’re done).

The first thing to do is open the query:

Then add the required counters (this code assumes you’re looking at a process on the current machine):

At this point you’re ready to start polling for updates. At periodic intervals you can collect the query data and do with it what you will:

Luckily for the Private Bytes counter we’ve got the simplest type of counter to ‘decode’; a raw counter value, essentially just a number. We don’t need to do any further manipulation on it to get the information we need, like having to divide by some frequency.