This topic applies to:
Visual Studio Edition
Visual Basic
C#
C++
J#
Express
No
Native
Standard
Pro/Team
The dialog boxes and menu commands you see might differ from those described in Help depending on your active settings or edition. To change your settings, choose Import and Export Settings on the Tools menu. For more information, see Visual Studio Settings.
The file name and line number in the memory leak report tell you where leaked memory is allocated, but knowing where the memory is allocated is not always sufficient to identify the problem. Often an allocation will be called many times during a run of the program, but it may leak memory only on certain calls. To identify the problem, you need to know not only where the leaked memory is allocated but also the conditions under which the leak occurs. The piece of information that allows you to do this is the memory allocation number. This is the number that appears in braces after the filename and line number when those are displayed. For example, in the following output, the memory allocation number is 18. It means that the leaked memory is the 18th block of memory allocated in your program.
Detected memory leaks! Dumping objects -> C:\PROGRAM FILES\VISUAL STUDIO\MyProjects\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.
The CRT library counts all memory blocks allocated during a run of the program, including memory allocated by the CRT library itself or by other libraries such as MFC. Therefore, an object with allocation number N will be the Nth object allocated in your program but may not be the Nth object allocated by your code. (In most cases, it will not be.)
You can use the allocation number to set a breakpoint at the location where memory is allocated. To do this, set a location breakpoint near the start of your program. When your program breaks at that point, you can set such a memory-allocation breakpoint from the QuickWatch dialog box or the Watch window.
In the Watch window, type the following expression in the Name column:
_crtBreakAlloc
If you are using the multithreaded DLL version of the CRT library (the /MD option), include the context operator, as shown here:
{,,msvcr71d.dll}_crtBreakAlloc
Press RETURN.
The debugger evaluates the call and places the result in the Value column. This value will be –1 if you have not set any breakpoints on memory allocations.
Replace the value in the Value column with the allocation number of the memory allocation where you want to break. For example, 18 to break at the allocation shown in the output above.
After you set breakpoints on the memory allocations you are interested in, you can continue debugging. Be careful to run the program under the same conditions as the previous run so that the allocation order does not change. When your program breaks at the specified memory allocation, you can look at the Call Stack window and other debugger information to determine the conditions under which the memory was allocated. If necessary, you can continue execution of the program from that point to see what happens to the object and perhaps determine why it is not properly deallocated.
Setting a data breakpoint on the object may be helpful. For more information, see How to: Set a Data Breakpoint (Native Only).
Although it is usually easier to set memory-allocation breakpoints in the debugger, you can set them in your code, if you prefer.
Add a line like this (for the 18th memory allocation):
_crtBreakAlloc = 18;
Alternately, you can use the _CrtSetBreakAlloc function, which has the same effect:
_CrtSetBreakAlloc(18);