How to use windbg track memory allocated by VirtualAlloc?

Question

you know how you can use gflags wih + ust to get a call stack paired with each distribution. can you use heap in windbg to diagnose leaks?

I want to do this with large selections made through VirtualAlloc. As far as I can tell, VirtualAlloc bypasses the gflags / extensions! Heap?

I hope someone can confirm

a)! heap looks at the list of allocated memory in each heap, but not the allocated memory obtained from VirtualAlloc

b) when you allocate a huge chunk of memory with new / malloc, which goes to LocalAlloc () and then to VirtualAlloc (), where it bypasses the call stack registration

I really hope someone can help me debug this kind of leaks. if the distributions were smaller, I would not have a problem with! heap

Answer 1

You can try LeakDiag, which works with several different types of memory, including memory coming from VirtualAlloc.

Answer 2

Heap functions work at a higher level than Virtual* functions; in fact, the heap should call VirtualAlloc to add more memory to the process address space. !heap will not help you with Virtual* calls.

Answer 3

Background

The operating system provides memory only through VirtualAlloc (). This works fine, but the graininess is not very good: it can only provide 64K at a time. This is why Microsoft has implemented various heap managers, for example. C ++ heap manager or .NET heap manager. They receive memory from the OS in 64kB blocks and provide it in small fragments in a C ++ or .NET program.

!heap , and related commands work only with the C ++ cumulus manager. To test a bunch of .NET, you need sos for WinDbg.

Regarding your questions

As far as I can tell, VirtualAlloc bypasses the gflags / extensions! heap?

The GFlags +ust specific to C ++ heap allocations. The !heap Heap commands also apply to the C ++ heap manager, so yes, none of them will care about VirtualAlloc () calls.

However, I would not say that VirtualAlloc () “bypasses” them, which would be an expression of the fact that it goes through a C ++ heap manager. It's rather the other way around: it's at a lower level than the heap manager.

a)! heap looks at the list of allocated memory in each heap, but not the allocated memory obtained from VirtualAlloc

Yes, for the same reason.

b) when you allocate a huge chunk of memory with new / malloc, which goes to LocalAlloc () and then to VirtualAlloc (), where it bypasses the call stack registration

I guess, yes. There is a point at which it is no longer worth dividing the memory into smaller areas. Obviously, allocating 64K for a 2-byte variable is too much waste.

Microsoft drew a line at ~ 512 kB, as described in HeapAlloc (find the term 0x7FFF8). Therefore, when you allocate more than 512 KB, it will no longer use the heap manager, but a block of raw memory VirtualAlloc (). In the worst case, overhead is 12% (64 KB waste with 512 KB + 1 byte allocation).

Do not worry

There are other tools for recognizing large memory leaks that arise from VirtualAlloc (). The WinDbg !address Address command is useful and the Rohitab API monitor can help. As suggested by others, you can also try LeakDiag or commercial memory leak analyzers.