A: 

Did you enable the needed debug options with AppVerifier or Gflags ? Memory blocks will have a _DPH_BLOCK_INFORMATION only if pageheap option is enabled, and you will be able to display the stack backtrace if that option is also enabled. To display the stack trace of a block, you can use !heap -p -a <block address>.

Be aware that !heap -l may display lots of false positives if not used at application exit time. You could also try umdh (also included in Debugging Tools for Windows), or DebugDiag.

plodoc
Thanks for the reponse!I am aware that I am supposed to use !heap -p -a <block address> to get the trace, but the problem is that I don't know how to extract a block address from the information returned !heap -l (namely, Heap, User, Entry, or Segment). Do you know how to do that? Thanks for the warning that !heap -l displaying false positives if not used at exit time. I wasn't aware of that. The documentation made it sound as if it was tracking memory for which there were no more references.
Kevin
Also I am aware of UMDH and I love it, but, alas, my application is too large for it.I've been recently introduced to DebugDiag and it works like a charm. However, I am suspicious about its algorithm for determining a leak. Its documentation says that the "leak probability" is based on research that says that allocations made evenly throughout an applications lifetime suggest a leak while those which are bunched at the beginning or end do not. That doesn't make sense to me;I've worked on plenty of programs which allocate consistently across a program's lifetime, but they also clean up.
Kevin
Ran out of space. Back to DebugDiag. So to the extent that its algorithm for determining a leak seems non-sensical to me, I don't yet trust it. I'd be much happier with a tool that can show me memory blocks for which there are no outstanding references. That seems an invariant way to determine a leak.
Kevin
You can use !heap -p -a with any address, it will retrieve the corresponding block if it has been heap allocated. Entry is the address of the memory block. You can display the header with dt _HEAP_ENTRY <Entry>. User is the address returned by the allocation returned. It will be Entry+8 if no debug flags are active.
plodoc
DebugDiag tries to distinguish leaks and cache. Some cache are built at the start of the application when data is loaded first, that's why by default DebugDiag waits 15 minutes before starting to monitor.
plodoc
You may try the leak detection at program exit. Set the registry DWORD value HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\<your executable.exe>\ShutdownFlags to 3. Attach a debugger to the process. The system will break in the debugger when the program exits. The list of outstanding blocks will be listed in the command window of the debugger. What do you mean by your application is too large for umdh ?
plodoc
On DebugDiag: In your experience, when it reports a high leak probability for a stack trace, is it usually correct? Have you seen a lot or any false positives? The run I did looked to have some fals positives. That's why I was more interested in the windbg route.On UMDH: I haven't tried it on our application directly but some team members have said that our program is so large that the overhead of the user stack trace database grinds its performance to a virtual halt. Thanks for responding!
Kevin
Yes it did report leaks for data that was cached. We discovered system caches, like for BSTR strings, and deferred releasing of memory, for instance with msxml.Regarding UMDH, the stack trace database memory footprint is configurable, and a Microsoft engineer told me once the performance hit of umdh was less than DebugDiag. I did not mesure that myself.
plodoc
That's very helpful. I'm most grateful. UMDH is an excellent tool. If I can get it to work, that would be terrific. Thanks again!
Kevin