CODEWITHSUNDEEP
memory-leakswindbg
Goblet Machine
Goblet Machine

Reputation: 36

How to trace heap in WinDbg?

I found an article to learn resolve the memory leaking problem,www.codeproject.com/KB/cpp/MemoryLeak.aspx. When I went to step Execute !heap -stat –h xxx,the article told me the result should be like

0:001> !heap -stat -h 00330000
heap @ 00330000
group-by: TOTSIZE max-display: 20
    size     #blocks     total     ( %) (percent of total busy bytes)
    1f64 76c6 - e905f58  (99.99)
    1800 1 - 1800  (0.00)
    824 2 - 1048  (0.00)

But my result like

0:009> !heap -stat -h 00000232ab550000
Walking the heap 00000232ab550000 .
 0: Heap 00000232ab550000
   Flags          00001002 - HEAP_GROWABLE 
   Reserved memory in segments              60 (k)
   Commited memory in segments              12 (k)
   Virtual bytes (correction for large UCR) 60 (k)
   Free space                               4 (k) (1 blocks)
   External fragmentation          34% (1 free blocks)
   Virtual address fragmentation   80% (1 uncommited ranges)
   Virtual blocks  0 - total 0 KBytes
   Lock contention 0
   Segments        1
.
.
.
      Buckets info:
  Size   Blocks  Seg  Empty  Aff    Distribution
------------------------------------------------
    16     409    11      2  1 (6-322,1-11,1-11,1-27,1-27,1-11,0-0,0-0)
    32   22248    58      0  1 (32-21414,3-87,5-129,10-386,5-145,3-87,0-0,0-0)
    48    3767    58      0  1 (14-972,25-2216,4-66,7-231,5-213,3-69,0-0,0-0)
    64    4539    41      0  1 (18-3065,15-818,1-254,1-30,4-328,2-44,0-0,0-0)
    80    2704    32      2  1 (19-2354,9-203,1-11,1-11,1-101,1-24,0-0,0-0)
    96    1846    28      1  1 (17-1531,6-141,1-41,2-29,1-20,1-84,0-0,0-0)
   112    1664    42      3  1 (19-926,18-680,1-8,2-34,1-8,1-8,0-0,0-0)

It looks...so much different.The next step !heap -flt s xxx in the article is also can't run in my WinDbg,looks like version problem(my WinDbg is the newest version). I don't know what I should do next. Can anyone help?

Upvotes: 0

Views: 58

Answers (1)

Neitsa
Neitsa

Reputation: 8176

Not a direct answer to your question but ...(way too long for a comment).

About the differences: the Windows heap internals have changed since the article you linked has been published, there's more info due to that now.

It's honestly pretty hard to hunt a memory leak directly from Windbg if you can't interpret the output of each of the command (and even then, it's still hard when the leak is small and only starts to really show up over long period of times).

What I usually recommend is:

  • UMDH:
    • Pros: it's basicallly a wraper around the debugging engine (so, the same as Windbg) but it does all the heavy lifting for you.
    • Cons: you need to do multiple traces and interpret the results by yourself.
  • Perfmon
    • Pros: Relatively easy to use.
    • Cons: may be still hard to interpret in some cases.

If you have the source code, and it's C or C++ and specifically targeting Windows.

  • The first thing I'd do is to use the CRT library in debug mode to diagnose mem leaks.
    • It's the simplest solution. Easy to use and you can find the culprit easily (unless you program is leaking from other places...)
    • It requires a bit of changes to the source, but not that much (in most cases).

If your program does not performs calls to the Windows API or use Windows libraries (i.e. it can be cross compiled), then you can use Asan (a.k.a. "Address Sanitizer") and more precisely LSan (Leak Sanitizer; part of Asan):

See related question here for example, using either MSYS2 or WSL to "cross-compile" on Windows.

Note that the Asan that comes with Visual Studio does not have Leak detection capabilities at the time of this writing.

Upvotes: 0

Related Questions