views:

247

answers:

2

I'm debugging an out-of-memory exception. When I get the exception, the "virtual bytes" performance counter indicates plenty of addressable space. The problem, however, is that the addressable space is badly fragmented, and the "Largest free region" (returned from !address in WinDbg) is too small.

To measure the memory fragmentation, I would like to monitor the "Largest free region" in perfmon. Is there a performance counter that gives me this value?

+1  A: 

From http://dotnetdebug.net/2005/06/30/perfmon-your-debugging-buddy/ :

Virtual Address Space Fragmentation Indicators:

  • Number of total reserved Bytes significantly larger than # total committed Bytes
  • Number of Pinned Objects increasing
  • Number of GC handles increasing
  • Number of bytes in all heaps always increasing.

MSN

MSN
These are some good indicators, but the worst offenders are actually outside of .NET inside C dlls that memory map files. These indicators assume that the problem is visible form .NET, but unfortunatelly it is not in my case.
Sean
If you could look at reserved bytes vs. committed bytes, that would give you a better idea. I don't see a counter like that though.MSN
MSN
+2  A: 

I don't believe that there's a single performance counter for this piece of information, but it can be deduced by using the VirtualQueryEx Win32 function.

You can call it on the minimum valid virtual address (which can be obtained from GetSystemInfo), you can then use the size of the returned page range to determine the base address of the next page range for which to call VirtualQueryEx.

By walking through the address space with repeated calls to VirtualQueryEx like this you can determine the largest page range of type MEM_FREE and what its base address is.

This is the technique that I used for my 'Address Space Monitor' program.

Charles Bailey