Why might _CrtSetBreakAlloc not cause a breakpoint?

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

It sounds like you might be compiling your app with a non-debug lib, eg. if you use the release version of the lib that should break your app, it will not do that. It's possible that this happens because you use the 3rd party app. It's also possible that the non-debug dll is loaded in place of the debug one at runtime.

Try to see if the right DLL-s are loaded for your app while debugging and also that the app or DLL is actually debugged. (Sometimes you explicitly have to load the dll or exe into the debugger.)

This is all that I can think of without seeing more details about this...

Answer 2

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...