Required Header Includes

To use the CRT debug heap functions, include headers in strict order:

#define _CRTDBG_MAP_ALLOC
#include <stdlib.h>
#include <crtdbg.h>

The _CRTDBG_MAP_ALLOC macro must be included without fail. Omitting this macro causes the memory leak report to miss critical details, including the source file name and line number where the allocation occurred.

Build Configuration

This technique requires a Debug build. In Release mode, the behavior may differ significantly—one configuration might report leaks while the other does not. This discrepancy can be useful when verifying whether the Debug build produces false positives.

When building with LiteServer in Debug mode, occasional issues may arise. In such cases, the debug heap can serve as a validation tool for checking whether Memcheck reports are accurate. Use conditional breakpoints on malloc calls (filtering by allocation size) and place breakpoints at the reported addresses.

Generating Memory Leak Reports

Automatic Reporting at Exit

Rather then manual inserting _CrtDumpMemoryLeaks() at every exit point, call this function once at application startup:

_CrtSetDbgFlag(_CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF);

This instructs the CRT to automatically dump memory leaks whenever the application exits, regardless of how many exit paths exist.

Manual Reporting

To manually output the leak report before application exit:

_CrtDumpMemoryLeaks();

Note that global and static objects not yet destroyed at exit will appear in the report. This does not constitute a false positive—the debug heap correctly identifies allocations that were never freed.

Redirecting Report Output

By default, memory leak reports appear in the Visual Studio Output window. To redirect output to an alternate location, use _CrtSetReportMode().

Interpreting Report Output

A typical memory leak report looks like this:

Detected memory leaks!
Dumping objects ->

c:\users\username\documents\projects\leaktest\leaktest.cpp(20) : {18}
normal block at 0x00780E80, 64 bytes long.
Data: <                > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD

Object dump complete.

Key elements:

• {18} indicates the allocation sequence number
• 64 bytes long represents the actual block size, which differs from the requested size due to heap headers and footers
• CD CD CD CD... shows the fill pattern used to detect uninitialized or overwritten memory

Obtaining Line Numbers for new Operators

The standard CRT debug heap does not track line information for C++ new operators—it only captures the address from the new call itself. To get accurate line numbers, replace all new call with a custom macro:

#ifdef _DEBUG
    #define DBG_NEW new ( _NORMAL_BLOCK , __FILE__ , __LINE__ )
#else
    #define DBG_NEW new
#endif

This macro expands new to include file name and line number parameters, enabling the debug heap to report the exact allocation source. To track custom allocation types instead, substitute _CLIENT_BLOCK for _NORMAL_BLOCK.

When dealing with third-party libraries or large codebases where replacing all new operators is impractical, this approach has limitations.

Breakpoint on Specific Allocations

Without stack trace information, identifying the call chain for leaks in deep nested functions can be challenging. The CRT debug heap supports breaking on specific allocations by setting _crtBreakAlloc.

First, add _crtBreakAlloc to the Watch window after breaking at the application entry point. For projects using /MD runtime library, specify the external symbol:

{,,ucrtbased.dll}_crtBreakAlloc

The default value is -1. Change it to the allocation sequence number shown in the leak report (such as {18}) to break when that specific allocation occurs.

Alternatively, set the breakpoint directly in code:

_crtBreakAlloc = 18;
// or
_CrtSetBreakAlloc(18);

Important: When re-running the debugger to investigate, ensure the allocation conditions remain identical to the first run where the sequence number was captured.

Practical Example

Test Code

#include <memory>

std::tr1::shared_ptr<int> g_smartPtr;

void ProcessData()
{
    g_smartPtr.reset(new int(0x88));
    
    int* rawPtr = new int(0xCC);
    void* buffer = malloc(sizeof(int));
}

Leak Report Output

Detected memory leaks!
Dumping objects ->

d:\codes\vs2010\test\detectmemleak\console\test.cpp(14) : {65}
normal block at 0x007B18A8, 4 bytes long.
Data: <    > CD CD CD CD

{64} normal block at 0x007B4F90, 4 bytes long.
Data: <    > CC 00 00 00

Object dump complete.

The highlighted section shows the new allocation without line number information, illustrating why the DBG_NEW macro is necessary for accurate leak source identification.