I'm using !dumpheap -stat for investigating a C# application dump, I have taken the dump using "C:\Windows\Syswow64\TaskMgr.exe". I have a question concerning the numbers I see:
!dumpheap -stat
The version of SOS does not match the version of CLR you are debugging. Please
load the matching version of SOS for the version of CLR you are debugging.
CLR Version: 4.7.3946.0
SOS Version: 4.8.9195.0
Statistics:
MT Count TotalSize Class Name
0b79f9b8 1 12 System.Collections.Generic.ObjectEqualityComparer`1[[Location, ProductShared]]
0b797500 1 12 Product.TelegramManager+<>c
0b796d78 1 12 Product.UdpConnection+<>c__DisplayClass11_1
... ... ... ...
08205080 8601 791292 System.Net.Sockets.Socket
05fe3c04 24246 1066824 System.Threading.ExecutionContext
050afd98 19003 1119064 System.String
050e6fdc 10489 1771710 System.Byte[]
06135068 7812 2031120 System.Net.Sockets.SocketAsyncEventArgs
00f0bcd0 19572 892214388 Free
The total size of the file (in bytes):
"C:\Temp_Folder\ProductServer (2).DMP" 1.113.058.732
This is in line with what I see in Windows explorer (1.086.972 KB).
The total amount of "TotalSize" (except "Free") equals 14841410.
Adding the "Totalsize" of "Free" equals 907.055.798.
None of those values corresponds with the total size of the dumpfile, so I'm wondering:
- Can I even use
!dumpheap -statfor investigating the memory usage of my C# application? - Is there a difference between managed memory usage and native memory usage (which might explain the enormous value for "Free" in the
!dumpheap -statresult)? - What is the exact relation between
!dumpheap -statresult and file size of the dump?
Edit after first dotMemory analysis of the dump:
My suspicions seem to be confirmed by a first glance at a JetBrains "dotMemory" analysis:
As you can see, only a small ±13Mb is occupied by objects, so why is the total size of the dump larger than 1Gb?
Edit: Memory snapshot, as shown in dotMemory
In dotMemory, the memory snapshot looks as follows:
In my humble opinion, this means that ±865Mb is present in the dump without even being used.
How is this possible?
Edit: investigation of pinned objects:
In the referred post, there are two commands: !gcroot <memory_address> and !eehead -gc, hereby the results of those commands:
!gcroot <memory_address of one of the System.Net.Sockets.SocketAsyncEventArgs objects:
0:000> !gcroot 02d259f8
The version of SOS does not match the version of CLR you are debugging. Please
load the matching version of SOS for the version of CLR you are debugging.
CLR Version: 4.7.3946.0
SOS Version: 4.8.9195.0
HandleTable:
00e726fc (async pinned handle)
-> 030b6f84 System.Threading.OverlappedData
-> 02d2a01c System.Threading.IOCompletionCallback
-> 02d259f8 System.Net.Sockets.SocketAsyncEventArgs
Found 1 unique roots (run '!GCRoot -all' to see all roots).
(The result "async pinned handle" gives me the impression I'm dealing with a pinned object indeed.)
Hereby the results of the eeheap -gc command:
0:000> !eeheap -gc
The version of SOS does not match the version of CLR you are debugging. Please
load the matching version of SOS for the version of CLR you are debugging.
CLR Version: 4.7.3946.0
SOS Version: 4.8.9195.0
Number of GC Heaps: 1
generation 0 starts at 0x60131f04
generation 1 starts at 0x600c1000
generation 2 starts at 0x02b71000
ephemeral segment allocation context: none
segment begin allocated size
02b70000 02b71000 03824fec 0xcb3fec(13320172)
15700000 15701000 162ec0bc 0xbeb0bc(12497084)
11700000 11701000 1229a258 0xb99258(12161624)
14700000 14701000 15356178 0xc55178(12931448)
16700000 16701000 171d2ec4 0xad1ec4(11345604)
19700000 19701000 1a2250fc 0xb240fc(11682044)
1a700000 1a701000 1b2ebbc0 0xbeabc0(12495808)
17700000 17701000 18215dc0 0xb14dc0(11619776)
10020000 10021000 10af8f94 0xad7f94(11370388)
13700000 13701000 1436bea8 0xc6aea8(13020840)
18700000 18701000 191b3024 0xab2024(11214884)
1d4c0000 1d4c1000 1df235a0 0xa625a0(10888608)
0dea0000 0dea1000 0e9b5a5c 0xb14a5c(11618908)
1f540000 1f541000 1ffcd6d4 0xa8c6d4(11060948)
1e4c0000 1e4c1000 1f0044e0 0xb434e0(11810016)
12700000 12701000 131b0d50 0xaafd50(11205968)
20540000 20541000 21071efc 0xb30efc(11734780)
22540000 22541000 2304c388 0xb0b388(11580296)
23540000 23541000 23ff2aec 0xab1aec(11213548)
24540000 24541000 24ff1fc0 0xab0fc0(11210688)
21540000 21541000 21fc6150 0xa85150(11030864)
27540000 27541000 28089918 0xb48918(11831576)
26540000 26541000 27076b44 0xb35b44(11754308)
25540000 25541000 2601f3a4 0xade3a4(11396004)
1c4c0000 1c4c1000 1cf12e3c 0xa51e3c(10821180)
2a540000 2a541000 2b0a243c 0xb6143c(11932732)
28540000 28541000 2906b6d4 0xb2a6d4(11708116)
2c540000 2c541000 2cfa5538 0xa64538(10896696)
2b540000 2b541000 2bf1ea28 0x9dda28(10345000)
29540000 29541000 29f7649c 0xa3549c(10704028)
2f540000 2f541000 2fee349c 0x9a249c(10101916)
2d540000 2d541000 2df41b38 0xa00b38(10488632)
30540000 30541000 30f5da50 0xa1ca50(10603088)
2e540000 2e541000 2ef127a8 0x9d17a8(10295208)
360c0000 360c1000 36c1727c 0xb5627c(11887228)
370c0000 370c1000 37bfb8f8 0xb3a8f8(11774200)
32540000 32541000 33158778 0xc17778(12679032)
390c0000 390c1000 39c4fc54 0xb8ec54(12119124)
3b0c0000 3b0c1000 3bb78efc 0xab7efc(11239164)
3a0c0000 3a0c1000 3ac0482c 0xb4382c(11810860)
3c0c0000 3c0c1000 3cbb095c 0xaef95c(11467100)
380c0000 380c1000 38b3c34c 0xa7b34c(10990412)
3e0c0000 3e0c1000 3eb31580 0xa70580(10945920)
3f0c0000 3f0c1000 3fc9e148 0xbdd148(12439880)
3d0c0000 3d0c1000 3dcc34fc 0xc024fc(12592380)
400c0000 400c1000 40c4006c 0xb7f06c(12054636)
410c0000 410c1000 41b0297c 0xa4197c(10754428)
420c0000 420c1000 42b3fbbc 0xa7ebbc(11004860)
430c0000 430c1000 43c8c314 0xbcb314(12366612)
460c0000 460c1000 46f1e244 0xe5d244(15061572)
440c0000 440c1000 44c1bec8 0xb5aec8(11906760)
450c0000 450c1000 45b5d020 0xa9c020(11124768)
33540000 33541000 33f0129c 0x9c029c(10224284)
31540000 31541000 31f4505c 0xa0405c(10502236)
480c0000 480c1000 48bce7b4 0xb0d7b4(11589556)
4b0c0000 4b0c1000 4bb84104 0xac3104(11284740)
4a0c0000 4a0c1000 4ab2856c 0xa6756c(10909036)
470c0000 470c1000 47ab4618 0x9f3618(10434072)
490c0000 490c1000 49a9367c 0x9d267c(10299004)
4c0c0000 4c0c1000 4cabe870 0x9fd870(10475632)
4d0c0000 4d0c1000 4dbc46e0 0xb036e0(11548384)
4f0c0000 4f0c1000 4fbc6644 0xb05644(11556420)
4e0c0000 4e0c1000 4ebede38 0xb2ce38(11718200)
510c0000 510c1000 51b0b090 0xa4a090(10789008)
500c0000 500c1000 50a8b41c 0x9ca41c(10265628)
540c0000 540c1000 54bb6784 0xaf5784(11491204)
520c0000 520c1000 52afdf9c 0xa3cf9c(10735516)
530c0000 530c1000 53a924b4 0x9d14b4(10294452)
570c0000 570c1000 57b247d8 0xa637d8(10893272)
560c0000 560c1000 56ab2050 0x9f1050(10424400)
580c0000 580c1000 58b0bebc 0xa4aebc(10792636)
550c0000 550c1000 55a31710 0x970710(9897744)
590c0000 590c1000 59b4062c 0xa7f62c(11007532)
5b0c0000 5b0c1000 5ba4d478 0x98c478(10011768)
5c0c0000 5c0c1000 5cc10f3c 0xb4ff3c(11861820)
5a0c0000 5a0c1000 5aaa172c 0x9e072c(10356524)
5e0c0000 5e0c1000 5ecb2ff8 0xbf1ff8(12525560)
5d0c0000 5d0c1000 5d9a1d88 0x8e0d88(9309576)
5f0c0000 5f0c1000 5f9de694 0x91d694(9557652)
600c0000 600c1000 60b2bcc4 0xa6acc4(10923204)
Large object heap starts at 0x03b71000
segment begin allocated size
03b70000 03b71000 03cb8e48 0x147e48(1343048)
Total Size: Size: 0x3611c380 (907133824) bytes.
------------------------------
GC Heap Size: Size: 0x3611c380 (907133824) bytes.
gcroot seems not to work very well (even without spelling mistakes :-) ):
0:000> !gcroot 0x03b71000
...
Found 0 unique roots (run '!GCRoot -all' to see all roots).
0:000> !GCRoot -all
The version of SOS does not match the version of CLR you are debugging. Please
load the matching version of SOS for the version of CLR you are debugging.
CLR Version: 4.7.3946.0
SOS Version: 4.8.9195.0
Invalid argument -all
Information for Eocron:
Hereby the last lines of the od -x ProductServer (2).DMP WSL command (I tried using the HEX viewer of Notepad++ but this seems not to work well on such large files):
10225750420 0000 8000 0100 0002 0000 0000 0000 0000
10225750440 0000 0000 0000 0000 0008 0000 0000 0000
10225750460 0000 0000 0000 0000 0000 0000 0000 0000
*
10225750520 0001 0000 0000 0000 0000 0000 0000 0000
10225750540 0000 0000 504b fecd ffff ffff 0002 0000
10225750560 0001 0083 fe28 8dfb 1b3d 01da 5800 14c5
10225750600 3c3d 01da 0007 0000 0000 0000 0007 0000
10225750620 0000 0000 0340 0000 0001 0000 0000 0000
10225750640 00a0 0000 00a0 0000 0100 0000 0240 0000
10225750660 0100 0000 0000 0000 0000 0000 0000 0000
10225750700 0000 0000 0000 0000 0000 0000 0000 0000
*
10225751640 0000 0000 0000 0000 0000 0000 0340 0000
10225751660 0000 0000 0000 0000 0000 0000 0000 0000
*
10225756640 0000 0000 0000 0000 0000 0000 0001 0000
10225756660 0000 0000 724e 65f4 b54b 0111 0000 0000
10225756700 0000 0000 0000 0000 0000 0000 0000 0000
*
10225766640 0000 0000 0000 0000 0000 0000
10225766654
=> Eocron, can you confirm whether or not this looks like the assembly references you've mentioned?
Information for dbc:
I've done a ping -n 100 <IP_Address> for one of the IP addresses, used for setting up TCP sockets, hereby the result (summary):
Reply from <IP_Addr>: bytes=32 time<1ms TTL=59 => 54 entries
Reply from <IP_Addr>: bytes=32 time=1ms TTL=59 => 40 entries
Reply from <IP_Addr>: bytes=32 time=2ms TTL=59 => 6 entries
Ping statistics for <IP_Addr>:
Packets: Sent = 100, Received = 100, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 2ms, Average = 0ms
... while, for another IP address, these are the results:
Reply from <IP_Addr2>: bytes=32 time<1ms TTL=59 => 70 entries
Reply from <IP_Addr2>: bytes=32 time=1ms TTL=59 => 25 entries
Reply from <IP_Addr2>: bytes=32 time=2ms TTL=59 => 4 entries
Reply from <IP_Addr2>: bytes=32 time=3ms TTL=59 => 1 entries
Ping statistics for <IP_Addr2>:
Packets: Sent = 100, Received = 100, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 3ms, Average = 0ms
=> As you can see, there is some variation on the response time, but I don't know if this might be sufficient to explain the mentioned behaviour.
Edit after comment from Alois Kraus:
@Alois, when a connection needs to be closed, I have the following piece of source code: (the connection is handled by a class, containing the property _clientSocket of the Socket class)
Can you confirm I should add the propose line?
Do you also know why the customer currently doesn't seem to have the memory leak? (The customer was before working on another Windows version, .Net framework 4.0, while now he is working on .Net framework 4.7)
Private Sub Socket_ConnectComplete(sender As Object, e As SocketAsyncEventArgs)
If e.SocketError <> SocketError.Success Then
// e.Dispose() <= should I add this line of source code?
Disconnect()
Return
End If
Public Sub Disconnect()
Try
If _clientSocket IsNot Nothing Then
_clientSocket.Close()
_clientSocket = Nothing
End If
...
End Sub