为什么堆堆不能按照预期的方式工作？

我的WinDBG版本是10.0.10240.9 AMD64，而随便调试一些本地内存转储时，我意识到我的！堆命令行为不同于描述，我无法找出原因。为什么堆堆不能按照预期的方式工作？

有很多资源提!heap -s：

当我执行!heap -s

我得到这个截断的列表：

0:000> !heap -s 

************************************************************************************************************************ 
               NT HEAP STATS BELOW 
************************************************************************************************************************ 
LFH Key     : 0x000000c42ceaf6ca 
Termination on corruption : ENABLED 
      Heap  Flags Reserv Commit Virt Free List UCR Virt Lock Fast 
          (k)  (k) (k)  (k) length  blocks cont. heap 
------------------------------------------------------------------------------------- 
Virtual block: 0000000003d40000 - 0000000003d40000 (size 0000000000000000) 
... many more virtual blocks 
0000000000b90000 00000002 3237576 3220948 3237576 20007 1749 204 359  0 LFH 
0000000000010000 00008000  64  8  64  5  1  1 0  0  
... more heaps 
-------------------------------------------------------------------------------------

好的，b90000看起来很大，但与上面的那些文档相反，并且与上面的那些文档相反，我无法获得这个堆的信息，这些命令中的每一个都产生与上面所看到的完全相同的输出（就好像我不会在-s之后指定任何东西）：

!heap -s b90000 
!heap -s -h b90000 
!heap -s 1

我得到的虚拟块的负荷和指定一个所有堆，而不是单一的转储。

任何人都有同样的问题？

来源

2016-12-02 Samuel

从内幕预览版SDK尝试最新的WinDBG的建设14965：https：//开头software-download.microsoft.com/pr/Windows_InsiderPreview_SDK_en-us_14965.iso?t=88bf7144-c840-4a35-9761-5776e3465d5b&e=14807791 43＆h = 43050afd20d55e08e2c5928966297243 – magicandre1981

为什么问题很难回答......它也在10.0.10075.9,10.0.10586.567,10.0.14321.1024中被破坏。它适用于6.3.9600.17298。 –

@ magicandre1981官方WDK版本14321.1024确实有效，但只能使用'-h heap'语法。 – Samuel

我的 “Windows调试版本10.0.10586.567 AMD64” 表现得像你的，但 “微软（R）Windows调试版本6.3.9600.16384 AMD64”我有： C：\ Program Files文件\的Windows套件\ 8.1 \调试器\ x64的

0:000> !heap -s -h 0000000000220000 
Walking the heap 0000000000220000 ..................Virtual block: 0000000015f20000 - 0000000015f20000 (size 0000000000000000) 
Virtual block: 000000001b2e0000 - 000000001b2e0000 (size 0000000000000000) 
Virtual block: 000000001f1e0000 - 000000001f1e0000 (size 0000000000000000) 
Virtual block: 0000000023c10000 - 0000000023c10000 (size 0000000000000000) 
Virtual block: 000000001c060000 - 000000001c060000 (size 0000000000000000) 
Virtual block: 000000001ddc0000 - 000000001ddc0000 (size 0000000000000000) 

0: Heap 0000000000220000 
    Flags   00000002 - HEAP_GROWABLE 
    Reserved memory in segments    226880 (k) 
    Commited memory in segments    218204 (k) 
    Virtual bytes (correction for large UCR) 218740 (k) 
    Free space        12633 (k) (268 blocks) 
    External fragmentation   5% (268 free blocks) 
    Virtual address fragmentation 0% (30 uncommited ranges) 
    Virtual blocks 6 - total 0 KBytes 
    Lock contention 0 
    Segments  1 

    Low fragmentation heap 00000000002291e0 
     Lock contention  0 
     Metadata usage  90112 bytes 
     Statistics: 
      Segments created  993977 
      Segments deleted  992639 
      Segments reused   0 
     Block cache: 
     3:   1024 bytes ( 17,  0) 
     4:   2048 bytes ( 42,  0) 
     5:   4096 bytes ( 114,  0) 
     6:   8192 bytes ( 231,  2) 
     7:  16384 bytes ( 129,  9) 
     8:  32768 bytes ( 128, 11) 
     9:  65536 bytes ( 265, 58) 
     10:  131072 bytes ( 357,  8) 
     11:  262144 bytes ( 192, 49) 

     Buckets info: 
    Size Blocks Seg Empty Aff Distribution 
------------------------------------------------ 
------------------------------------------------ 

        Default heap Front heap  Unused bytes 
    Range (bytes)  Busy Free Busy Free  Total Average 
------------------------------------------------------------------ 
    0 - 1024  577 140 1035286 11608 10563036  10 
    1024 - 2048  173  3 586 374  27779  36 
    2048 - 3072  17  19  47 224  1605  25 
    3072 - 4096  20  12  1 126  348  16 
    4096 - 5120  35  3  1  30  677  18 
    5120 - 6144  2  8  0  0   33  16 
    6144 - 7168  5  9  0  0   56  11 
    7168 - 8192  0  11  0  0   0  0 
    8192 - 9216  14  0  0  15  236  16 
    9216 - 10240  1  0  0  0   8  8 
12288 - 13312  1  0  0  0   17  17 
14336 - 15360  1  0  0  18   1  1 
15360 - 16384  1  0  0  0   32  32 
16384 - 17408  10  0  0  0  160  16 
22528 - 23552  1  0  0  0   9  9 
23552 - 24576  2  0  0  0   32  16 
27648 - 28672  1  0  0  0   8  8 
30720 - 31744  0  1  0  0   0  0 
32768 - 33792  18  0  0  0  250  13 
33792 - 34816  0  1  0  0   0  0 
39936 - 40960  0  2  0  0   0  0 
40960 - 41984  0  1  0  0   0  0 
43008 - 44032  0  2  0  0   0  0 
44032 - 45056  0  5  0  0   0  0 
45056 - 46080  0  1  0  0   0  0 
46080 - 47104  0  2  0  0   0  0 
47104 - 48128  0  1  0  0   0  0 
49152 - 50176  0  3  0  0   0  0 
50176 - 51200  1  0  0  0   16  16 
51200 - 52224  0  4  0  0   0  0 
57344 - 58368  0  1  0  0   0  0 
58368 - 59392  0  1  0  0   0  0 
62464 - 63488  0  1  0  0   0  0 
63488 - 64512  200  1  0  0  3200  16 
64512 - 65536  0  1  0  0   0  0 
65536 - 66560  1029  2  0  0  10624  10 
79872 - 80896  100  0  0  0  900  9 
131072 - 132096  9  0  0  0  144  16 
193536 - 194560  1  0  0  0   9  9 
224256 - 225280  1  0  0  0   16  16 
262144 - 263168  49  27  0  0  784  16 
327680 - 328704  1  0  0  0   17  17 
384000 - 385024  0  1  0  0   0  0 
523264 - 524288  1  5  0  0   23  23 
------------------------------------------------------------------ 
    Total    2271 268 1035921 12395 10610020  10

这可能是一个外观图释，不能回答为什么赢得10版本不工作:-(

来源

2016-12-02 14:14:16

为什么堆堆不能按照预期的方式工作？

回答

相关问题