Q: Can you have memory leaks in managed code?  If so, how can you catch them?


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 .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.