Example:
0:074> !address -summary
--- Usage Summary ---------------- RgnCount ----------- Total Size -------- %ofBusy %ofTotal
Free 90919 7ec`34659000 ( 7.923 Tb) 99.03%
<unclassified> 95426 12`3c3e9000 ( 72.941 Gb) 92.12% 0.89%
Heap 744 1`7ee50000 ( 5.983 Gb) 7.56% 0.07%
Image 4303 0`0f890000 ( 248.563 Mb) 0.31% 0.00%
Stack 225 0`00de9000 ( 13.910 Mb) 0.02% 0.00%
TEB 75 0`00096000 ( 600.000 kb) 0.00% 0.00%
ActivationContextData 28 0`00025000 ( 148.000 kb) 0.00% 0.00%
NlsTables 1 0`00023000 ( 140.000 kb) 0.00% 0.00%
CsrSharedMemory 1 0`00006000 ( 24.000 kb) 0.00% 0.00%
PEB 1 0`00001000 ( 4.0开发者_如何转开发00 kb) 0.00% 0.00%
<unclassified>
is for allocations that are not further traceable to other memory managers and thus is allocated via VirtualAlloc()
from WinDbg's point of view. In newer versions of WinDbg, this is called <unknown>
.
There are different reasons for memory classified that way:
- direct calls to
VirtualAlloc()
of course - allocations via the Windows Heap Manager that are larger than 512 kb (see the statement by Sasha Goldshtein).
- allocations of the .NET runtime (which has its own heaps that are unknown to WinDbg until you use the special SOS extension)
- some versions of MSXML
- potential other memory managers, e.g. the heap manager from Java or Python (just a guess, I never verified)
Hmmm, this is a wild guess, but things that can take up VA space that aren't on that list are directly calling VirtualAlloc, or memory-mapped files. VMMap might prove to be more helpful here.
精彩评论