Question

I’m using Visual CRT’s memory leak detection routines from <crtdbg.h>; when I call _CrtDumpMemoryLeaks one allocation is reported consistently on every invocation of the program:

{133} normal block at 0x04F85628, 56 bytes long.
 Data: <                > B0 81 F8 04 B0 81 F8 04 B0 81 F8 04 CD CD CD CD 

The address varies but {133} is always the same.

According to MSDN’s instructions on How to set breakpoints on memory allocation number, I should be able to set a breakpoint on the 133rd allocation with this call:

_CrtSetBreakAlloc(133);

and I can also verify in the watch window that {,,msvcr90d.dll}_crtBreakAlloc is indeed set to 133. After the program exits, the leak report still lists #133 (along with some higher numbers), but no breakpoint occurs. Why might this be and how do I get the breakpoint to occur?

Potentially relevant info:

1. VS2008, using the "multi-threaded debug DLL" CRT
2. My code is a DLL that gets loaded by a third-party product
3. "Normal" breakpoints work just fine; stepping through works fine; __asm int 3 works fine too.
4. No other value for _crtBreakAlloc causes a breakpoint either (not the ones I tried anyway)
5. #133 is the lowest number in the leak report

Answer 1

Major forehead slapping… One “obvious” reason is if allocation #133 occurred before the breakpoint was set…

It’s just that the first leak turns out to occur before my DLL gets invoked. In fact it’s not necessarily a leak, because I call _CrtDumpMemoryLeaks when the DLL is unloaded – not when the parent application is done deinitializing.

As for “Potentially relevant info #4” in my original question – well I did try a few values, but somehow none were higher than 133…