随着用户负载的增加，我们在IIS中托管的wcf服务崩溃（w3wp.exe~1.6 GB）。我们通过Debug Diag获得转储并在windbg中运行此命令。这是输出：
0:000> !address -summary
Failed to map Heaps (error 80004005)
--- Usage Summary ---------------- RgnCount ----------- Total Size -------- %ofBusy %ofTotal
<unclassified> 6007 57a86000 ( 1.370 Gb) 85.37% 68.48%
Free 268 19519000 ( 405.098 Mb) 19.78%
Image 874 80da000 ( 128.852 Mb) 7.84% 6.29%
Stack 8022 64ce000 ( 100.805 Mb) 6.14% 4.92%
TEB 2674 a72000 ( 10.445 Mb) 0.64% 0.51%
NlsTables 1 24000 ( 144.000 kb) 0.01% 0.01%
ActivationContextData 4 b000 ( 44.000 kb) 0.00% 0.00%
CsrSharedMemory 1 7000 ( 28.000 kb) 0.00% 0.00%
PEB 1 1000 ( 4.000 kb) 0.00% 0.00%
--- Type Summary (for busy) ------ RgnCount ----------- Total Size -------- %ofBusy %ofTotal
MEM_PRIVATE 16360 5dd0f000 ( 1.466 Gb) 91.37% 73.30%
MEM_IMAGE 1188 8454000 ( 132.328 Mb) 8.05% 6.46%
MEM_MAPPED 36 974000 ( 9.453 Mb) 0.58% 0.46%
--- State Summary ---------------- RgnCount ----------- Total Size -------- %ofBusy %ofTotal
MEM_COMMIT 14613 51e17000 ( 1.279 Gb) 79.75% 63.97%
MEM_FREE 268 19519000 ( 405.098 Mb) 19.78%
MEM_RESERVE 2971 14cc0000 ( 332.750 Mb) 20.25% 16.25%
--- Protect Summary (for commit) - RgnCount ----------- Total Size -------- %ofBusy %ofTotal
PAGE_READWRITE 8423 475ea000 ( 1.115 Gb) 69.51% 55.76%
PAGE_EXECUTE_READ 155 69f1000 ( 105.941 Mb) 6.45% 5.17%
PAGE_READWRITE|PAGE_GUARD 5319 1f24000 ( 31.141 Mb) 1.90% 1.52%
PAGE_READONLY 364 11bc000 ( 17.734 Mb) 1.08% 0.87%
PAGE_WRITECOPY 179 a16000 ( 10.086 Mb) 0.61% 0.49%
PAGE_EXECUTE_READWRITE 109 1fd000 ( 1.988 Mb) 0.12% 0.10%
PAGE_EXECUTE_WRITECOPY 64 149000 ( 1.285 Mb) 0.08% 0.06%
--- Largest Region by Usage ----------- Base Address -------- Region Size ----------
<unclassified> 66f0000 c041000 ( 192.254 Mb)
Free 71c97000 4109000 ( 65.035 Mb)
Image 51b0e000 da4000 ( 13.641 Mb)
Stack c90000 3d000 ( 244.000 kb)
TEB 7f370000 1000 ( 4.000 kb)
NlsTables 7ffb0000 24000 ( 144.000 kb)
ActivationContextData 70000 5000 ( 20.000 kb)
CsrSharedMemory 7f6f0000 7000 ( 28.000 kb)
PEB 7ffd4000 1000 ( 4.000 kb)
我不明白的是未分类？它们都很大！我跑了！地址，并再次得到很多未分类。我是windbg的初学者，所以不知道如何从这里开始关于内存泄漏。
！heap -s和！gchandles给出了以下输出，这些数字看起来非常小。
0:000> !gchandles
GC Handle Statistics:
Strong Handles: 101224
Pinned Handles: 23
Async Pinned Handles: 2
Ref Count Handles: 4
Weak Long Handles: 0
Weak Short Handles: 0
Other Handles: 0
Statistics:
MT Count TotalSize Class Name
67370460 1 12 System.Web.Hosting.AppManagerAppDomainFactory
79b5f8b4 1 16 System.Threading.RegisteredWaitHandle
7aa02d34 1 20 System.Net.TimerThread+TimerQueue
79b76668 1 20 System.Threading._ThreadPoolWaitOrTimerCallback
79b9a934 1 24 System.Threading.AutoResetEvent
79ba1b18 1 28 System.SharedStatics
6733fc00 3 36 System.Web.Hosting.ISAPIRuntime
79b9f5e8 5 60 System.Object
79b9fde8 1 84 System.ExecutionEngineException
79b9fd9c 1 84 System.StackOverflowException
79b9fd50 1 84 System.OutOfMemoryException
79b9fc0c 1 84 System.Exception
7988736c 2 136 System.Threading.OverlappedData
79b9fe34 2 168 System.Threading.ThreadAbortException
79ba3670 10 360 System.Security.PermissionSet
79ba0ec8 4 448 System.AppDomain
79b88df4 19 1520 System.Runtime.Remoting.ServerIdentity
6736eb50 54 1728 System.Web.NativeFileChangeNotification
67375ecc 489 95844 System.Web.HttpContext
79b9ffcc 2645 126960 System.Threading.Thread
79b56c28 10536 683588 System.Object[]
79baa808 87474 1749480 System.Threading._TimerCallback
Total 101253 objects
0:000> !heap -s
LFH Key : 0x866023d1
Heap Flags Reserv Commit Virt Free List UCR Virt Lock Fast
(k) (k) (k) (k) length blocks cont. heap
-----------------------------------------------------------------------------
Virtual block: 020b0000 - 020b0000 (size 00000000)
Virtual block: 02250000 - 02250000 (size 00000000)
00080000 00000002 65536 42512 42512 1765 248 1 2 21d36 L
00180000 00008000 64 12 12 10 1 1 0 0
00260000 00001002 1088 628 628 24 0 1 0 0 L
00500000 00000002 1024 20 20 2 1 1 0 0 L
00640000 00001002 256 28 28 1 1 1 0 0 L
00680000 00001002 256 12 12 4 1 1 0 0 L
006c0000 00001002 256 12 12 4 1 1 0 0 L
00700000 00001002 1280 1172 1172 42 10 1 0 0 L
00740000 00001002 256 12 12 4 1 1 0 0 L
00ad0000 00001002 1280 296 296 2 1 1 0 0 L
00b10000 00001002 256 12 12 4 1 1 0 0 L
00b50000 00001002 256 12 12 4 1 1 0 0 L
00b90000 00001002 256 12 12 4 1 1 0 0 L
00bd0000 00001002 256 12 12 4 1 1 0 0 L
00c10000 00001002 256 12 12 4 1 1 0 0 L
00c50000 00001002 256 12 12 4 1 1 0 0 L
00dc0000 00001002 256 12 12 4 1 1 0 0 L
00e00000 00001002 256 12 12 4 1 1 0 0 L
00e40000 00001002 256 12 12 4 1 1 0 0 L
00e80000 00001002 256 12 12 4 1 1 0 0 L
00ec0000 00001002 256 12 12 4 1 1 0 0 L
00f00000 00001002 256 12 12 4 1 1 0 0 L
01050000 00001002 7424 4628 4628 14 4 1 0 0 L
01090000 00001002 256 36 36 1 1 1 0 0 L
01110000 00001002 7232 3192 3192 70 41 1 0 0 L
01120000 00001002 256 12 12 4 1 1 0 0 L
01160000 00001002 256 176 176 2 1 1 0 0 L
011a0000 00001002 256 24 24 3 1 1 0 0 L
012e0000 00001002 256 12 12 3 1 1 0 0 L
01320000 00001002 256 12 12 4 1 1 0 0 L
01360000 00001002 256 12 12 4 1 1 0 0 L
013a0000 00001002 256 12 12 4 1 1 0 0 L
013e0000 00001002 256 72 72 3 1 1 0 0 L
01420000 00001002 256 12 12 4 1 1 0 0 L
01460000 00001002 256 168 168 3 1 1 0 0 L
014a0000 00001002 256 12 12 4 1 1 0 0 L
014e0000 00001002 256 12 12 4 1 1 0 0 L
01520000 00001002 256 12 12 4 1 1 0 0 L
01560000 00001002 256 12 12 4 1 1 0 0 L
01670000 00001002 256 12 12 4 1 1 0 0 L
016b0000 00001002 256 12 12 4 1 1 0 0 L
016f0000 00001002 256 12 12 4 1 1 0 0 L
01730000 00001002 256 12 12 4 1 1 0 0 L
01770000 00001002 256 12 12 4 1 1 0 0 L
017b0000 00001002 256 12 12 4 1 1 0 0 L
017f0000 00001002 256 12 12 4 1 1 0 0 L
01830000 00011002 256 12 12 4 1 1 0 0 L
01870000 00001002 1088 120 120 7 1 1 0 0 L
01880000 00001002 64 12 12 4 1 1 0 0 L
01890000 00001002 256 12 12 4 1 1 0 0 L
019d0000 00001002 256 12 12 4 1 1 0 0 L
01a10000 00001002 256 116 116 0 0 1 0 0 LFH
01a50000 00001002 256 12 12 4 1 1 0 0 L
01b50000 00001002 256 200 200 4 0 1 0 0 L
01bb0000 00001002 3136 1500 1500 69 41 1 0 0 L
01bc0000 00041002 256 12 12 4 1 1 0 0 L
01c00000 00001002 3136 1500 1500 69 41 1 0 0 L
01c10000 00041002 256 12 12 4 1 1 0 0 L
01c50000 00041002 256 16 16 1 1 1 0 0 L
01e10000 00041002 256 64 64 1 1 1 0 0 L
01ed0000 00001002 1088 424 424 20 1 1 0 0 L
1af40000 00001002 256 152 152 0 0 1 0 0 L
1b060000 00001002 64 48 48 40 2 1 0 0 L
1bab0000 00001002 1280 688 688 28 2 2 0 0 L
-----------------------------------------------------------------------------
！eeheap -gc给出以下输出：
0:000> !eeheap -gc
Number of GC Heaps: 4
------------------------------
Heap 0 (000e9678)
generation 0 starts at 0x3415e208
generation 1 starts at 0x340b6894
generation 2 starts at 0x026f0038
ephemeral segment allocation context: none
segment begin allocated size
026f0000 026f0038 066eda74 0x3ffda3c(67099196)
336c0000 336c0038 3471a7c4 0x105a78c(17147788)
Large object heap starts at 0x126f0038
segment begin allocated size
126f0000 126f0038 1272cd38 0x3cd00(249088)
Heap Size: Size: 0x5094ec8 (84496072) bytes.
------------------------------
Heap 1 (000ea8b0)
generation 0 starts at 0x39fd9748
generation 1 starts at 0x39f13224
generation 2 starts at 0x066f0038
ephemeral segment allocation context: none
segment begin allocated size
066f0000 066f0038 0a6ef668 0x3fff630(67106352)
38e00000 38e00038 3a63e8bc 0x183e884(25421956)
Large object heap starts at 0x146f0038
segment begin allocated size
146f0000 146f0038 146f0048 0x10(16)
Heap Size: Size: 0x583dec4 (92528324) bytes.
------------------------------
Heap 2 (000ebdb8)
generation 0 starts at 0x3087fedc
generation 1 starts at 0x307e8868
generation 2 starts at 0x0a6f0038
ephemeral segment allocation context: none
segment begin allocated size
0a6f0000 0a6f0038 0e6ee9f4 0x3ffe9bc(67103164)
2f3b0000 2f3b0038 31acc084 0x271c04c(41009228)
Large object heap starts at 0x166f0038
segment begin allocated size
166f0000 166f0038 166f0048 0x10(16)
Heap Size: Size: 0x671aa18 (108112408) bytes.
------------------------------
Heap 3 (000ed4d0)
generation 0 starts at 0x6d1c892c
generation 1 starts at 0x6d110038
generation 2 starts at 0x0e6f0038
ephemeral segment allocation context: none
segment begin allocated size
0e6f0000 0e6f0038 126ee814 0x3ffe7dc(67102684)
2b1a0000 2b1a0038 2d14311c 0x1fa30e4(33173732)
6d110000 6d110038 6d75f814 0x64f7dc(6617052)
Large object heap starts at 0x186f0038
segment begin allocated size
186f0000 186f0038 186f0048 0x10(16)
Heap Size: Size: 0x65f10ac (106893484) bytes.
------------------------------
GC Heap Size: Size: 0x175de850 (392030288) bytes.
由于
答案 0 :(得分：9)
关于 unclassified ，互联网上的很多帖子都表明，在WinDBG 未分类条目的后期版本中，刚刚取代之前映射到不同区域的内容。在以前版本的调试器中，您有这些RegionUsageIsVAD, RegionUsageImage。
就我而言，我在!address -summary输出中也有很多或未分类的条目，但这并不妨碍我将来调试。
不，回到你的其他结果：
根据我对WinDBG的经验，如果当MEM_COMMIT给出1.3Gb时eeheap显示~300Mb的内存，则可能是本机内存泄漏。
请参阅CodeProject了解如何捕获它。
注意，运行!heap -p -a时可能没有堆栈，所以在调试之前需要使用适当的gflags运行进程。你可以read more about it
然后，您可能会遇到另一个更简单的情况，重复的字符串。我曾经遇到过这种情况described it。
答案 1 :(得分：1)
WCF（Windows Communication Foundation）是一种.NET技术。 .NET不使用Windows堆管理器，因此使用任何!heap命令都不适用于.NET。难怪它很小。
相反，由于垃圾回收，.NET框架有自己的内存管理器。您已使用正确的命令!eeheap -gc来显示有关.NET堆的信息。该命令的最后一行说：
GC Heap Size: Size: 0x175de850 (392030288) bytes.
因此，.NET负责将近400 MB的<unclassified>（<unknown>）内存。其余的可能是由
VirtualAlloc() 如果这些值保持不变，则无需担心。但如果它增加，这可能表明泄漏。我个人认为那些87000计时器回调是一个潜在的来源。所有那些计时器回调都在做什么？他们是否能够完成他们的工作？
79baa808 87474 1749480 System.Threading._TimerCallback