Memory Leaks in Managed code

Q: Can you have memory leaks in
managed code? If so, how can you
catch them?"urn:schemas-microsoft-com:office:office" />

A: (From the GC Architect) GC will typically reclaim objects at its
own pace, based on balancing available memory and runtime overhead. If an
assembly is terminated and it is known to contain a significant percentage of
the total set of managed objects, then calling GC.Collect() after the unload
does make sense.

If you define a leak as the memory
usage grows over time, then you can have leaks in a GC runtime. If you keep ever
growing datat in a static variable for example. Suppose an editor keeps an
infinite undo list, then this would be seen as a leak.

As far as leak detection and
diagnosis, you should look at the perfmon counters in the category
."urn:schemas-microsoft-com:office:smarttags" />NET CLR Memory You will find a lot of
interesting counters like # object in all heaps. They will tell you if you are
leaking objects.

You should also check out the
various CLR memory profilers out there. With
them you can get a picture of the heap and by comparing the pictures at 2
different points you can determine which objects are accumulating and then find
out which code path allocates them in the first place, or even, which connected
graph keeps them alive.