#define
statement maps a base version of the CRT heap functions to the corresponding debug version. If you leave out the #define
statement, the memory leak dump will be less detailed.malloc
and free
functions to their debug versions, _malloc_dbg and _free_dbg, which track memory allocation and deallocation. This mapping occurs only in debug builds, which have _DEBUG
. Release builds use the ordinary malloc
and free
functions._CrtDumpMemoryLeaks
at every exit point. To cause an automatic call to _CrtDumpMemoryLeaks
at each exit point, place a call to _CrtSetDbgFlag
at the beginning of your app with the bit fields shown here:_CrtDumpMemoryLeaks
outputs the memory-leak report to the Debug pane of the Output window. If you use a library, the library might reset the output to another location._CrtSetReportMode
to redirect the report to another location, or back to the Output window as shown here:_CRTDBG_MAP_ALLOC
, _CrtDumpMemoryLeaks displays a memory-leak report that looks like:_CRTDBG_MAP_ALLOC
, the memory-leak report looks like:_CRTDBG_MAP_ALLOC
, the memory-leak report displays:18
in the examplenormal
in the example.0x00780E80
in the example.64 bytes
in the example.new
operator creates either a normal block or a client block, as appropriate for the object being created.malloc
function. If your program allocates memory using the C++ new
operator, however, you may only see the filename and line number where operator new
calls _malloc_dbg
in the memory-leak report. To create a more useful memory-leak report, you can write a macro like the following to report the line that made the allocation:new
operator by using the DBG_NEW
macro in your code. In debug builds, DBG_NEW
uses an overload of global operator new
that takes additional parameters for the block type, file, and line number. The overload of new
calls _malloc_dbg
to record the extra information. The memory-leak reports show the filename and line number where the leaked objects were allocated. Release builds still use the default new
. Here's an example of the technique:_CrtDumpMemoryLeaks
generates a report in the Output window that looks similar to:new
, or any other language keyword._crtBreakAlloc
in the Name column.{,ucrtbased.dll}_crtBreakAlloc
_crtBreakAlloc
will be reported as unidentified._CrtMemState
structure and pass it to the _CrtMemCheckpoint
function._CrtMemCheckpoint
function fills in the structure with a snapshot of the current memory state._CrtMemState
structure, pass the structure to the _ CrtMemDumpStatistics
function:_ CrtMemDumpStatistics
outputs a dump of memory state that looks like:_ CrtMemDifference
to compare the two states:_CrtMemDifference
compares the memory states s1
and s2
and returns a result in (s3
) that is the difference between s1
and s2
._CrtMemCheckpoint
calls at the beginning and end of your app, then using _CrtMemDifference
to compare the results. If _CrtMemDifference
shows a memory leak, you can add more _CrtMemCheckpoint
calls to divide your program using a binary search, until you've isolated the source of the leak._CrtDumpMemoryLeaks
can give false indications of memory leaks if a library marks internal allocations as normal blocks instead of CRT blocks or client blocks. In that case, _CrtDumpMemoryLeaks
is unable to tell the difference between user allocations and internal library allocations. If the global destructors for the library allocations run after the point where you call _CrtDumpMemoryLeaks
, every internal library allocation is reported as a memory leak. Versions of the Standard Template Library earlier than Visual Studio .NET may cause _CrtDumpMemoryLeaks
to report such false positives.