Private bytes does not appear to match summary

andyinpedro

I can see my private bytes growing consistent with VM memory as provided by task manager. However, the summary of the memory usage isn't nearly as large as the private bytes total. Shouldn't they be the same?

Andrew H

No: private bytes includes free space on the .NET heaps as well as unmanaged memory usage. You can find out which is responsible by looking at the breakdown at the bottom of the snapshot summary page: the free space on all .NET heaps value is included in the private bytes.

If this value is large and the largest free block is small, your program is suffering from fragmentation of the large object heap. See http://www.simple-talk.com/dotnet/.net- ... ject-heap/ for a description of the problem.

If the value is small, then it's likely that your program is suffering from an unmanaged memory leak of some variety. If the unmanaged memory is being used by .NET objects then you should be able to find the problem by looking for objects whose instance count is increasing, or by looking for objects on the finaliser queue that have not been disposed. The 'Kept in memory only by GC roots of type COM+' filter may also reveal .NET objects that have been leaked through unmanaged code.

EddieL

Hi Andrew,

I have a similar problem in one of my applications. I see in the ANTS Memory Profiler tool that the "Private Bytes" have grown from 45.1MB to 589.6 MB.

In your post you indicate that these Private Bytes include the free space on the .NET heap as well as unmanaged memory usage. I do have some unmanaged code wrapped into a managed .dll that is then used in my C# app, so it all makes sense so far.

In the Summary for my last snapshot I can see that the largest free block is 15MB which is arguably small, compared to the total number of pivate bytes. According to your explanation, this would point to the fact that the application is suffering from large object heap fragmentaton. Would that be accurate?

Cheers,
Eddie