If you have developed C or C++ applications, then you are no doubt aware of memory leaks and their pitfalls. Although the .Net CLR abstracts memory management from the developer, memory leaks can happen in your .Net applications as well. In this article, we’ll look at the causes of memory leaks in .Net applications, how we can detect them, and the strategies we can use to avoid them.

The first thing to note is that you can have memory leaks in the managed heap, the unmanaged heap, and even on the stack. Memory allocated in the stack is generally reclaimed once the execution of the method is completed. However, there may be situations in which your application makes heavy use of the stack and the stack frame is never released. Such conditions may lead to leaking the thread stack.

The .Net CLR (common language runtime) allocates objects in the managed heap and releases them when they are no longer needed by the application. However, keep in mind that the runtime only releases objects in the managed heap that are unreachable. In other words, if your application has a reference to an object in the managed heap, that object will not be cleaned up by the GC (garbage collector). 

Release objects promptly

So, the first rule is to avoid holding references to managed objects longer than necessary. While this might not seem to be a memory leak, when an application holds references longer than necessary, memory consumption increases and an “Out of Memory” exception may result.