debuggingwindbggflags

remote dump analysis - is the "user mode stack trace database" par to the dump file?


If I have a need to analyze memory leaks in a dump from a remote machine and I have enabled the user mode stack trace database as detailed here are those stack traces going to be a part of the dump file or I need to transfer something else from the remote machine except for the dump file? Or can I only see those stacks when running WinDBG on the same machine the dump was taken on? So far, all the resources I've seen regarding this topic, do not elaborate on what is the actual storage place for these stacks.


Solution

  • the data base should be in dump
    take a look here for a sample to follow

    compile , run in one command prompt gflags /i dbstk.exe +ust +hpa & dbstk
    will be waiting for keypress
    open another command prompt and attach to the running exe
    cdb -pn dbstk.exe

    and create a dump
    .dump /ma d:\blah.dmp

    open the dump and look at stack tracedatabase

    cdb -z d:\blah.dmp
    !heap -p

    you should get some thing like this indicating the address in the dump

    0:001> !heap -p
    
        Active GlobalFlag bits:
            hpa - Place heap allocations at ends of pages
    
        StackTraceDataBase @ 000001922cbb0000 of size 0000000001800000 with 00000010 traces
    
        PageHeap enabled with options:
            ENABLE_PAGE_HEAP
            COLLECT_STACK_TRACES
    
        active heaps:
    
        + 1922e3b0000
            ENABLE_PAGE_HEAP COLLECT_STACK_TRACES
          NormalHeap - 1922f460000
              HEAP_GROWABLE
        + 1922f560000
            ENABLE_PAGE_HEAP COLLECT_STACK_TRACES
          NormalHeap - 19230640000
              HEAP_GROWABLE HEAP_CLASS_1
    0:001>  
    

    but the !heap extension has been rendered mostly useless due to several
    modifications in heap structures in the name of security
    and the extension has been lagging behind
    so you may be forced to grope in bits and bytes

    on x64 i think you should start groping from here onwards (may be wrong take it with a pinch of salt haven't touched x64 heap in a long time)

    0:001> dt ntdll!_STACK_TRACE_DATABASE poi(ntdll!RtlpStackTraceDatabase)
       +0x000 Reserved         : [104]  ""
       +0x000 Lock             : _RTL_STACK_DATABASE_LOCK
       +0x068 Reserved2        : (null)
       +0x070 PeakHashCollisionListLength : 0
       +0x078 LowerMemoryStart : 0x00000192`2cbd57e0 Void
       +0x080 PreCommitted     : 0 ''
       +0x081 DumpInProgress   : 0 ''
       +0x088 CommitBase       : 0x00000192`2cbb0000 Void
       +0x090 CurrentLowerCommitLimit : 0x00000192`2cbd9000 Void
       +0x098 CurrentUpperCommitLimit : 0x00000192`2e3af000 Void
       +0x0a0 NextFreeLowerMemory : 0x00000192`2cbd8a90  ""
       +0x0a8 NextFreeUpperMemory : 0x00000192`2e3aff80  "???"
       +0x0b0 NumberOfEntriesLookedUp : 0x17f
       +0x0b4 NumberOfEntriesAdded : 0x10
       +0x0b8 EntryIndexArray  : 0x00000192`2e3b0000  -> 0xeeeeeeee`eeeeeeee _RTL_STACK_TRACE_ENTRY
       +0x0c0 NumberOfEntriesAllocated : 0x6c
       +0x0c4 NumberOfEntriesAvailable : 0
       +0x0c8 NumberOfAllocationFailures : 0
       +0x0d0 FreeLists        : [32] _SLIST_HEADER
       +0x2d0 NumberOfBuckets  : 0x254f
       +0x2d8 Buckets          : [1] _RTL_STD_LIST_HEAD
    0:001>