Release Com Object(Object) Method
Decrements the reference count of the Runtime Callable Wrapper (RCW) associated with the specified COM object.
public: static int ReleaseComObject(System::Object ^ o);
[System.Security.SecurityCritical] public static int ReleaseComObject (object o);
public static int ReleaseComObject (object o);
static member ReleaseComObject : obj -> int
Public Shared Function ReleaseComObject (o As Object) As Integer
The COM object to release.
The new value of the reference count of the RCW associated with
o. This value is typically zero since the RCW keeps just one reference to the wrapped COM object regardless of the number of managed clients calling it.
o is not a valid COM object.
This method is used to explicitly control the lifetime of a COM object used from managed code. You should use this method to free the underlying COM object that holds references to resources in a timely manner or when objects must be freed in a specific order.
Every time a COM interface pointer enters the common language runtime (CLR), it is wrapped in an RCW.
The RCW has a reference count that is incremented every time a COM interface pointer is mapped to it. The ReleaseComObject method decrements the reference count of an RCW. When the reference count reaches zero, the runtime releases all its references on the unmanaged COM object, and throws a System.NullReferenceException if you attempt to use the object further. If the same COM interface is passed more than one time from unmanaged to managed code, the reference count on the wrapper is incremented every time, and calling ReleaseComObject returns the number of remaining references.
This method enables you to force an RCW reference count release so that it occurs precisely when you want it to. However, improper use of ReleaseComObject may cause your application to fail, or may cause an access violation.
Consider a scenario in which managed code in an application domain is holding onto an RCW that represents a COM component. If you call the ReleaseComObject method on the RCW, the managed code will be unable to access the RCW and will raise an InvalidComObjectException exception.
A more serious error may occur if a call to the RCW is executing when the RCW is released. In this case, there is a good chance that the thread making the call will cause an access violation. However, process memory may become corrupted, and the process may continue to run until it fails for reasons that are very difficult to debug.
This risk is compounded when the COM component that is being used is a singleton, for the following reason: The CLR activates COM components by calling the COM CoCreateInstance function, which returns the same interface pointer every time it is called for singleton COM components. Thus, separate and independent pieces of managed code in an application domain can be using the same RCW for a singleton COM component, and if either one calls the ReleaseComObject method on the COM component, the other will be broken.
Therefore, use the ReleaseComObject only if it is absolutely required. If you want to call this method to ensure that a COM component is released at a determined time, consider using the FinalReleaseComObject method instead. FinalReleaseComObject will release the underlying COM component regardless of how many times it has re-entered the CLR. The internal reference count of the RCW is incremented by one every time the COM component re-enters the CLR. Therefore, you could call the ReleaseComObject method in a loop until the value returned is zero. This achieves the same result as the FinalReleaseComObject method.