RCW & reference counting when using COM interop in C#

Question

I have an application that uses Office interop assemblies. I am aware about the "Runtime Callable Wrapper (RCW)" managed by the runtime. But I am not very sure how the reference count gets incremented. MSDN says,

RCW keeps just one reference to the wrapped COM object regardless of the number of managed clients calling it.

If I understand it correctly, on the following example,

using Microsoft.Office.Interop.Word;

static void Foo(Application wrd)
{
    /* .... */
}

static void Main(string[] args)
{
    var wrd = new Application();
    Foo(wrd);
    /* .... */
}

I am passing the instance wrd to another method. But this doesn't increment the internal reference count. So I am wondering on what scenarios the reference count gets incremented? Can anyone point out a scenario where the reference count gets incremented?

Also I read some blog which says avoid using double dots when programming with COM objects. Something like, wrd.ActiveDocument.ActiveWindow. The author claims that compiler creates separate variables to hold the values which will increment the reference counter. IMHO, this is wrong and the first example proves this. Is that correct?

Any help would be great!

Solution 1

I have been researching this question too, working on a COM/.Net-Interop-centric application, fighting leaks, hangs and crashes.

Short answer: Every time the COM object is passed from COM environment to .NET.

Long answer:

1. For each COM object there is one RCW object [Test 1] [Ref 4]
2. Reference count is incremented each time the object is requested from within COM object (calling property or method on COM object that return COM object, the returned COM object reference count will be incremented by one) [Test 1]
3. Reference count is not incremented by casting to other COM interfaces of the object or moving the RCW reference around [Test 2]
4. Reference count is incremented each time an object is passed as a parameter in event raised by COM [Ref 1]

On a side note: You should ALWAYS release COM objects as soon as you are finished using them. Leaving this work to the GC can lead to leaks, unexpected behavior and event deadlocks. This is tenfold more important if you access object not on the STA thread it was created on. [Ref 2] [Ref 3] [Painful personal experience]

I'm hope I have covered all cases, but COM is a tough cookie. Cheers.

Test 1 - reference count

private void Test1( _Application outlookApp )
{
    var explorer1 = outlookApp.ActiveExplorer();
    var count1 = Marshal.ReleaseComObject(explorer1);
    MessageBox.Show("Count 1:" + count1);

    var explorer2 = outlookApp.ActiveExplorer();
    var explorer3 = outlookApp.ActiveExplorer();
    var explorer4 = outlookApp.ActiveExplorer();

    var equals = explorer2 == explorer3 && ReferenceEquals(explorer2, explorer4);
    var count2 = Marshal.ReleaseComObject(explorer4);
    MessageBox.Show("Count 2:" + count2 + ", Equals: " + equals);
}
Output:
Count 1: 4
Count 2: 6, Equals: True

Test 2 - reference count cont.

private static void Test2(_Application outlookApp)
{
    var explorer1 = outlookApp.ActiveExplorer();
    var count1 = Marshal.ReleaseComObject(explorer1);
    MessageBox.Show("Count 1:" + count1);

    var explorer2 = outlookApp.ActiveExplorer();

    var explorer3 = explorer2 as _Explorer;
    var explorer4 = (ExplorerEvents_10_Event)explorer2;
    var explorerObject = (object)explorer2;
    var explorer5 = (Explorer)explorerObject;

    var equals = explorer2 == explorer3 && ReferenceEquals(explorer2, explorer5);
    var count2 = Marshal.ReleaseComObject(explorer4);
    MessageBox.Show("Count 2:" + count2 + ", Equals: " + equals);
}
Output:
Count 1: 4
Count 2: 4, Equals: True

Sources I relay on in addition to my experience and testing:

1. Johannes Passing's - RCW Reference Counting Rules != COM Reference Counting Rules

2. Eran Sandler - Runtime Callable Wrapper Internals and common pitfalls

3. Eran Sandler - Marshal.ReleaseComObject and CPU Spinning

4. MSDN - Runtime Callable Wrapper

Solution 2

You shouldn't need any special treatment. The runtime only keeps one reference to the COM object. The reason for this is that the GC tracks all managed references, so when the RCW goes out of scope and is collected, the COM reference is released. When you pass around a managed reference, the GC is tracking it for you - this is one of the biggest advantages of a GC-based runtime over the old AddRef/Release scheme.

You don't need to manually call Marshal.ReleaseComObject unless you want more deterministic release.

Solution 3

The accepted solution is valid, but here's some additional background information.

A RCW contains one or more native COM object interface references internally for its COM object.

When a RCW releases its underlying COM object, either due to getting garbage collected or due to Marshal.ReleaseComObject() getting called on it, it releases all of its internally held COM object interfaces.

There are actually many reference counts here - one determining when .NET's RCW should release its underlying COM object interfaces, and then each of those raw COM interfaces has its own reference count as in regular COM.

Here's code to get raw COM IUnknown interface reference count:

int getIUnknownReferenceCount(object comobject)
{
    var iUnknown = Marshal.GetIUnknownForObject(comObject);
    return Marshal.Release(iUnknown);
}

And you can get the same for the object's other COM interfaces using Marshal.GetComInterfaceForObject().

In addition to the ways listed in the accepted solution, we can also increase the .NET RCW reference count artificially by calling something like Marshal.GetObjectForIUnknown().

Here's example code making use of that technique to get a given COM object's RCW reference count:

int comObjectReferenceCount(object comObject)
{
    var iUnknown = Marshal.GetIUnknownForObject(comObject);
    Marshal.GetObjectForIUnknown(iUnknown);
    Marshal.Release(iUnknown);
    return Marshal.ReleaseComObject(comObject);
}

Comments

[Navaneeth K N]

thanks, but this doesn't answer the question. I am aware about Marshal.ReleaseComObject and Marshal.FinalReleaseComObject methods. My question was more about how the internal reference count works and at what point it get incremented.

[Navaneeth K N]

Question is not about the usage of Marshal.ReleaseComObject or something similar. I was trying to understand how the reference counting works and at what point it will be incremented.

[codekaizen]

Precisely. If you read again, you'll note that I say exactly this. There is only one COM reference. It never gets incremented. All tracking of the RCW is done by the GC.

[hypersw]

These tests do not take into account the fact that there are actually TWO reference counters, the real native one of the COM object (which should only be incremented once by CLR) and the managed reference couter within the RCW which counts smth like the number of times the object were passed from the native world (i.e. the number of times you'd want to call ReleaseComObject). Your test only measures the latter, which is but a partial answer to the question.