GC works properly, but this question has nothing to do with the problem.
Do you think that with GC you don't have memory leaks? If so, this is completely wrong. Of course it eliminates memory leaks you would make due to forgetting to release some memory, but it cannot help if you have wrong design. It's pretty easy to design code which leaks managed memory.
As to forgetting to release some resources, this is still a source of other kind of memory leaks, of unmanaged resources. In particular, you need guarantee that you properly call
for all types implementing
, because many of such objects allocate unmanaged resource and free them only if you call
. This is the possibility Mehdi mentioned in his solution. Use
statement (not to be mixed up with
Of course you can have memory leaks by design. One typical case is putting objects in some application-global collection (for the sake of fast search, for example) and forgetting to remove references when object is not used anymore. By the way, think about using
, see http://msdn.microsoft.com/en-us/library/system.weakreference.aspx
So, first analyze your design for management of life cycle of all objects. Remember that an object is scheduled for destruction by GC only if all references to it in whole Application Domain becomes totally inaccessible form working code, but it does not apply to weak references. This mechanism if very cunning: if you have isolated path of circular reference, GC is clever enough to schedule all involving objects for destruction. Consider
. If all other references to each of these three objects are lost, they will be scheduled for destruction by GC anyway. [EDIT] The criteria for destruction is reachability
, see http://en.wikipedia.org/wiki/Garbage_collection_%28computer_science%29#Reachability_of_an_object
].[END EDIT] Pretty neat, isn't it?
After that you may need to use the good advice by Mehdi and use a memory profiler. A good memory profiler is quite a powerful weapon.—SA