C++ 为什么WinDbg总是返回相同的“信息”；！堆-s"；当我测试内存泄漏程序时？

我编写了一个程序来学习WinDbg的内存泄漏检测。但是当我使用“！heap-s”命令时，在我运行内存泄漏程序很长一段时间后，它总是返回相同的信息（见下文）

Microsoft (R) Windows Debugger Version 6.12.0002.633 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.

*** wait with pending attach
Symbol search path is: srv*c:\symbols*http://msdl.microsoft.com/download/symbols;C:\image
Executable search path is: srv*c:\symbols*http://msdl.microsoft.com/download/symbols;C:\image
ModLoad: 00000000`00400000 00000000`0041a000   C:\image\memory.exe
ModLoad: 00000000`76d40000 00000000`76ee9000   C:\Windows\SYSTEM32\ntdll.dll
ModLoad: 00000000`76f20000 00000000`770a0000   ntdll.dll
ModLoad: 00000000`001c0000 00000000`0022e000   C:\Windows\system32\verifier.dll
ModLoad: 00000000`731c0000 00000000`731ff000   C:\Windows\SYSTEM32\wow64.dll
ModLoad: 00000000`73160000 00000000`731bc000   C:\Windows\SYSTEM32\wow64win.dll
ModLoad: 00000000`74850000 00000000`74858000   C:\Windows\SYSTEM32\wow64cpu.dll
ModLoad: 00000000`6f7f0000 00000000`6f850000   VERIFIER.dll
ModLoad: 00000000`72a20000 00000000`72a49000   vrfcore.dll
ModLoad: 00000000`6f870000 00000000`6f8ac000   VFBASICS.dll
ModLoad: 00000000`76380000 00000000`76490000   KERNEL32.dll
ModLoad: 00000000`76490000 00000000`764d7000   KERNELBASE.dll
ModLoad: 00000000`10200000 00000000`10320000   MSVCR80D.dll
ModLoad: 00000000`74e20000 00000000`74ecc000   msvcrt.dll
(44e0.4748): Break instruction exception - code 80000003 (first chance)
ntdll!DbgBreakPoint:
00000000`76d90590 cc              int     3
0:001> !heap -s
LFH Key                   : 0x0000008a68294636
Termination on corruption : ENABLED
          Heap     Flags   Reserv  Commit  Virt   Free  List   UCR  Virt  Lock  Fast 
                            (k)     (k)    (k)     (k) length      blocks cont. heap 
-------------------------------------------------------------------------------------
0000000000320000 00000002     512      8    512      3     1     1    0      0      
0000000003d80000 00001002     512      8    512      3     1     1    0      0      
0000000000310000 00008000      64      4     64      1     1     1    0      0      
00000000003a0000 00008000      64     64     64     61     1     1    0      0      
-------------------------------------------------------------------------------------
0:001> g
(44e0.1550): Break instruction exception - code 80000003 (first chance)
ntdll!DbgBreakPoint:
00000000`76d90590 cc              int     3
0:001> g
(44e0.3b04): Break instruction exception - code 80000003 (first chance)
ntdll!DbgBreakPoint:
00000000`76d90590 cc              int     3
0:001> !heap -s
LFH Key                   : 0x0000008a68294636
Termination on corruption : ENABLED
          Heap     Flags   Reserv  Commit  Virt   Free  List   UCR  Virt  Lock  Fast 
                            (k)     (k)    (k)     (k) length      blocks cont. heap 
-------------------------------------------------------------------------------------
0000000000320000 00000002     512      8    512      3     1     1    0      0      
0000000003d80000 00001002     512      8    512      3     1     1    0      0      
0000000000310000 00008000      64      4     64      1     1     1    0      0      
00000000003a0000 00008000      64     64     64     61     1     1    0      0      
-------------------------------------------------------------------------------------

程序代码如下所示：

#include <windows.h>

void AllocateMemory() 
{ 

    int* a = new int[2000]; 
    ZeroMemory(a, 8000); 
    Sleep(1); 
}

int main(int argc, char* argv[])
{   
while(1) 
{ 
    AllocateMemory(); 
} 
return 0; 
} 

C:\Program Files\Debugging Tools for Windows (x64)>gflags.exe -i memory.exe +ust

---

我只是稍微修改了代码，以帮助我计算迭代次数，并在6.12中运行了它并使用了！heap-l检测泄漏windbg似乎报告正确，请查看busyblock的计数

#include <windows.h>
int count =0;
void AllocateMemory() {
    int* a = new int[2000]; 
    ZeroMemory(a, 8000); 
    Sleep(1);
    count++;
}
int main(void) {   
while(1) { 
    AllocateMemory(); 
} 
return 0; 
} 

---

我在windows server 2008和windows 7上都试过了，代码是用vs2005编译的，我使用的是测试程序的调试版本。您是否正在运行泄漏程序的发行版或调试版本？如果已发布，则优化编译器可能已优化了对new和ZeroMemory的调用，因为局部变量a未在任何地方使用。6.12.0002.633相当旧。您可能还想使用版本6.2.9200或6.3.9600检查这是否是WinDbg中的一个bug。请参阅我的@ThomasW列表。尝试了Microsoft（R）Windows调试器版本6.3.9600.17298 AMD64，仍然得到相同的结果：（32位版本windbg也不起作用。）：（：（为什么我使用该命令时。）printf“%y\n”、@eip总是得到“ntdll！DbgBreakPoint（77a000c）”。

！heap-l

的输出总是检测不到泄漏。

0:001>。printf“%y\n”、@eip ntdll！DbgBreakPoint（77a000c）0:001>g（1bf4.1410）：中断指令异常-代码80000003（第一次机会）..//ommited.0:001>计数；！heap-l int 28567在内存中搜索潜在的无法访问的忙块。heap 03c50000 heap 05150000 heap 002400000 heap 05410000扫描VM…扫描来自12个忙块（0 MB）的引用…未检测到任何潜在的无法访问的块。

打印是为了显示我在main（）函数的开头，这意味着我在main（）中设置断点后使用了g Go应用程序已突破我的断点，在运行命令之前我已清除了所有断点。printf是一种神奇的药丸，它只是一个printf，当您执行时，它会打印出您的eip所在的符号，您似乎启用了一些第一次执行：（您是否修改了任何事件筛选器？int3 first chance不应显示iirc尝试运行。sxcmds并尝试重置所有sx*筛选器12个忙块不会显示任何无法访问的代码您是否使用了“打开可执行文件…”菜单？然而，我使用这个菜单，仍然不起作用。它似乎无法使断点int main。顺便问一下，“！heap-l”命令是否需要可疑程序运行一些时间，或者只是用它来确定哪个块内存泄漏？是的，打开可执行文件->选择你的exe->g->ctrl+break->堆-l->g->ctrl+break->堆-l，这是2次迭代我还没有解决我的问题。无论如何，谢谢你的帮助。

0:000> .printf "%y\n" ,@eip
leakmem!main (00401050)
0:000> ?? count ; !heap -l
int 0n0
Scanning references from 97 busy blocks (0 MBytes) ...No potential unreachable blocks were detected.
0:000> bp @eip+3 0n5
0:000> g
Breakpoint 0 hit
0:000> ?? count ; !heap -l
int 0n4
Scanning references from 101 busy blocks (0 MBytes) ...No potential unreachable blocks were detected.
0:000> bp 401053 0n15
breakpoint 0 redefined
0:000> bl
 0 e 00401053     000f (000f)  0:**** leakmem!main+0x3
0:000> g
Breakpoint 0 hit
0:000> ?? count ; !heap -l
int 0n19
Scanning references from 117 busy blocks (0 MBytes) ...
Entry     User      Heap      Segment       Size  PrevSize  Unused    Flags
-----------------------------------------------------------------------------
00421f98  00421fa0  00030000  00410000      1f58      1f58        18  busy extra
 fill
00425e48  00425e50  00030000  00410000      1f58      1f58        18  busy extra
 fill
00435908  00435910  00030000  00420000      1f58      1f58        18  busy extra
 fill
00437860  00437868  00030000  00420000      1f58      1f58        18  busy extra
 fill
004397b8  004397c0  00030000  00420000      1f58      1f58        18  busy extra
 fill
5 potential unreachable blocks were detected.
0:000>