Large Object Heap Fragmentation
The C#/.NET application I am working on is suffering from a slow memory leak.  I have used CDB with SOS to try to determine what is happening but the data does not seem to make any sense so I was hoping one of you may have experienced this before.

The application is running on the 64 bit framework.  It is continuously calculating and serialising data to a remote host and is hitting the Large Object Heap (LOH) a fair bit.  However, most of the LOH objects I expect to be transient: once the calculation is complete and has been sent to the remote host, the memory should be freed.  What I am seeing, however, is a large number of (live) object arrays interleaved with free blocks of memory, e.g., taking a random segment from the LOH:

    0:000> !DumpHeap 000000005b5b1000  000000006351da10
             Address               MT     Size
    ...
    000000005d4f92e0 0000064280c7c970 16147872
    000000005e45f880 00000000001661d0  1901752 Free
    000000005e62fd38 00000642788d8ba8     1056       <--
    000000005e630158 00000000001661d0  5988848 Free
    000000005ebe6348 00000642788d8ba8     1056
    000000005ebe6768 00000000001661d0  6481336 Free
    000000005f214d20 00000642788d8ba8     1056
    000000005f215140 00000000001661d0  7346016 Free
    000000005f9168a0 00000642788d8ba8     1056
    000000005f916cc0 00000000001661d0  7611648 Free
    00000000600591c0 00000642788d8ba8     1056
    00000000600595e0 00000000001661d0   264808 Free
    ...

Obviously I would expect this to be the case if my application were creating long-lived, large objects during each calculation.  (It does do this and I accept there will be a degree of LOH fragmentation but that is not the problem here.)  The problem is the very small (1056 byte) object arrays you can see in the above dump which I cannot see in code being created and which are remaining rooted somehow.

Also note that CDB is not reporting the type when the heap segment is dumped: I am not sure if this is related or not.  If I dump the marked (<--) object, CDB/SOS reports it fine:

    0:015> !DumpObj 000000005e62fd38
    Name: System.Object[]
    MethodTable: 00000642788d8ba8
    EEClass: 00000642789d7660
    Size: 1056(0x420) bytes
    Array: Rank 1, Number of elements 128, Type CLASS
    Element Type: System.Object
    Fields:
    None

The elements of the object array are all strings and the strings are recognisable as from our application code.

Also, I am unable to find their GC roots as the !GCRoot command hangs and never comes back (I have even tried leaving it overnight).

So, I would very much appreciate it if anyone could shed any light as to why these small (<85k) object arrays are ending up on the LOH: what situations will .NET put a small object array in there?  Also, does anyone happen to know of an alternative way of ascertaining the roots of these objects?

Thanks in advance.
Large Object Heap Fragmentation
===

The C#/.NET application I am working on is suffering from a slow memory leak.  I have used CDB with SOS to try to determine what is happening but the data does not seem to make any sense so I was hoping one of you may have experienced this before.

The application is running on the 64 bit framework.  It is continuously calculating and serialising data to a remote host and is hitting the Large Object Heap (LOH) a fair bit.  However, most of the LOH objects I expect to be transient: once the calculation is complete and has been sent to the remote host, the memory should be freed.  What I am seeing, however, is a large number of (live) object arrays interleaved with free blocks of memory, e.g., taking a random segment from the LOH:

    0:000> !DumpHeap 000000005b5b1000  000000006351da10
             Address               MT     Size
    ...
    000000005d4f92e0 0000064280c7c970 16147872
    000000005e45f880 00000000001661d0  1901752 Free
    000000005e62fd38 00000642788d8ba8     1056       <--
    000000005e630158 00000000001661d0  5988848 Free
    000000005ebe6348 00000642788d8ba8     1056
    000000005ebe6768 00000000001661d0  6481336 Free
    000000005f214d20 00000642788d8ba8     1056
    000000005f215140 00000000001661d0  7346016 Free
    000000005f9168a0 00000642788d8ba8     1056
    000000005f916cc0 00000000001661d0  7611648 Free
    00000000600591c0 00000642788d8ba8     1056
    00000000600595e0 00000000001661d0   264808 Free
    ...

Obviously I would expect this to be the case if my application were creating long-lived, large objects during each calculation.  (It does do this and I accept there will be a degree of LOH fragmentation but that is not the problem here.)  The problem is the very small (1056 byte) object arrays you can see in the above dump which I cannot see in code being created and which are remaining rooted somehow.

Also note that CDB is not reporting the type when the heap segment is dumped: I am not sure if this is related or not.  If I dump the marked (<--) object, CDB/SOS reports it fine:

    0:015> !DumpObj 000000005e62fd38
    Name: System.Object[]
    MethodTable: 00000642788d8ba8
    EEClass: 00000642789d7660
    Size: 1056(0x420) bytes
    Array: Rank 1, Number of elements 128, Type CLASS
    Element Type: System.Object
    Fields:
    None

The elements of the object array are all strings and the strings are recognisable as from our application code.

Also, I am unable to find their GC roots as the !GCRoot command hangs and never comes back (I have even tried leaving it overnight).

So, I would very much appreciate it if anyone could shed any light as to why these small (<85k) object arrays are ending up on the LOH: what situations will .NET put a small object array in there?  Also, does anyone happen to know of an alternative way of ascertaining the roots of these objects?

Thanks in advance.