Is there a way to check if garbage collection was triggered while analyzing dump file through SOS.dll

647 views Asked by At

I am analyzing a .dmp file for "OutofMemory" exception. The objects are staying in the memory for very long time, so is there a command to check if the garbage collection was triggered by using SOS.dll or SOSEX?

1

There are 1 answers

0
Thomas Weller On

In a comment you mention

When I look at the dump, I see a particular object staying in generation 2 almost occupying 500+ MB, so I wanted to check if the garbage collection ran or not.

If you have an object in Gen 2, then garbage collection ran at least 2 times, otherwise it would be in Gen 0.

Now that you know it, it's obvious that this information is not really helpful. You want to know why it remains in memory.

To find out which reference keeps the large object in memory, use the SOS command !gcroot. When you know that, review your code to find out where such a reference comes from or where it should be removed.

If there is no reference any more, the object may be freed soon and it's just alive because no Gen 2 garbage collection has occurred since. See this great answer on IDisposable, which discusses the point of releasing a large object.

In your case, it might even be ok to call GC.Collect() after releasing the reference. Usually you should not tamper with garbage collection, but if you always have such a large object and you certainly know that this object is no longer needed and GC.Collect() resolves the OOM exception, then it is the right thing to do.