What Exactly Are Unmanaged Resources

What exactly are unmanaged resources?

Managed resources basically means "managed memory" that is managed by the garbage collector. When you no longer have any references to a managed object (which uses managed memory), the garbage collector will (eventually) release that memory for you.

Unmanaged resources are then everything that the garbage collector does not know about. For example:

• Open files
• Open network connections
• Unmanaged memory
• In XNA: vertex buffers, index buffers, textures, etc.

Normally you want to release those unmanaged resources before you lose all the references you have to the object managing them. You do this by calling Dispose on that object, or (in C#) using the using statement which will handle calling Dispose for you.

If you neglect to Dispose of your unmanaged resources correctly, the garbage collector will eventually handle it for you when the object containing that resource is garbage collected (this is "finalization"). But because the garbage collector doesn't know about the unmanaged resources, it can't tell how badly it needs to release them - so it's possible for your program to perform poorly or run out of resources entirely.

If you implement a class yourself that handles unmanaged resources, it is up to you to implement Dispose and Finalize correctly.

What are managed resources and unmanaged resources?

Managed resources are those that are fully written in .NET. Though not normally subject to classic memory leaks, one can still leak memory by not dereferencing unused resources (the most common reason is to not un-register event handlers).

Unmanaged resources are those that are generally those that are not pure .NET (and in the same process) - examples are:

• COM components
• Database connections/transactions
• Window handles
• Filesystem handles
• Registry handles
• Network connections
• etc... etc...

For these, you need to implement the Dispose pattern, correctly and ensure proper disposal when you have finished using them.

Do we really need to worry about memory leaks or not?

Yes, we do need to worry about them, in particular when going outside of .NET.

What is meant by managed vs unmanaged resources in .NET?

The term "unmanaged resource" is usually used to describe something not directly under the control of the garbage collector. For example, if you open a connection to a database server this will use resources on the server (for maintaining the connection) and possibly other non-.net resources on the client machine, if the provider isn't written entirely in managed code.

This is why, for something like a database connection, it's recommended you write your code thusly:

using (var connection = new SqlConnection("connection_string_here"))
{
    // Code to use connection here
}

As this ensures that .Dispose() is called on the connection object, ensuring that any unmanaged resources are cleaned up.

How can I tell if a resource is unmanaged?

It's the other way around.

First, all types you work with in .NET are managed. But some managed types encapsulate unmanaged resources, such as Windows handles.

The types that encapsulate unmanaged resources, usually implement IDisposable. The IDisposable interface lets you explicitly release unmanaged resources held by these objects, by either calling Dispose(), or putting them in using. In the latter case, Dispose() is called automatically when exiting the scope of the using.

In any way, even if Dispose() is not called on an object that implements it, well designed classes should release their unmanaged resources in Finalize() (which is basically destructor). But Finalize() is invoked by the GC, and we don't know how often the GC is invoked, which meakes the process of releasing resources non-deterministic. Without IDisposable, we'd hold expensive unmanaged resources for extended periods of time, much more than might be necessary.

When a type doesn't implement IDisposable, it is an indication that it holds no unmanaged resources, and it has no reason to be explicitly disposed (provided the type is well-designed, of course).

Note that some types that implement IDisposable don't actually hold any unmanaged resources. For example, a class that measures time of execution can implement IDisposable, so that it saves a timestamp in constructor, then in Dispose it takes current timestamp and calculates elapsed time and reports it to some logging mechanism. When you put such a class inside using, you get a convenient way of measuring execution time of your code blocks.

What counts as an Unmanaged Resource in the Disposable pattern?

I understand the confusion. I think there are a few simple guidelines to follow:

1. If your class "owns" a reference to another object (i.e. your object created the other object, or was given the reference to that object with the understanding that your object now "owns" it), then you are responsible for doing any necessary cleanup (if any)

2. If that other object is a .NET object and does not implement the IDisposable interface, then you probably don't need to do anything. The IDisposable interface is, by convention, the interface that we use to declare whether or not our objects require cleanup.

3. If that other object is a .NET object and implements the IDisposable interface, then your class should also implement the IDisposable interface. In your Dispose method, just call the Dispose method of the other object.

4. If that other object is an unmanaged object or resource, then your class should implement a finalizer to ensure that the unmanaged object / resource will get cleaned up. Follow the guidelines described in that blog post for how to implement that.

Below are some specific answers to your questions.

• At some point, .NET is just wrapping Win32 calls, right? So aren't most of the .NET objects in a way an Unmanaged Resource?

Even though a .NET object may wrap Win32 calls, the term "Unmanaged Resource" is not appropriate because it is a .NET object, therefore it is by definition a "Managed Resource". The CLR handles the memory allocation and garbage collection for those objects.

• What about COM objects that we have .NET wrappers for -- what are they considered?

.NET wrapper objects are still .NET objects, so they are "managed resources", but note that they must implement their own dispose/finalize logic. Basically, they take care of cleaning up the "unmanaged resources" so that you don't have to. If you were implementing your own wrapper for a COM object, then you would be responsible for implementing the necessary dispose/finalize logic to clean it up, so that the consumers of your wrapper don't have to.

• What about managed classes that get functionality solely from P/Invokes?

A managed class that uses P/Invoke to call unmanaged code might be allocating unmanaged resources, depending on what it is calling. Therefore, it may be necessary for it to implement the necessary dispose/finalize logic to clean up those unmanaged resources.

• What about C++/CLI classes that internally use native libraries?

Yes, those also may be allocating unmanaged resources from the native libraries, so it would also be necessary for them to implement the necessary destructor/finalizer logic.

• At the C# level, the C++/CLI classes that had destructors now implement IDisposable... what are they considered?

In C++/CLI, you can choose to declare a class as either managed (with the ref keyword) or unmanaged (without the ref keyword). If it's declared with the ref keyword, then it is a managed class; it will be allocated on the managed heap and will be cleaned up by the garbage collector once it falls out of scope and there are no more references to it. If the class is declared without the ref keyword, then it is unmanaged and must be explicitly cleaned up. In either case, the class might have allocated unmanaged resources that need to be cleaned up in the destructor/finalizer.

Managed vs Unmanaged Resources in .NET. What's the difference?

You got it right:

Managed resources are managed by the CLR, unmanaged aren't. In other words: Managed resources live only in the .NET world where as unmanaged resources are from the normal Win32 world.

What C# class objects acquire unmanaged resources? Is there a list?

Obviously I don't want to start calling Dispose() on every object in

Wrong.

In general, any object that implements IDisposable should be disposed as soon as you're finished with it, typically using the using statement.

Most objects that do not have unmanaged resources do not implement IDisposable (and do not have Dispose() methods), so you have nothing to worry about.

The only exceptions are base classes that implement IDisposable in case some derived implementations have something to dispose (eg, IEnumerator, Component, or TextReader).

However, it is not always obvious which concrete implementations need to be disposed (and it may change at any time), so you should always dispose them anyway.

How do we distinguish between managed and unmanaged resources in C#? Is TextFieldParser unmanaged?

You're missing the point. Whenever any class implements IDisposable, you should call Dispose when you're done with it.

Whether the class uses unmanaged resources or not is internal to the class, you shouldn't care about it at all. Every class that uses unmanaged resources should also have a finalizer that clears up those unmanaged resources if you didn't dispose of the class explicitly. Dispose just allows you to clean its resources (both managed and unmanaged, though this doesn't necessarily mean freeing up the memory immediately) in a more deterministic and immediate fashion. For example, Disposeing a FileStream will release the file handle immediately, while if you don't Dispose (or Close), the file will be opened until the next collection and finalization.

EDIT:

To show that Dispose may also be necessary to clean up managed resources, we only have to look at event handlers. In particular, the case when you're subscribing on an event of a class that has a longer lifetime than you do:

var control = new MyHelperControl();
MyParentForm.Click += control.DoSomething();

Now, even if control goes out of scope, it will survive as long as MyParentForm - it's still referenced by the event handler. The same problem grows to absurd proportions when the parent has the same lifetime as the whole application - that's can be a huge memory leak. An example would be registering event handlers on the main form of an application, or on a static event.

There might also be other things that happen in the Dispose. For example, again with Windows forms, when you call Dispose on a Control, a whole lot of things happen:

• All the unmanaged resources are released. Since Winforms controls are wrappers of the native controls to an extent, this is usually a lot of resources - the control itself, any pens, brushes, images... all of those are native resources. They will also be released if you forget a Dispose, since they all have finalizers, but it might take more time - which is especially painful when you create and destroy a lot of those objects. For example, there's a limited supply of GDI+ object handles, and if you run out, you get OutOfMemoryException and you're out.
• Dispose of all sub-controls.
• Remove any context menu handlers (remember, context menu is a separate component that's only linked to another control).
• Remove any data bindings.
• Remove itself from the parent container, if any.
• If the control is a window with its own message loop, kill the message loop.

The funny part is that the unmanaged resources matter the least, really - they always have a finalizer. The managed resources are trickier, because you're more or less forbidden to handle managed references in a finalizer (because they might have already been released, or they might be in the middle of being released, or they might start being released in the middle of your finalizer... it's complicated). So doing MyParentForm.Click -= this.OnClick; is not a good thing to have in your finalizer - not to mention that it would require you to make every such class finalizable, which isn't exactly free, especially when you expect the finalizer to actually run (when you do a Dispose, the GC is alerted that this instance no longer needs a finalization).

Can any one explain why StreamWriter is an Unmanaged Resource.

StreamWriter is not an unmanged resource, its a .NET class, and it is 100% managed.

Another totally different thing is that StreamWriter might internally use unmanaged resources or own an IDisposable object that in turn might use an unmanaged resource, or simply extends a class that implements IDisposable.

The latter two are the reasons why StreamWriter implements IDisposable, but beware, implementing IDisposable does not necessarily mean that the class uses directly or indirectly unmanaged resources.

In the particular case of StreamWriter, it is obvious that it might indirectly consume unmanged resources; the underlying stream (the IDisposable instance field Stream stream) could be a FileStream which obviously consumes unmanaged resources (a file in your HD for instance). But its also very possible that the underlying stream doesn't use any unmanaged resources, but as Colin Mackay correctly points out in commentaries below, all streams must implement a consistent interface which the abstract class Stream provides.

Where unmanaged resources are allocated

Essentially the heap is the same speaking from the operating system view: the memory space assigned to the OS process.

The difference is that when the CLR (.net VM) loads inside a Windows process it takes a piece of this heap and turns it into a managed heap. This memory space becomes the place where all managed resources are allocated and known to the garbage collector.

For instance, you can run into a Out of Memory error if you allocate a big chunk of unmanaged memory and run out of space for your managed heap. Or the other way around.

Jeffrey Richter is the guy that better explains this stuff. I highly recommend reading his explanation:

• Garbage Collection: Automatic Memory Management in the Microsoft .NET Framework
• Garbage Collection Part 2: Automatic Memory Management in the Microsoft .NET Framework

You can use the services of the System.InteropServices namespace, the Marshal class specifically, to copy data between the unmanaged part of the heap and the managed.

---

Related Topics