The .NET runtime includes automatic memory management, garbage collection, so there’s no need to explicitly allocate or deallocate memory. However there’s still ways managed applications can leak memory, here’s a summary of what can go wrong:

1. you have a managed memory leak, meaning you have a finished with an object, but you are still holding a reference to it so the garbage collector cannot tell that you have finished with it. Typically this is done by adding it to global collection or event handler.
2. you are using unmanaged objects wrapped in managed objects (this is essentially what DirectX is), and you forget to call the Dispose method to release the unmanaged resources (this won’t actually cause a leak since the memory will be reclaimed eventually but it will take a lot longer since the object now needs to be finialized which requires two garbage collections)
3. Your using unmanaged code directly via p/invoke and you forget to deallocated it, because in this case you do need to deallocate it.

The windows platform has a great tool for trapping all these types of memory leaks, its called windbg and it can be downloaded here: [link:www.microsoft.com]

There’s lots of material on the internet about how to trap memory leaks in managed application, here’s a couple I found useful:
[link:blogs.msdn.com]
[link:geekswithblogs.net]