Podsumowanie adresu WinDbg

Question

Nasza usługa wcf obsługiwana w wypadkach IIS (w3wp.exe ~ 1,6 GB) w miarę wzrostu obciążenia użytkownika. Mamy zrzut przez Debug Diag i uruchomiliśmy to polecenie w windbg. To jest wyjście:

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) 

Czego nie rozumiem, jest niesklasyfikowane? Wszystkie są ogromne! Sprawdziłem adres i znowu otrzymałem wiele niesklasyfikowanych. Jestem początkujący w windbg, więc nie wiem, jak postępować tutaj w odniesieniu do wycieku pamięci.

! Heap -s i! Gchandles podaje następujące dane wyjściowe, a liczby te wyglądają bardzo małymi literami. !

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 daje następujący wynik:

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. 

Dzięki

Answer 1

O niesklasyfikowany, wiele stanowisk w Internecie wynika, że ​​w późnych wersjach WinDBG niesklasyfikowany wpisy właśnie zastąpiły rzeczy, które wcześniej były mapowane do różnych regionów. W poprzednich wersjach debuggera miałeś te RegionUsageIsVAD, RegionUsageImage.

Po mojej stronie, również mam wiele lub jawnych wpisów w !address -summary wyjściach, ale to nie przeszkadza mi w przyszłym debugowaniu.

Nie, wróć do innych wyników:

Według mojego doświadczenia z WinDBG, jeśli eeheap pokazuje ~ 300MB pamięci kiedy MEM_COMMIT daje 1.3Gb, może to być native wyciek pamięci.

Zobacz, jak można go złapać.

Pamiętaj, że prawdopodobnie nie będziesz mieć stosów podczas pracy z !heap -p -a, więc przed debugowaniem musisz uruchomić proces z odpowiednimi znakami gflag. Możesz read more about it

Następnie, być może masz inną, prostszą sytuację z powtarzającymi się ciągami znaków. Raz spotkałem się z taką sytuacją i described it.

Answer 2

WCF (Windows Communication Foundation) to technologia .NET. .NET nie korzysta z Menedżera sterty systemu Windows, więc użycie dowolnej komendy !heap nie będzie działać dla .NET. Nic dziwnego, że jest mały.

Zamiast tego, platforma .NET ma swój własny menedżer pamięci z powodu czyszczenia pamięci. Użyłeś już poprawnego polecenia !eeheap -gc, aby wyświetlić informacje o hałdach .NET. Ostatni wiersz tego polecenia mówi:

GC Heap Size:   Size: 0x175de850 (392030288) bytes. 

Więc NET jest odpowiedzialny za prawie 400 MB <unclassified> (<unknown>) pamięci. Reszta może być spowodowane przez

• połączeń bezpośrednich do VirtualAlloc() oczywiście
• przydziały przez sterty menedżera Windows, które są większe niż 512 kb (patrz statement by Sasha Goldshtein). Może to być na przykład kod C++. Praca z obrazami lub wideo może często należeć do tej kategorii.
• niektóre wersje MSXML
• potencjalnych innych menedżerów pamięci do zbierania śmieci, np. Menedżer sterty z Java (domyślam się, nigdy nie weryfikowałem, ale Menedżer sterty systemu Windows nie działa dobrze do zbierania śmieci)

Jeśli wartości te pozostają stałe, nie ma się czym martwić. Ale jeśli się zwiększy, może to oznaczać wyciek. Osobiście uważam te callbacki liczące 87000 za potencjalne źródło. Co robią te wszystkie wywołania czasowe? Czy kiedykolwiek są w stanie ukończyć swoją pracę?

79baa808 87474  1749480 System.Threading._TimerCallback