This information is surprisingly scarce on the Internet. I should have realized earlier that the world has simply moved on to more modern languages than those who tax us to deal with mundane things like memory leaks.
Anyway, for those who’re still stuck, this should be your savior. This is almost as good as Valgrind on nix
Minimal example
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
| #include <crtdbg.h>
void leak()
{
::operator new(1000);
new double[1000];
}
int main()
{
_CrtSetDbgFlag(_CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF);
leak();
return 0;
} |
Running the above code will get you something like this in the Debug output:
Detected memory leaks!
Dumping objects ->
{67} normal block at 0x00573FC8, 8000 bytes long.
Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD
{66} normal block at 0x005713E8, 1000 bytes long.
Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD
Object dump complete.
This is nice and good, but it isn’t very useful since we (pretend) don’t know where the leak came from!
And then WinDBG comes in
(Obviously, add WinDBG to your PATH first)
First, we’ll turn on heap stack tracing for our program. gflags.exe needs to be run with elevated privileges:
1
| > gflags /i leak.exe +ust |
Now we’re ready to go!
At the debug output in WinDBG, we’ll see our leak report:
Detected memory leaks!
Dumping objects ->
{80} normal block at 0x003B4378, 8000 bytes long.
Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD
{79} normal block at 0x003B3F50, 1000 bytes long.
Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD
Object dump complete.
At WinDBG, we can trace down the originating functions
000:0> !heap -p -a 0x003B4378
address 004b4378 found in
_HEAP @ 4b0000
HEAP_ENTRY Size Prev Flags UserPtr UserSize - state
004b4340 03f0 0000 [00] 004b4358 01f64 - (busy)
Trace: cfba8
7753dd4d ntdll!RtlAllocateHeap+0x00000274
6fa87743 MSVCR100D!_heap_alloc_base+0x00000053
6fa95d8c MSVCR100D!_heap_alloc_dbg_impl+0x000001fc
6fa95b2f MSVCR100D!_nh_malloc_dbg_impl+0x0000001f
6fa95adc MSVCR100D!_nh_malloc_dbg+0x0000002c
6fa9906b MSVCR100D!malloc+0x0000001b
6fa871b1 MSVCR100D!operator new+0x00000011
6fa872ef MSVCR100D!operator new[]+0x0000000f
dc13d5 leak!leak+0x00000035
dc1447 leak!main+0x00000037
dc19df leak!__tmainCRTStartup+0x000001bf
dc180f leak!mainCRTStartup+0x0000000f
75f43677 kernel32!BaseThreadInitThunk+0x0000000e
774f9d42 ntdll!__RtlUserThreadStart+0x00000070
774f9d15 ntdll!_RtlUserThreadStart+0x0000001b
There you go! The highlighted line above is the culprit. For those unfamiliar with WinDBG, here’s a little more hand holding: Click on the source code view, Ctrl+G and then type leak+0x35.
Remember to turn gflags off afterwards. The gflags is a registry and won’t clear even if you delete the file itself.
1
| > gflags /i leak.exe -ust |
32/64 bit
To debug 32 bit applications in a 64 bit system, you need to use the 32 bit version of WinDBG, which is not installed by default. You can find dbg_x86_*.msi somewhere in your “Microsoft SDKs” installation directory.
More advanced usage
Heap debugging is not restricted to detecting leaks. If you find your application allocating a lot of memory in some places, you can easily trace down where they come from with WinDBG and the !heap extension. This CodeProject article describes how to do just that in depth.
However, for doing that, I find a more modern and less intrusive way to be using XPerf tool. That combined with WinDBG and you’ve got a debugging power-house. (Resources on how to do it is extremely scarce. If you thought this WinDBG technique is obscure, you ain’t seen nothing :p I may write an post about that some time later when I feel like it.)
Wrong way of doing it
MSDN suggests something like this
1
2
3
4
5
6
| #define _CRTDBG_MAP_ALLOC
#include <stdlib.h>
#include <crtdbg.h>
// At the end of your program
_CrtDumpMemoryLeaks(); |
This solution is inadequate for a couple of reasons:
- It only lists source code location for
malloc. What’s the point?
- Calling
_CrtDumpMemoryLeaks() at the end of main() would mistakenly report memory allocated by static objects as leaks.
The only good thing about it is that you don’t need to leave your comfort zone of Visual Studio (that’s probably the entire programmer life for many people, unfortunately).
Some other good resources
Probably this will serve as a gentler introduction.