Everyone who knows me knows that I have a special interest for memory leaks in .Net. At the company where I work we have solved a lot of these issues and I’ve also had talks about this at Norwegian .Net User Group (NNUG) in Bergen and Stavanger. One of our biggest problems was memory leaks related to events. Rico Mariani (MS performance guru) has set focus on this in his blog today by this blog post, so go check it out!

He focuses on the issue related to event generators, but there are other areas where you can get into trouble as well. I’ll try to explain our scenario:

1. We have a graphical engine responsible for creating graphical components (user controls) dynamically by using reflection.
2. All of these user controls inherit from the same class which exposes a lot of events.
3. When our graphical engine creates new instances of these user controls it hooks up these events.

This model is created to have loose coupling between the user controls, the engine and other components we have in our app. The engine has a lot of knowledge about other components and services in our app, which sometimes our user controls wants to communicate with. This communication is done through these events. Here’s an example:

I have a user control that wants to tell a service that he have made some changes the service should know about. For this we have created a special event on the user control that the engine listens to. So I trigger this event on the user control, the engine receives it and tells the service about it.

These event hookups caused us a lot of pain at some point. Our solution was the first that Rico mentioned in his blog post (IDisposable), which I personally would prefer. In addition to this we added some reflection code which found events and removed them. You’ll find more info about this here: http://channel9vip.orcsweb.com/ShowPost.aspx?PostID=180985

Before I end I want to recommend two tools you can use to find memory leaks in .net. The first one which we use is called .Net Memory Profiler. The other one which I’ve not personally used but I’ve heard others are using is the ANTS Profiler. So go find your leaks. Happy hunting!

On Thursday 7th of November I’m having a lecture about Memory Leaks in .Net at NNUG in Stavanger. In addition to memory leaks Per-Ove Joakimsen (from WebStep and leader of NNUG in Stavanger) is talking about his experience at TechEd in Barcelona. He’s also doing a short intro to WPF, WCF and LINQ. Go to http://www.nnug.no/Avdelinger/Stavanger/Moter/Brukergruppemote-desember-2006/ to register for the event.

If you don’t live in Stavanger but another city in Norway and are interested in .Net, don’t forget to register at http://www.nnug.no/Profil/RegistrerDeg/ and you will be updated on NNUG happenings in your city. As of now we have NNUG in Bergen, Kristiansand, Oslo, Stavanger, Tromsø, Trondheim and Vestfold. For those of you who don’t know about NNUG, it is an independent INETA .Net usergroup. These usergroups exist all over the world, so if you live outside of Norway, look it up and you probably find a user group near you. If not you can start one!

In my last post about memory leaks, I emphasized the importance of calling Dispose. This time I’m going to talk about how you can see how much memory your application is using.

You probably think that I think you’re stupid… Right? Right now you say to your self

Of course I know where to find my app’s memory usage! I’m not f$£@&g stupid!

Ok. I get it. You of course go to the task manager and look at the memory usage column for you app. Right? Wrong. Don’t do that. It dos not tell you anything about your app’s memory usage. Why? First here’s an example to make a point (or rub it in…):

.Net application just started.

Here I have started my test application and as you see it has a memory usage of 11 696K.

The funny thing is that if you minimize the application it only has a memory usage of 812 K.

.Net application minimized.

What happened? Did all my objects just disappear when I minimized my app. I don’t think so! The problem is that Mem Usage equals working set (http://support.microsoft.com/kb/293215). And what dos working set tell you? One of the more common definitions of working set is;

The working set of a process is defined as the number of virtual memory pages that it is allowed to keep resident in RAM.

In other words; it dos not tell you how much memory your app are using.

Now we know that Mem Usage is not much use to us, what CAN we use? What you want is your applications private memory. Private memory is the actual space in memory your application use. And as it happens, you can find that column in Task Manager as well… Only it’s called Virtual Memory. Go figure. In Task Manager go to View -> Select Columns…, and select Virtual Memory.

So my advice to you is to get rid of the Mem Usage column and replace it with Virtual Memory. Do this on all the computers at your office and tell everyone!

At Wednesday 18th of October we will have a new meeting at NNUG in Bergen where Bård Strøm will talk about Agile development and I about Memory Leaks in .Net.

Agile development
In Norway agile development gain more and more popularity. Statistics show that 3 out of 10 software projects are delivered as ordered, but 7 out of 10 fail completely or partly. Based on techniques like extreme programming, agile development presents techniques to create products not only with higher quality but delivery on time, to the customer’s satisfaction.

Bård will talk more about this in his talk, so don’t miss out on this.

Memory Leaks in .Net
In a previous post in my blog I talked a bit about memory leaks and the importance of the dispose pattern. At my talk at NNUG I will go into the heart of the problem, show you the tools necessary to detect these leaks, demo common coding mistakes and show you some guidelines on how to avoid these errors in your software.

So if you live in Bergen, Norway don't miss this out. Go to http://www.nnug.no/Avdelinger/Bergen/Moter/Brukergruppemote-Oktober/ to register.

"Hi! There are no memory leaks in .Net! It has that great garbage collector everyone's talking about! And the dispose pattern and all that".

Not very likely that a person actually uttered this, but it’s a great start for a discussion. I’ll start mentioning some normal miss conceptions about GC, Dispose and that "stuff":

• The garbage collector cleans up everything you keep laying around and you don’t need to worry about it.
• If you just do your cleanup in Dispose the GC will call dispose for you.
• If you really want to be sure, do your cleanup in the destructor and your home free.

Nice! Lets just do this and we can all go home… Or you can read on…:

• The garbage collector cleans up everything you don’t use anymore. That is all objects not referenced by your running program.
• If you do your cleanup in Dispose, YOU have to remember to call it! Not only that, if you use objects that have Dispose methods, you need to call them as well!
• You can do cleanup in the destructor, but it’s much more efficient to use the Dispose pattern. More on this later.

I think most of us know that the garbage collector only releases objects with no running references to it. What’s interesting though is that not everyone knows that you have to call Dispose on all objects that have a Dispose method! I can not emphasize this enough (even though I tried with bold text).

You have a gene in your body as developer to call Close methods (on file handles, data connection etc), but no one ever mentioned Dispose for you. Or you where told that the GC call Dispose for you, or something else that sounded good at the moment.