Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results
Before Posting...
Please check out the Community Guidelines in the Announcements and Administration Category.More Info on Driver Writing and Debugging
The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.
Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/
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.
======================
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.
| Upcoming OSR Seminars | ||
|---|---|---|
| OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead! | Kernel Debugging | 30 Mar 2020 | OSR Seminar Space |
| Developing Minifilters | 15 Jun 2020 | LIVE ONLINE |
| Writing WDF Drivers | 22 June 2020 | LIVE ONLINE |
| Internals & Software Drivers | 28 Sept 2020 | Dulles, VA |
Comments
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, [email protected]
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
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer>
>