Tell tale sign of memory fragmentation (as opposed to a memory leak)?

Question

First I realize that leaks can fragment memory badly, but please bear with me.

• Using WinDbg and attaching to a process: Using !heap (or another WinDbg command), what should I expect see if I'm dealing with memory fragmentation as opposed to a leak? For instance, I can use "!heap stat" and "!heap stat -h handle" to zero-in on the code generating a leak; but is there something in these same return values which would hint at fragmentation?
• Has memory allocation changed radically between XP and Vista? Particularly, as related to DLL and other library-loading? We've been developing exclusively on XP so I'm unfamiliar with Vista, but it turns out that certain memory issues we've been seeing on XP disappear when we install the same binaries on Vista.

Thanks!

Answer 1

I am sorry I can't help you with the fragmentation issue, so I am only going to address your second question.

Vista introduced ASLR which changes the way DLLs are loaded. For more info see this wiki entry and for a more specific discussion this post may be useful.

Answer 2

Starting with Windows Vista a new memory manager is enabled by default, called the low fragmentation heap (m2).

MS Description

For Windows XP you can enable the low fragmentation heap using the following code:

HANDLE heaps[1025];
DWORD nheaps = GetProcessHeaps((sizeof(heaps) / sizeof(HANDLE)) - 1, heaps);
for (DWORD i = 0; i < nheaps; ++i) {
  ULONG  enableLFH = 2;
  HeapSetInformation(heaps[i], HeapCompatibilityInformation, &enableLFH, sizeof(enableLFH));
}

Answer 3

There are a couple of different kinds of fragmentation: address space fragmentation and heap fragmentation. The former could cause failures to expand managed or unmanaged heaps, or failures to load DLLs, the latter could cause memory allocation failures in calls to new.

You can use !address -summary to get an overview of the address space. This tells you how much space is free, committed, used for DLL mapping, virtual address descriptors (metadata), etc. The sysinternals VMMap tool gives you a graphical view of it, without the need for the debugger.

For heap fragmentation, the output from !heap -s should include some indication of how fragmented unmanaged heaps are, e.g.:

00970000 00001002   64576  39232  49736   5732  1314   448    0      1   L  
    External fragmentation  14 % (1314 free blocks)
    Virtual address fragmentation  21 % (448 uncommited ranges)

You can dig into this using !heap -stat, e.g. !heap -stat -h 00970000 given the output above, and this will tell you the distribution of allocation sizes etc. This can be useful to see if you've got large amounts of small objects, assuming you're not using the low fragmentation heap, e.g.:

0:057> !heap -stat -h 00970000 
 heap @ 00970000
group-by: TOTSIZE max-display: 20
    size     #blocks     total     ( %) (percent of total busy bytes)
    134 c0c8 - e7f0a0  (50.72)
    18 ee22 - 165330  (4.88)
    8c 26f9 - 15502c  (4.66)
    a4 1ffc - 147d70  (4.48)

Hope this helps.