4

メモリダンプがあります。このダンプには、ハンドル付きのヒープがありますfd00000。!heap -s fd00000これは、コマンドの出力からの抜粋です。

 0: Heap 0fd00000
 Flags          00001002 - HEAP_GROWABLE 
 Reserved memory in segments              80192 (k)
 Commited memory in segments              56540 (k)
 Virtual bytes (correction for large UCR) 60592 (k)
 Free space                               3884 (k) (572 blocks)
 External fragmentation          6% (572 free blocks)
 Virtual address fragmentation   6% (69 uncommited ranges)
 Virtual blocks  124 - total 0 KBytes
 Lock contention 23
 Segments        1

期待どおりに要約情報が表示されていることがわかります。しかし、出力は!heap -stat -h 0fd00000 次のようになります。

 heap @ 0fd00000
 group-by: TOTSIZE max-display: 20
 size     #blocks     total     ( %) (percent of total busy bytes)
 19fa40 7a - c614280  (93.96)
 62d30 4 - 18b4c0  (0.73)
 d49 13d - 107365  (0.49)

すべて 16 進数なので、ここから「総ビジー バイト数」が 205 MB を超えていることがわかります。つまり、このヒープには 80 MB/60 MB の予約済み/仮想メ​​モリがあることがわかりますが、このヒープは 205 MB を占有していることがわかります。!heap -s!heap -stat不一致は非常に大きいです。これはどのように可能ですか？実行する!heap -sと、次のような複数のエントリが表示されます。

Virtual block: 293c0000 - 293c0000 (size 00000000)

多分これが理由ですか？

4

1 に答える 1

1

一部の!heapスイッチは、大量の割り当てがヒープ マネージャーを通過するときに正しく動作しないことが知られています。Heap Manager は大きな割り当てを に直接転送します。これらの割り当てを追跡する方法を知っているコマンドVirtualAllocもあれば、知らないコマンドもあります。!heapまた、WinDbg のバージョンを最新の Windows SDK に更新してみてください。これは、!heapコマンドが、Windows のバージョンによって変化するヒープ マネージャーの内部データ構造と密接に結びついているためです。

このような状況で VMMap を使用して、大きな割り当てソースを検出することをお勧めします。

于 2015-07-23T11:27:11.287 に答える