This project is read-only.


MemClean! The first and only framework that actually cleans up .NET managed memory leaks.
The framework is lightweight, efficient and easy to use. Take a look you’ll agree, MemClean!’s for me!


Used in conjunction with your favorite managed memory analysis technique, MemClean! can be
directed to clean even the most stubborn dangling references from managed code under your control
(such as those troublesome static classes) and out of your control (such as Microsoft and 3rd party UI
controls or frameworks).

The framework focuses on two of the primary code patterns that produce .NET managed memory
leaks, static references and events. Given appropriate direction, MemClean! can ferret out these types
of pesky dangling references from static classes, Form hierarchies, and 3rd party product frameworks
efficiently and safely.


The MemClean! framework is robust and mature having already been successfully deployed in
numerous production scenarios before publication. The framework has proven to be an invaluable tool
in dealing with a variety of .NET managed memory issues.

MemClean! cleaning agents search for dangling references in places such as:
  1. Component event handler lists
    1. Forms, UserControls, etc
  2. Component references
  3. Delegate invocation lists
    1. events, custom delegates, etc
  4. All styles of Collections
    1. Arrays, Collections, Dictionaries, Lists, etc
  5. Singleton instances
    1. Non-static instances hidden behind a static facade

The Vision

It’s the eve of a major release, the eleventh hour. And final tests are revealing an alarming increase in
memory consumption, culminating in the dreaded “Out of virtual memory” message. Perhaps you’re
lucky and managed memory analysis directs you to your own code. But what if it’s a 3rd party control
leaking? You know you’ll never get a hot-fix in time. It may take a day, a week, a month, maybe never.

The MemClean! team has scoured the internet, looking for every leaky code example they could get
their hands on. If you’re brave enough to Google (or Bing) something innocuous enough, like, let’s say
‘.NET memory leak’, you might blanch in horror at the results. (Perhaps the faint of heart should choose
another profession.)

The sheer number and scope of 3rd party UI control leaks alone is disheartening. All the big boys do it.
Even our stalwart friends at MS are leaking on occasion. Add your own managed memory
mismanagement to the mix and you’ve got a potential catastrophe on your hands!

.NET can Leak Managed Memory?

Quite certainly. But before we continue, let’s get one thing straight. The .NET garbage collector (GC for
short) is not the problem. The GC rocks. It is your friend. The only time .NET leaks managed memory is
through poor programming practice. There are many scenarios where poor programming can lead to
managed memory leaks. Chief among these are static references and events.

A complete exploration into the many ways these two code patterns manifest memory leaks is beyond
the scope of this product summary, however, the following code (in C#) illustrates the single most
common scenario plainly enough.

public class SomeClass
    public static event EventHandler SomeStaticEvent;

The simple pattern above may be the source of over 90% of managed memory leaks in .NET, since it is
employed in every single UI control suite on the market today. Couple this with the fact that the
remedy to the leak maybe one of the most common .NET bugs and what do you have? Catastrophe!
Whether in your own code or worse in a 3rd party UI package, this leak is subtle but deadly, as it can
chew through memory like a hoard of locust.



As stated, MemClean! must be directed toward leaky parts. This means you must know the culprit
holding onto memory (i.e. dangling references) preventing it from being garbage collected. Rarely is the
part left in memory the actual problem. More often, it’s another part holding a reference to the
apparent leak. You must perform managed memory analysis to reveal the problem to you (see
Managed Memory Analysis for details). With this intelligence in hand, MemClean! can be efficiently
and safely directed at the problem.


.NET Version Support

MemClean! can be used with .NET 2.0 or greater.


MemClean! is only to be used to save your life in the bleak twilight of the eleventh hour or when some
other software vendor has left you high and dry.

In no way should MemClean! be used in place of sound software engineering practice! Do NOT be a
code molester! Dispose of objects early and often. As a rule of thumb, if it has a Dispose, you best be
callin’ it. Give your poor GC a hand. Never use a finalizer unless you have unmanaged stuff (see
reference below).

Apply the best practice Dispose pattern where appropriate. If you write something that holds
unmanaged references, clean them up properly. If you’re not sure whether something is unmanaged or
not, perhaps you shouldn’t be using it.

The Mont says: “Don’t molest your code…”

See Also:

Future Features


Managed Memory Analysis

A Few Free Fixes...

Last edited Oct 2, 2009 at 3:48 AM by theMont, version 31