I'm a big fan of the Windows instrumented debug heap, but today I want to talk about the CRT support, which can sometimes provide a bit more context.
You can make a build-time decision to use the CRT debug heap. A nice thing about these is that the function calls to the debug heap disappear when _DEBUG
is not defined, which is presumably how your release build works.
This adds a debug allocator on top of the release allocator, and enables a bunch of new functionality. The most useful ones are these:
NULL
)._CRTDBG_MODE_DEBUG
(debugger window) and _CRTDBG_MODE_FILE
(a file or stream).CreateFile
), or one of _CRTDBG_FILE_STDERR
or _CRTDBG_FILE_STDOUT
._CRTDBG_CHECK_ALWAYS_DF
flag with _CrtSetDbgFlag to have this checked on every memory operation (but calling it by hand may help you narrow down the offending code). Still, handy to know about.Here's how you would put the above functions together.
_CrtMemState startState{};
_CrtMemCheckpoint(&startState);
// Allocate things and presumably deallocate them again!
// Set the memory dump to print to `stderr` and write objects we've allocated and not freed since starting.
_CrtSetReportMode(_CRT_WARN, _CRTDBG_MODE_FILE);
_CrtSetReportFile(_CRT_WARN, _CRTDBG_FILE_STDERR);
_CrtMemDumpAllObjectsSince(&startState);
For the official doc and step-by-step instructions, see Find memory leaks with the CRT library.
Happy leak tracking!