Memory/Resource Leaks in .NET

[Barry Etter]

Back in my C++ days, I relied on BoundsChecker to help identify potential memory leaks and resource leaks since I write mainly server-based services that run 24x7. With .NET, managed code and garbage collection, is there still a need for these third-party tools? What's your experience? Also, can someone explain this...I have a console .NET application that starts up taking around 9K of memory. By the time everything gets loaded, Task Manager shows it taking around 20K. Fine. But when the console window is minimized, the memory (as reported by Task Manager goes down to like 3K! WTF?! Barry Etter

[Steve Maier]

Well the suite that BoundsChecker is in is changing to more of a profiling and performance tool. They actually have a free profiler (community edition) for VS.Net. Its not the best, but its not bad either. Compuware [^] As for you memory question, if you look at any application, esp VS.Net when its up and then minimize it and there will be a difference in the memory used. I think that this is due to the OS getting rid of some of the memory pages that it does not need. I have observed this with all windows apps, not just console apps. Steve Maier, MCSD MCAD

[Heath Stewart]

Yes there is such a use, but a CLR profiler is a better choice. Many classes in the .NET BCL (and third-party libraries) rely on native resources. These are unmanaged resources because the CLR does not manage them. File handles are a good example. FileStream (actually, any String) implements IDisposable because there may be a file handle (there is for a FileStream) or some other native resource that must be closed when finished. You must call the IDisposable.Dispose implementation when finished with such an object. If you are a class designer, you should follow the dispose pattern discussed in the .NET Framework SDK and other articles:

class MyObject : IDisposable
{
~MyObject()
{
Dispose(false);
}
void IDisposable.Dispose()
{
Dispose(true);
}
protected virtual void Dispose(bool disposing)
{
if (disposing)
{
// Release managed resources.
}
// Release unmanaged resources.
}
}

Unmanaged resources will be freed aventually. There is no gaurantee of when the GC runs, however, and you should almost never call GC.Collect (repeated calls can greatly hinder the performance of your application). This is why IDisposable exists. The using block statement is good to make sure that - even in case of exception - your objects are disposed:

using (FileStream file = File.Open("file.txt", FileMode.Open))
{
// Do something with 'file'.
}

Is the same as:

FileStream file = File.Open("file.txt", FileMode.Open));
try
{
// Do something with 'file'.
}
finally
{
if (file != null) ((IDisposable)file).Dispose(0;
}

So, exceptions will still be thrown, but at least the file is disposed and the native file handle is released. So, in a round-about way, you should be able to see that while objects are garbage collected, resources they use (i.e., unmanaged resources) are not. Using a profile will help you find those problems, although it's a good rule of thumb to always dispose of any object that implements IDisposable anywhere up the class inheritance hierarchy. Profilers can also help you find bottlenecks in your code; any platform is susceptible to that since it's typically human fault. This posting is provided "AS IS" with no warranties, and confers no rights. Software Design Engineer Developer Division Sustained Engineering Microsoft