When you run your (unmanaged/C++) application in debugger, you see at the end a report of memory leaks (if any are detected). Something like this:

Detected memory leaks!
Dumping objects ->
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(141) : {381} normal block at 0x001FFC30, 54 bytes long.
Data: < x > 0C 00 B9 78 12 00 00 00 12 00 00 00 01 00 00 00
d:\marius\vc++\memoryleakstest\memoryleakstestdlg.cpp(163) : {380} normal block at 0x001FFBF0, 4 bytes long.
Data: <@ > 40 FC 1F 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\thrdcore.cpp(306) : {374} client block at 0x001FFA38, subtype c0, 68 bytes long.
a CWinThread object at $001FFA38, 68 bytes long
Object dump complete.

Some of them can be fixed immediately, because when you double click on them Visual Studio will take you to the line where the allocation was made. Some of them are harder to spot, because Visual Studio is not able to do the same. Question is how do you find the source of those allocations? Luckily, there is this global variable called _crtBreakAlloc, that can be used to force the debugger to stop the execution when a certain block is allocated.

In order to use that, you should follow several steps:

  • First, you have to find a reproducible sequence that produces the same memory allocation number. When memory blocks are allocated, they are identified with a number, called allocation number. This number is reported by Visual Studio in brackets when it lists the memory leaks (e.g. {381}).
  • Second, you have to put a breakpoint somewhere in your program to force a stop at the beginning of the execution. That means you could use function main(), your CWinApp derived class constructor, function InitInstance() or other, depending on your application type and how early in the execution of the program the block that leaks is allocated. The smaller the allocation number is, the earlier in the execution the allocation occurs.
  • Run your program in debugger.
  • When the program stops (at the first breakpoint) open the Watch window and add the following expression: {,,msvcr90d.dll}_crtBreakAlloc in the Name column. In the Value column (which by default should have the value -1) write the allocation number. Take notice that msvcr90d.dll (which is the DLL that contains the C++ runtime library) is specific to Visual Studio 2008 (and is the debug version). If you use another version of Visual Studio, you have to use the appropriate DLL.
  • Continue debugging.
  • When the block identified by the allocation number set in the Watch window is allocated, the debugger will stop the execution and jump to a line from dbgheap.c.

    In order to see the line in your code that triggered the allocation, open the Call Stack window and find, from top down, the first function from your own code.

    That will lead you to the source of the memory leak.

To read more about this topic see:
How to: Set Breakpoints on a Memory Allocation Number
How to use _crtBreakAlloc to debug a memory allocation

, Hits for this post: 25856 .
Trackback

6 comments untill now

  1. Gravatar

    The best way to find memory leaks is to use Deleaker ( http://deleaker.com/ )

  2. Gravatar

    Sure, but my post was about finding the source of memory leaks detected by Visual Studio.

  3. Gravatar

    This is a tricky solution, thanks for the idea!

  4. Gravatar

    Indeed, using Deleaker can quickly trace a resource leak.

  5. Gravatar
    Olga Yurina @ 2014-07-14 15:35

    I try to use the method you describe but when I add {,,msvcr90d.dll}_crtBreakAlloc in the name column, value become Module “msvcr90d.dll” not found. How can I add this module? Thank you

  6. Gravatar
    Olga Yurina @ 2014-07-14 15:43

    I am using VS 2013 pro, I have redistributable packages from 2008-2013.

Add your comment now