Is it necessary to dispose every ManagementObject?

Question

I noticed that ManagementObject is IDisposable, but it's also returned from ManagementClass.GetInstances() and ManagementObjectSearcher.Get(), does this mean I need to dispose each object encountered?

Like so:

ManagementObject ret;
foreach(ManagementObject mo in searcher.Get()) {
    if( IsWhatIWant(mo) ) ret = mo;
    else mo.Dispose();
}

Further confounding this: there's a bug in ManagementBaseObject where it does not correctly implement IDisposable (See Using clause fails to call Dispose? ) so you need to call it yourself, or use a wrapper around it that does correctly call it.

This is irritating because I have so many ManagementObjectCollections around.

Metsky

foreach through ManagementObjectCollections creates ManagementObjectEnumerator and that should be disposed, too. ugh – Electrodynamics

Answer 1

This is irritating because I have so many ManagementObjectCollections around.

Which has nothing to do with calling Dispose(), that only releases the underlying unmanaged COM objects. ManagementObjectCollection is a managed class, instances of it are garbage collected. Which is automatic, you can only help by calling GC.Collect(). Your program is probably just creating a lot of System.Management objects, possibly because that's the only thing it ever does. The quoted bug was fixed in the current versions of .NET 3.5SP1 and .NET 4.5 that I have installed on my machine.

So if you don't have a patched version of .NET then you don't only see a lot of System.Management objects on the GC heap, your process will also consume a lot of unmanaged memory. If the garbage collector doesn't run frequently enough then that can cause the program to crash with OOM. You didn't mention that as a failure mode so it is not strongly indicated that you have a real problem.

The initial size of generation 0 of the GC heap is 2 megabytes, it can grow to 8+ megabytes. That is a lot of ManagementObjectCollections objects, it is a very small object that takes only 24 bytes in 32-bit mode. The actual collection is unmanaged. Use Perfmon.exe or your memory profiler to check that the garbage collector is running frequently enough. If it doesn't then keep an eye on your program's VM size. If that's ballooning then using a counter in your query loop and calling GC.Collect() when it is high enough is a viable workaround. Careful with the info you get out of a memory profiler, it can irritate for the wrong reasons.

Reconciliatory

My question wasn't about memory - but the underlying unmanaged COM objects - there isn't any documentation that makes it clear what the consequences are of not calling ManagementObject.Dispose(). – Metsky

Answer 2

I've created a helper object to dispose all created management objects:

public class ManagementObjectDisposer : IDisposable
{
    private List<IDisposable> disposables = new List<IDisposable>();

    /// <summary>
    /// Workaround to dispose ManagementBaseObject properly.
    /// See http://stackoverflow.com/questions/11896282
    /// </summary>
    /// <param name="disposable"></param>
    public static void DisposeOne(IDisposable disposable)
    {
        ManagementBaseObject mbo = disposable as ManagementBaseObject;
        if (mbo != null)
            mbo.Dispose();
        else
            disposable.Dispose();
    }

    public void Dispose()
    {
        Exception firstException = null;
        foreach (IDisposable d in Enumerable.Reverse(disposables))
        {
            try
            {
                DisposeOne(d);
            }
            catch (Exception ex)
            {
                if (firstException == null)
                    firstException = ex;
                else
                    cvtLogger.GetLogger(this).Error($"Swallowing exception when disposing: {d.GetType()}", ex);
            }
        }
        disposables.Clear();
        if (firstException != null)
            throw firstException;
    }

    public T Add<T>(T disposable) where T : IDisposable
    {
        disposables.Add(disposable);
        return disposable;
    }

    /// <summary>
    /// Helper for ManagementObjectSearcher with adding all objects to the disposables.
    /// </summary>
    /// <param name="query">The query string.</param>
    public IEnumerable<ManagementBaseObject> Search(string query)
    {
        ManagementObjectSearcher searcher = this.Add(new ManagementObjectSearcher(query));
        return EnumerateCollection(searcher.Get());
    }

    /// <summary>
    /// Helper for adding ManagementObjectCollection and enumerating it.
    /// </summary>
    public IEnumerable<ManagementBaseObject> EnumerateCollection(ManagementObjectCollection collection)
    {
        this.Add(collection);
        ManagementObjectCollection.ManagementObjectEnumerator enumerator = this.Add(collection.GetEnumerator());
        while (enumerator.MoveNext())
            yield return this.Add(enumerator.Current);
    }
}

