Please can anyone recommend a quick checklist / best practice guide to help us avoid simple (but subtle) mistakes that cause could cause memory leaks in .net apps
I find
There are many forms of leaks:
The first two is usually handled by two different pieces of code:
The third, however, is different.
Say you are using a big list holding thousands of objects, totalling a significant size of memory. If you keep around a reference to this list for longer than you need to, you will have what looks like a memory leak. In addition, if you keep adding to this list, so that it grows with more data periodically, and old data is never reused, you definitely have a memory leak.
One source of this I've seen frequently is to attach methods to event handlers but forget to unregister them when you're done, slowly bloating the event handler both in size and code to execute.
The fourth, an incorrect understanding of how .NET memory management works can mean that you look at the memory usage in a process viewer and notice that your app keeps growing in memory usage. If you have lots and lots of memory available, GC might not run that often, giving you an incorrect picture of the current usage of memory, as opposed to mapped memory.
The fifth, that's harder, I've only seen one resource management bug in .NET so far and afaik it has been slated for fix in .NET 4.0, it was with copying the desktop screen into a .NET image.
Edit: In response to the question in the comments, how to avoid keeping references longer than necessary, then the only way to do that is to to just that.
Let me explain.
First, if you have a long-running method (for instance, it might be processing files on disk, or downloading something, or similar), and you used a reference to a big data-structure early in the method, before the long-running part, and then you don't use that data structure for the rest of the method, then .NET, in release-builds (and not running under a debugger) is smart enough to know that this reference, though it is held in a variable that is technically in scope, is eligible for garbage collection. The garbage collector is really aggressive in this respect. In debug-builds and running under a debugger, it will keep the reference for the life of the method, in case you want to inspect it when stopped at a breakpoint.
However, if the reference is stored in a field reference in the class where the method is declared, it's not so smart, since it's impossible to determine whether it will be reused later on, or at least very very hard. If this data structure becomes unnecessary, you should clear the reference you're holding to it, so that GC will pick it up later.
One of the many good things you can do to manage memory effectively.
Call dispose on any object that implements IDisposable wherever possible especially on the DataSet or DataTable object.
Better still use the using{} constructs on these objects.
Memory leaks can come from a variety of sources.
You registered an event but forgot to unregister that event.
Files/connections were opened but not closed properly.
The Dispose() call was not implemented properly.
The Dispose() call was bypassed somehow; for example, an exception was encountered in between.
You encountered a deadlock (which may result in not releasing root objects).
The finalizer thread is blocked; for example, the STA thread for the COM object is not available.
There are leaks from unmanaged code.
An object’s lifetime is too high.
There is a circular reference.
Leaks can come from the .NET Runtime environment (on rare occasions).
Leaks may also appear from your testing framework. (In that case, it is a test leak, not a development environment leak, and test engineers are responsible for resolving it.)
To answer your last two questions:
There are, by definition, no memory leaks in managed code. There are two kinds of leaks that can occur:
So, two rules of thumb are:
Following are the main reason of memory leak.
please read further on http://blogs.msdn.com/b/davidklinems/archive/2005/11/16/three-common-causes-of-memory-leaks-in-managed-applications.aspx