WinDbg地址摘要
WinDbg地址摘要
提问于 2012-08-09 11:48:24
我们托管在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)我不明白的是非机密的。它们都很大！我运行了!address，再一次得到了很多非机密的信息。我是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.回答 2
Stack Overflow用户
回答已采纳
发布于 2012-08-09 22:16:38
关于未分类，互联网上的许多帖子表明，在较新版本的WinDBG中，未分类条目只是取代了以前映射到不同区域的内容。在以前版本的调试器中，您有这些RegionUsageIsVAD, RegionUsageImage。
就我而言，我在!address -summary输出中也有很多未分类的条目，但这并不妨碍我以后的调试。
否，返回到您的其他结果：
根据我使用WinDBG的经验，如果当MEM_COMMIT提供1.3 it时，eeheap显示约300MB的内存，这可能是本机内存泄漏。
关于如何捕捉它，请参阅CodeProject。
请注意，在运行!heap -p -a时，您可能没有堆栈，因此在调试之前，您需要使用适当的gflag来运行进程。你可以使用read more about it
然后，您可能会遇到另一种更简单的情况，即字符串重复。我有一次遇到过这样的情况，described it。
Stack Overflow用户
发布于 2017-05-31 04:00:49
WCF (Windows Communication Foundation)是一种.NET技术。.NET不使用Windows Heap Manager，所以使用任何!heap命令对.NET都不起作用，难怪它很小。
相反，由于垃圾收集，.NET框架有自己的内存管理器。您已经使用了正确的命令!eeheap -gc来显示有关.NET堆的信息。该命令的最后一行写道：
GC Heap Size: Size: 0x175de850 (392030288) bytes.因此，.NET负责将近400MB的<unclassified> (<unknown>)内存。其余的原因可能是
- 通过Windows Heap Manager直接调用course
- allocations的
VirtualAlloc()，这些调用大于512KB(请参阅statement by Sasha Goldshtein)。例如，这可以是一些C++代码。处理图像或视频通常属于MSXML - potential其他垃圾收集内存管理器的category.
- some版本，例如来自MSXML
- potential的堆管理器(猜测，我从未验证过，但Windows堆管理器不能很好地用于垃圾收集)
如果这些值保持不变，就没有什么好担心的了。但如果它增加了，这可能表示存在泄漏。我个人认为这87000个计时器回调是一个潜在的来源。所有这些计时器回调都在做什么？他们能完成他们的工作吗？
79baa808 87474 1749480 System.Threading._TimerCallback页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接：
https://stackoverflow.com/questions/11876516
复制相关文章
相似问题
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号