Just use it like:

using (var moDisposer = new ManagementObjectDisposer())
{
    foreach (var mobj = moDisposer.Search("SELECT * FROM Win32_Processor")
        Console.WriteLine(mobj["DeviceID"]);
}

Note: the ManagementClass.GetInstances() is easy to add to the ManagementObjectDisposer, too.

Electrodynamics

Answer 3

Actually the code from:

http://referencesource.microsoft.com/#System.Management/managementobjectcollection.cs

and also the Symbols from the Microsoft Symbol Server

http://msdl.microsoft.com/download/symbols

Imply ManagementObjectCollection is IDisposable which implies it is for some reason using unmanaged resources or it is incorrectly using the IDisposable interface.

Chopper

Answer 4

After two weeks of looking for a memory leak while working with WMI, the following solution helped:

using (ManagementObjectSearcher searcher = new ManagementObjectSearcher(scope, objectQuery, enumerationOptions))
using (ManagementObjectCollection collection = searcher.Get())
{
    foreach (ManagementBaseObject obj in collection)
    {
        using (obj) // calls Component.Dispose()
        {
            try
            {
                // Your code
            }
            finally
            {
                obj.Dispose(); // calls ManagementBaseObject.Dispose()
            }
        }
    }
}

The reason is in ManagementBaseObject.Dispose(), which is marked as new, so using doesn't call it. So ManagementBaseObject.Dispose() was called by the finalizer (GC). With a huge amount of ManagementBaseObject (thousands per second) in a highly loaded system after a couple of days, the duration of the finalizers became more than an hour, which caused memory leak, OutOfMemoryException and application termination. This issue is still present in .Net Framework 4.8.

Theoretically, you can remove using for ManagementBaseObject, because ManagementBaseObject.Dispose() calls the base Dispose(), but who knows what surprises are in other versions of .Net

Also, the Dispose method is marked as new in the inherited classes: ManagementObject and ManagementClass.

Guttersnipe

Answer 5

If you do a lot of WMI queries you should always dispose the return ManagementObjectCollection to avoid Quota violation exceptions.

System.Management.ManagementException: Quota violation
at System.Management.ManagementException.ThrowWithExtendedInfo(ManagementStatus errorCode)
at System.Management.ManagementObjectCollection.ManagementObjectEnumerator.MoveNext()

Saccular

Answer 6

The ultimate answer to the question is yes. You have to release the objects held by a ManagementObjectCollection.
Here's why:

If you look into the ManagementObjectCollection.Dispose() method, you'll see it calls Marshal.ReleaseComObject() on 'enumWbem'.

private void Dispose ( bool disposing )
{
    if ( disposing )
    {
        GC.SuppressFinalize (this);
        isDisposed = true;
    }
    Marshal.ReleaseComObject (enumWbem);
}

'enumWbem' is a Runtime Callable Wrapper of the interface IEnumWbemClassObject.
On the implementation example found here they release every object prior to releasing the IEnumWbemClassObject.

Furthermore, on the ManagementBaseObject signature, the Dispose() method looks like this:

public new void Dispose()
{
    if (_wbemObject != null)
    {
        _wbemObject.Dispose();
        _wbemObject = null;
    }
    base.Dispose();
    GC.SuppressFinalize(this);
}

Where _wbemObject is a IWbemClassObjectFreeThreaded, so Dispose() will call Marshal.ReleaseComObject(), and base.Dispose() calls the 'Component' class Dispose().

My C# knowledge is week on this one, but this is what the virtual method looks like:

protected virtual void Dispose(bool disposing) {
    if (disposing) {
        lock(this) {
            if (site != null && site.Container != null) {
                site.Container.Remove(this);
            }
            if (events != null) {
                EventHandler handler = (EventHandler)events[EventDisposed];
                if (handler != null) handler(this, EventArgs.Empty);
            }
        }
    }
}

I know that freeing every single object is a pain, but dealing with COM overall is :D.
You can use a helper class, and structure your code accordingly, to avoid memory leaks.

Hope it helps!

Ninette