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的地址摘要

回答

相關問題