The failure to deallocate previously allocated memory is known as a memory leak. A memory leak is one of those hard to detect bugs, and it may cause unpredictable behavior in your program.

To allocate memory on the heap, you call new. To deallocate, you call delete. If a memory object has not been deallocated, a memory leak dump for a leak can be seen in the Output window in the end of a VC++ debug session. The dump is as follows:

{N} normal block at 0x00421C90, 12 bytes long. Data: <            > CD CD CD CD CD CD CD CD CD CD CD CD

In which N is a unique allocation request number that represents the sequence number of an allocation of the “leaked” object.

This dump is not very helpful. To improve this dump, you can insert additional code that extends the memory leak dump with a file name and line number within this file, where the “leaked” allocation has occurred. This capability began with MFC 4.0 with the addition of the Standard C++ library. The MFC and C run-time library use the same debug heap and memory allocator. Here’s the additional code:

	#ifdef _DEBUG                              //for debug builds only		#define new DEBUG_NEW		#undef THIS_FILEstatic char THIS_FILE[] = __FILE__;#endif

The __FILE__ is an ANSI C macro defined by compiler. The preprocessor fills the macro with a string, whose content is the current file name, surrounded by double quotation marks.

An improved memory leak dump is as follows:

PathFilename (LineNumber): {N} normal block at 0x00421C90, 12 bytes long.Data: <            > CD CD CD CD CD CD CD CD CD CD CD CD

MS VC++ AppWizard and ClassWizard place the additional code, shown above, in the .CPP files that they create by default. The filename that is shown above will be a .CPP file name or .H file that has a template class code in them where the N-th object was allocated.

Having the location where the “leaked” N-th object was allocated is not enough. You need to know when the memory leak occurred, because the line with allocation code can be executed hundreds of times. This is why setting a simple breakpoint on this line may not be adequate.

The solution is to break an execution of the debugged program only at the moment when the “leaked” N-th object is allocated. To do this, stop the execution of your program in the debugger just after the beginning. Type in _crtBreakAlloc in the Name column of the Watch window and press the Enter key. If you use the /MDd compiler option, type in {,,msvcrtd.dll}*__p__crtBreakAlloc() in the Name column. Replace a number in the Value column with the value of N. Continue to debug using the same execution path, and the debugger will stop the program when the “leaked” N-th object will be allocated.