In every language there are traps that easy to fall to and misconceptions on the expected behavior of the language and framework, and this post will detail some of these such as 'Assuming the Dictionary type keeps items in the same order as you add them'.
In a garbage collected environment, the term memory leak is a bit counter intuitive. There are 2 related core causes for this. The first core cause is when you have objects that are still referenced but are effectually unused. The second cause is when you somehow allocate unmanaged memory (without garbage collection) and don’t free it.
Subscribing to Events. Once you subscribe to an event, that object holds a reference to your class.
Capturing members in anonymous methods, while it might be obvious that an event-handler method means an object is referenced, it’s less obvious that the same applies when a class member is captured in an anonymous method.
Static Variables is considered as a GC Root. This means that static variables and everything they reference will never be garbage collected.
Caching functionality. Developers love caching. Why do an operation twice when you can do it once and save the result, right?
Incorrect WPF Bindings. WPF Bindings can actually cause memory leaks. The rule of thumb is to always bind to a DependencyObject or to a INotifyPropertyChanged object.
Threads that Never Terminate. We already talked about how the GC works and about GC roots. I mentioned that the Live Stack is considered as a GC root. The Live Stack includes all local variables and members of the call stacks in the running threads.
Not de-allocating unmanaged memory, you will need to de-allocate the memory explicitly.
Adding Dispose without Calling it, what happens when whoever used the class didn’t call Dispose?