views:

119

answers:

1

I'm learning to use WinDbg and I might be way off track on this, but I assume that if my program isn't using a paged heap that instead of _DPH_HEAP_BLOCK structures that "own" a pointer to my allocation, I would instead have a _HEAP_ENTRY for the allocated data.

Given an address to allocated data on the heap, how might I find which _HEAP_ENTRY goes with it (in WinDbg), or does my question not even make sense?

The root of my question is my desire to know if an allocation in a dump was freed or if the heap was corrupted somehow.

+2  A: 

!heap -p -a <address>

With page heap enabled, this dumps out useful information (potentially including the callstack of the last person to allocate/free this heap block) - I think this visualizes the _DPH_HEAP_BLOCK.

Without page heap enabled it just shows basic info - which isn't that useful. I think this is the regular _HEAP_ENTRY struct. Debugging double frees/etc at the point of the second access is pretty much impossible (by mere mortals such as myself, at least).

When confronted with a heap issue, I immediately enable heap validation via AppVerifier, then repo again. This does two things:

  1. It moves AV's from accessing freed memory "further up" to an earlier point in time, sometimes making the root cause of bugs obvious

  2. It makes the !heap -p -a <address> command dump out a lot more useful information, including the callstack of who last freed it (!!)

!heap+app verifier is pretty awesome, and probably second only to memory write breakpoints on the list of ninja-windbg-foo that everyone should know.

Terry Mahaffey
Sadly, I have no repro.
Sydius
Also, shouldn't it be possible to go from the address back to the heap structures, or else how does free work?
Sydius
I think the same command (!heap -p -a <address>) will dump out the HEAP_ENTRY for an allocation if page heap isn't enabled; but HEAP_ENTRIES just aren't that useful. It's the callstack in the debug heap entry that really helps track down these bugs.
Terry Mahaffey