本文介绍了< unclassified>有什么作用?在windbg中的均值！地址输出的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！
问题描述
示例:
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.000 kb) 0.00% 0.00%
推荐答案
<unclassified>用于无法进一步追溯到其他内存管理器的分配，因此从WinDbg的角度通过VirtualAlloc()进行分配.在较新版本的WinDbg中，这称为<unknown>.
<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:
- 直接呼叫
VirtualAlloc()通过Windows Heap Manager进行的 - 分配大于512 kb(请参阅 Sasha Goldshtein声明).
- .NET运行时的分配(它具有自己的堆，在使用特殊的SOS扩展之前，WinDbg不会知道这些堆)
- 某些版本的MSXML
- 其他潜在的内存管理器，例如Java或Python的堆管理器(只是一个猜测，我从未验证)
- 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)
这篇关于< unclassified>有什么作用?在windbg中的均值！地址输出的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！