WinDbg的地址摘要

我们的WCF服务崩溃（w3wp.exe的〜1.6 GB）随着用户负载的增加而增加。我们通过Debug Diag获得了一个转储，并在windbg中运行这个命令。这是输出：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的初学者，所以不知道如何从这里开始处理内存泄漏问题。

！堆-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.

感谢

来源

2012-08-09 VVV

你想达到什么目的？调查崩溃或调查内存使用情况？崩溃时的调用堆栈是什么？ – 2012-08-09 05:22:34

其实只是试图找出为什么w3wp.exe IIS 6的内存使用量不断增加？ – VVV 2012-08-10 03:32:27

关于非保密，在互联网上展示了很多帖子说在WinDbg中非保密的后期版本条目刚刚取代了之前映射到不同区域的东西。在以前版本的调试器中，您有这些RegionUsageIsVAD, RegionUsageImage。

在我的身边，我也有很多或!address -summary输出非保密条目，但它并不妨碍我从未来的调试。

否，返回到你的其他结果：

根据我的使用WinDbg的经验，如果eeheap表明〜300MB的内存时MEM_COMMIT给1.3GB，这可能是本机内存泄漏。

见CodeProject你怎么能抓住它。

注意，你可能会运行!heap -p -a的时候，所以你需要与调试前适当GFLAGS运行过程中不会有堆栈。您可以read more about it

然后，你可能有另外一个，反复串简单的情况。我遇到过这种情况一次，并且described it。

来源

2012-08-09 14:16:37 KateButenko

感谢您的信息好友！ – VVV 2012-08-10 03:28:03

@VVV希望它有帮助！ – KateButenko 2012-08-10 08:32:37

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()通过Windows堆管理器
分配是大于512 KB（见statement by Sasha Goldshtein）。例如，这可能是一些C++代码。处理图像或视频通常可以归入这一类。
某些版本的MSXML
潜在的其他垃圾收集内存管理器，例如，来自Java的堆管理器（猜测，我从未验证过，但Windows堆管理器不能很好地处理垃圾收集）

如果这些值保持不变，则无需担心。但是如果增加，这可能表明泄漏。我个人认为那些87000定时器回调是潜在的来源。那些定时器回调在做什么？他们是否能够完成他们的工作？

79baa808 87474  1749480 System.Threading._TimerCallback

来源

2017-05-30 20:00:48

WinDbg的地址摘要

回答

相关问题