Detecting memory leaks with Windbg

From time to time I like to use Windbg to look into memory leaks, if only to get a hang of and familiarize myself with the !heap extension. Along the way I ran into an option that I never noticed before: -l. The docs say:

======================
The !heap -l command detects leaked heap blocks. It uses a garbage collector algorithm to detect all busy blocks from the heaps that are not referenced anywhere in the process address space. For huge applications, it can take a few minutes to complete. This command is only available in Windows XP and later versions of Windows.

If I were to break into the debugger at random points (of course, I am supposed to have used: gflags.exe /i +ust MyApp.exe prior to doing all this) and run !heap -l, I see a whole bunch of callstacks leading up to some memory allocations. Do I take it to mean all these are allocations that were never freed? IOW, I am not sure I understand the “busy blocks not referenced anywhere in the process space” comment.

This command searches the address of all the busy blocks in the entire
process address space. If the address is not found then it is shown as
“leaking”. I think “busy” blocks also include freed allocations present in
the front-end allocator, so this may not necessarily be a leak. If it is
your code check from code review if the stacks shown in !heap -l are
actually leaking.

On Thu, Nov 2, 2017 at 2:46 AM, xxxxx@gmail.com
wrote:

> From time to time I like to use Windbg to look into memory leaks, if only
> to get a hang of and familiarize myself with the !heap extension. Along
> the way I ran into an option that I never noticed before: -l. The docs say:
>
> ======================
> The !heap -l command detects leaked heap blocks. It uses a garbage
> collector algorithm to detect all busy blocks from the heaps that are not
> referenced anywhere in the process address space. For huge applications, it
> can take a few minutes to complete. This command is only available in
> Windows XP and later versions of Windows.
> ======================
>
> If I were to break into the debugger at random points (of course, I am
> supposed to have used: gflags.exe /i +ust MyApp.exe prior to doing all
> this) and run !heap -l, I see a whole bunch of callstacks leading up to
> some memory allocations. Do I take it to mean all these are allocations
> that were never freed? IOW, I am not sure I understand the “busy blocks not
> referenced anywhere in the process space” comment.
>
>
> —
> WINDBG is sponsored by OSR
>
> OSR is hiring!! Info at http://www.osr.com/careers
>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer&gt;
></http:>