I'm investigating OutOfMemoryException in 32bit process, the following stats has drawn my attention (large int64 array):
!dumpheap -stat
........
707b251c 3 692500 System.Int64[]
6fa6b038 72151 2020228 System.Diagnostics.ProcessModule
6fa9b1a0 72151 2308832 System.Diagnostics.ModuleInfo
707fdd04 2404 3223807 System.Byte[]
707faea4 11990 5780152 System.Object[]
707fb37c 9847 16162530 System.Char[]
00c16a88 41026 19281740 Free
707fac04 183726 21698276 System.String
Total 758006 objects
0:000> !DumpHeap /d -mt 707b251c
Address MT Size
02f5b9ec 707b251c 76
02f7c198 707b251c 60
03f40000 707b251c 692364
Statistics:
MT Count TotalSize Class Name
707b251c 3 692500 System.Int64[]
Total 3 objects
0:000> !gcroot 03f40000
Thread 4320:
*** WARNING: Unable to verify checksum for System.ni.dll
1238ea6c 6fbedbd0 System.Net.TimerThread.ThreadProc() [f:\dd\NDP\fx\src\net\System\Net\_TimerThread.cs @ 707]
edi: (interior)
-> 03dc3670 System.Object[]
-> 03f40000 System.Int64[]
Found 1 unique roots (run '!GCRoot -all' to see all roots).
.Net Framework 4.8 is used. Why TimerThread needs such big array?
The dump was made out of "simplified" of app, the initial version has more drastic figures (with more threads(229 vs 32), with app domains(~180 vs 0) loading):
!dumpheap -stat
..........
707b251c 387 105384412 System.Int64[]
Finally found it, not sure whether TimeThread callstack that is shown by WinDbg is reflecting the reality, but the simplest way to reproduce it is to run such Console App with main method:
And later get the dump, which shows in my case
So it seems that strange behavior is related to Process.GetProcessesByName. However Process.GetCurrentProcess() doesn't produce any int64[] footprint in memory.