[SOLVED] How to avoid "(null)" StackTrace in DPH_BLOCK

How to avoid "(null)" StackTrace in DPH_BLOCK_INFORMATION?

I'm having a blast tracking down some heap corruption. I've enabled standard page heap verification with

gflags /p /enable myprogram.exe

and this succeeds in confirming the corruption:

===========================================================
VERIFIER STOP 00000008: pid 0x1040: corrupted suffix pattern 

    10C61000 : Heap handle
    19BE0CF8 : Heap block
    00000010 : Block size
    00000000 : 
===========================================================

When I turn on full page heap verification (gflags /p /enable myprogram.exe /full) in anticipation that this will cause an error to occur at the time the corruption is introduced, I get nothing more.

I started to get my hopes up while reading Advanced Windows Debugging: Memory Corruption Part II—Heaps, which is a chapter from Advanced Windows Debugging. I installed WinDbg, and downloaded debug symbols for user32.dll, kernel32.dll, ntdll.dll according to http://support.microsoft.com/kb/311503. Now when the program halts in the debugger I can issue this command to see information about the heap page:

0:000> dt _DPH_BLOCK_INFORMATION 19BE0CF8-0x20
ntdll!_DPH_BLOCK_INFORMATION
   +0x000 StartStamp       : 0xabcdaaaa
   +0x004 Heap             : 0x90c61000 
   +0x008 RequestedSize    : 0x10
   +0x00c ActualSize       : 0x38
   +0x010 FreeQueue        : _LIST_ENTRY [ 0x0 - 0x0 ]
   +0x010 TraceIndex       : 0
   +0x018 StackTrace       : (null) 
   +0x01c EndStamp         : 0xdcbaaaaa

I am dismayed by the (null) stack trace. Now, http://msdn.microsoft.com/en-us/library/ms220938%28VS.80%29.aspx says:

The StackTrace field will not always contain a non-null value for various reasons. First of all stack trace detection is supported only on x86 platforms and second, even on x86 machines the stack trace detection algorithms are not completely reliable. If the block is an allocated block the stack trace is for the allocation moment. If the block was freed, the stack trace is for the free moment.

But I wonder if anyone has any thoughts on increasing the chances of seeing the stack trace from the allocation moment.

Thanks for reading!

Solution

Ah ha! Turns out I needed to enable more gflags options:

gflags /i myprogram.exe +ust

Which has this effect:

ust - Create user mode stack trace database

Seems straightforward when I see parameter description. Silly me. But I also seem to need to set the size of the trace database before it will take effect:

gflags /i myprogram.exe /tracedb 512

...or whatever (in MB).