我创建了一些进程的完全转储，其中（进程或其转储文件）需要大约7GB。 该过程是WCF服务。启动时需要大约1.4GB并在一段时间后长大，但从不超过2-3GB。从未到今天。现在几乎所有的免费记忆。
在WinDbg运行！dumpheap -stat命令时，我接下来：
000007fef929ac78 15038 4878720 System.Collections.Hashtable+bucket[]
000007fe9c4d4d20 118818 7604352 BLL.EmailOptOutBLL
000007fef92a0ec0 727949 17470776 System.RuntimeMethodHandle
000007fef9287fe8 10794 17832144 System.Reflection.Emit.__FixupData[]
000007fe9c6dc5c0 907500 36300000 ExactTargetEmail.etAPI.APIProperty
000007fef927f1b8 409602 39034712 System.Object[]
000007fe9c6d9858 302500 41140000 ExactTargetEmail.etAPI.ObjectExtension
000007fef929f058 49141 52089645 System.Byte[]
000007fef929aee0 2487200 152416116 System.String
00000000013a6030 941 1601636252 Free
所有列出的对象的总大小约为2.3GB
！eeheap -gc命令列出4个总大小为6.3GB的堆
问题：剩下的7GB - 2.3GB = 4.7GB？我怎样才能找到它们（在WinDbg或其他工具中）？
！地址-summary
0:000> !address -summary
Failed to map Heaps (error 80004005)
--- Usage Summary ---------------- RgnCount ----------- Total Size -------- %ofBusy %ofTotal
Free 387 7fb`98d72000 ( 7.983 Tb) 99.79%
<unclassified> 1141 4`53c8f000 ( 17.309 Gb) 98.28% 0.21%
Image 2387 0`11ed5000 ( 286.832 Mb) 1.59% 0.00%
Stack 141 0`0168c000 ( 22.547 Mb) 0.13% 0.00%
TEB 47 0`0005e000 ( 376.000 kb) 0.00% 0.00%
NlsTables 1 0`00023000 ( 140.000 kb) 0.00% 0.00%
ActivationContextData 4 0`00007000 ( 28.000 kb) 0.00% 0.00%
CsrSharedMemory 1 0`00005000 ( 20.000 kb) 0.00% 0.00%
PEB 1 0`00001000 ( 4.000 kb) 0.00% 0.00%
--- Type Summary (for busy) ------ RgnCount ----------- Total Size -------- %ofBusy %ofTotal
MEM_PRIVATE 671 4`50a59000 ( 17.260 Gb) 98.00% 0.21%
MEM_IMAGE 3014 0`15304000 ( 339.016 Mb) 1.88% 0.00%
MEM_MAPPED 38 0`01521000 ( 21.129 Mb) 0.12% 0.00%
--- State Summary ---------------- RgnCount ----------- Total Size -------- %ofBusy %ofTotal
MEM_FREE 387 7fb`98d72000 ( 7.983 Tb) 99.79%
MEM_RESERVE 799 2`af232000 ( 10.737 Gb) 60.96% 0.13%
MEM_COMMIT 2924 1`b804c000 ( 6.875 Gb) 39.04% 0.08%
--- Protect Summary (for commit) - RgnCount ----------- Total Size -------- %ofBusy %ofTotal
PAGE_READWRITE 897 1`a2017000 ( 6.531 Gb) 37.08% 0.08%
PAGE_EXECUTE_READ 333 0`103c9000 ( 259.785 Mb) 1.44% 0.00%
PAGE_READONLY 899 0`03940000 ( 57.250 Mb) 0.32% 0.00%
PAGE_WRITECOPY 527 0`01c95000 ( 28.582 Mb) 0.16% 0.00%
PAGE_EXECUTE_READWRITE 132 0`003b9000 ( 3.723 Mb) 0.02% 0.00%
PAGE_EXECUTE_WRITECOPY 88 0`00208000 ( 2.031 Mb) 0.01% 0.00%
PAGE_READWRITE|PAGE_GUARD 47 0`000d2000 ( 840.000 kb) 0.00% 0.00%
PAGE_EXECUTE 1 0`00004000 ( 16.000 kb) 0.00% 0.00%
--- Largest Region by Usage ----------- Base Address -------- Region Size ----------
Free 5`3fa00000 7f9`5b0e0000 ( 7.974 Tb)
<unclassified> 1`0a3ef000 0`f5611000 ( 3.834 Gb)
Image 7fe`e7e9a000 0`01338000 ( 19.219 Mb)
Stack 0`007c0000 0`0007b000 ( 492.000 kb)
TEB 7ff`ffe9a000 0`00002000 ( 8.000 kb)
NlsTables 7ff`fffb0000 0`00023000 ( 140.000 kb)
ActivationContextData 0`00030000 0`00004000 ( 16.000 kb)
CsrSharedMemory 0`7efe0000 0`00005000 ( 20.000 kb)
PEB 7ff`fffdf000 0`00001000 ( 4.000 kb)
！eeheap -gc
0:000> !eeheap -gc
Number of GC Heaps: 4
------------------------------
Heap 0 (00000000013d4ad0)
generation 0 starts at 0x00000001066b2868
generation 1 starts at 0x00000001066984b8
generation 2 starts at 0x00000000ffa01000
ephemeral segment allocation context: none
segment begin allocated size
00000000ffa00000 00000000ffa01000 00000001067ea940 0x6de9940(115251520)
Large object heap starts at 0x00000004ffa01000
segment begin allocated size
00000004ffa00000 00000004ffa01000 0000000509173080 0x9772080(158802048)
Heap Size: Size: 0x1055b9c0 (274053568) bytes.
------------------------------
Heap 1 (00000000013d9960)
generation 0 starts at 0x0000000203ef0168
generation 1 starts at 0x0000000203d01f78
generation 2 starts at 0x00000001ffa01000
ephemeral segment allocation context: none
segment begin allocated size
00000001ffa00000 00000001ffa01000 000000027c2af408 0x7c8ae408(2089477128)
Large object heap starts at 0x000000050fa01000
segment begin allocated size
000000050fa00000 000000050fa01000 000000050fa01018 0x18(24)
Heap Size: Size: 0x7c8ae420 (2089477152) bytes.
------------------------------
Heap 2 (0000000001e48f90)
generation 0 starts at 0x000000030552c398
generation 1 starts at 0x00000003054a0920
generation 2 starts at 0x00000002ffa01000
ephemeral segment allocation context: none
segment begin allocated size
00000002ffa00000 00000002ffa01000 0000000374600330 0x74bff330(1958736688)
Large object heap starts at 0x000000051fa01000
segment begin allocated size
000000051fa00000 000000051fa01000 000000051fd87130 0x386130(3694896)
Heap Size: Size: 0x74f85460 (1962431584) bytes.
------------------------------
Heap 3 (0000000001e4bfa0)
generation 0 starts at 0x00000004059eaa60
generation 1 starts at 0x00000004057d3308
generation 2 starts at 0x00000003ffa01000
ephemeral segment allocation context: none
segment begin allocated size
00000003ffa00000 00000003ffa01000 0000000471912bb8 0x71f11bb8(1911626680)
Large object heap starts at 0x000000052fa01000
segment begin allocated size
000000052fa00000 000000052fa01000 0000000534f2d468 0x552c468(89310312)
Heap Size: Size: 0x7743e020 (2000936992) bytes.
------------------------------
GC Heap Size: Size: 0x1791cd260 (6326899296) bytes.
答案 0 :(得分：2)
如前所述，7.983 Tb只是免费的虚拟空间 I.E空间NOT（尚未）使用。
你的！地址 - 摘要显示17 GB和错误 “无法映射堆”意味着本地堆包含在＆lt;未分类＆gt;
据我所知，您的17 GB包含
a) Native heaps,
b) .NET heaps
c) Areas allocated by VirtualAlloc
d) Memory mapped files
.NET堆贡献6 GB，留下11 GB进行调查。 要检查本机堆，您可以尝试使用：
!heap –s
但是如果它们很大则尺寸可能不可靠，并且它可能无法工作，因为！address -summary无法分类。 您也可以尝试：
!address
BaseAddress EndAddress+1 RegionSize Type State Protect Usage
------------------------------------------------------------------------------------------------------------------------
+ 0`00000000 0`00010000 0`00010000 MEM_FREE PAGE_NOACCESS Free
+ 0`00010000 0`00020000 0`00010000 MEM_MAPPED MEM_COMMIT PAGE_READWRITE Heap [ID: 1; Handle: 0000000000010000; Type: Segment]
+ 0`00020000 0`00021000 0`00001000 MEM_PRIVATE MEM_COMMIT PAGE_READWRITE <unknown>
准备好长输出（因此重定向到文件），在这里你可以看到 所有内存区域和映射文件的文件名。
答案 1 :(得分：0)
我希望您的转储文件接近17 GB（如Kjell所指出的），而不是7 GB。我不认为你真的想在你的问题中使用7 GB，但我可能是错的。查看this article以了解有关！dumpheap -summary。
中的总尺寸显示的更多信息相关的是，GC堆正在使用6.2 GB，占承诺内存的最大份额（6.875 GB）。这是你最可能关心的。你的应用程序使用4个GC堆，其中，堆0比其他3个小一点（~274 MB），使用接近2 GB。如果您的应用没有内存压力，那么花时间垃圾收集可能效率不高。
显示你的！address和！heap -s输出可能有助于理解保留10.737 Gb内存的原因。