我正在使用来自<crtdbg.h>的Visual CRT的内存泄漏检测例程;当我调用_CrtDumpMemoryLeaks时，在每次调用程序时都会一致地报告一个分配：
{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
地址有所不同，但{133}始终相同。
根据MSDN关于How to set breakpoints on memory allocation number的说明，我应该可以通过此调用在第133次分配上设置断点：
_CrtSetBreakAlloc(133);
我还可以在监视窗口中验证{,,msvcr90d.dll}_crtBreakAlloc确实设置为133.程序退出后，泄漏报告仍会列出＃133（以及一些更高的数字），但不会发生断点。为什么会这样，我如何让断点发生？
潜在相关信息：
__asm int 3也可以。_crtBreakAlloc没有其他值也会导致断点（不是我试过的那个）答案 0 :(得分：9)
主要额头拍打......一个“显而易见”的原因是，在设置断点之前，如果分配＃133发生了 ...
只是在我的DLL被调用之前发生了第一次泄漏。事实上，它不一定是泄漏，因为我在卸载DLL时调用_CrtDumpMemoryLeaks - 而不是在父应用程序完成取消初始化时。
至于我原来的问题中的“潜在相关信息＃4” - 我确实尝试了一些值，但不知何故没有高于133 ......
答案 1 :(得分：0)
听起来您可能正在使用非调试库编译您的应用程序，例如。如果您使用应该破坏您的应用程序的lib的发行版本，它将不会这样做。这可能是因为您使用第三方应用程序。也可能在运行时加载非调试dll代替调试版。
尝试在调试时查看是否为您的应用加载了正确的DLL-s以及实际调试了应用程序或DLL。 （有时您必须明确地将dll或exe加载到调试器中。）
这是我能想到的所有内容，而没有看到更多关于此的细节...