Have you ever encountered a scenario where you have a COM server that you just want to get cleaned up right away and not have to wait for DCOM Garbage Collection (DCOM GC) to kick in?  Well, starting with Windows 8 / Windows Server 2012 you can.  You can opt-in to the fast rundown path using the IGlobalOptions interface.  Here is a code snippet on how to opt-in.  Just put this in in your COM server’s initialization code.

        IGlobalOptions* pGlobalOptions = NULL;
        HRESULT hr = CoCreateInstance(CLSID_GlobalOptions, NULL, CLSCTX_INPROC_SERVER, IID_PPV_ARGS(&pGlobalOptions));
        if (SUCCEEDED(hr))
        {
            pGlobalOptions->Set(COMGLB_RO_SETTINGS, COMGLB_FAST_RUNDOWN);
        }

        pGlobalOptions->Release();
        pGlobalOptions = NULL;

A rundown is the process by with the RpcSs (RPC Server Service) calls release on COM stubs within a COM server application to release resources maintained by that COM stub.  See this documentation for more information on COM stubs.  By setting the global flag COMGLB_FAST_RUNDOWN all of the COM stubs in this COM server will be subject to the fast rundown behavior which means that stubs are run down on termination of the client process.  This can be useful particularly in a case where a COM client might terminate abnormally and not call release on any COM proxies that it still references, e.g. a case where a COM client has crashed due to an unhandled exception.

It should be noted that the fast rundown path only works if the COM client and server are on the same machine.  For remote COM stubs this will not work and rundown will still be governed by the normal DCOM garbage collection process.  Just as I did, you might wonder why this won’t work for remote COM servers.  My best guess is this.  DCOM Garbage Collection is performed through a pinging process where the client machine’s RpcSs service will ping the remote server’s RpcSs service to let it know the client is still alive. In the remote case the remote RpcSs service (running on the COM server machine) is responsible for running down stubs in the remote COM server, but the remote RpcSs service has no idea of when the client will exit since the client executable is running on a different machine.

What if you are not able to set this global flag, i.e. your have a COM DLL that is acts as a plug-in to another application?  In this case you are not the owner of the COM server code and can’t set this global flag during process initialization.  Even if you could set this global flag I don’t think the application owner would want you setting a global flag that would impact other plug-ins.  In this case you can opt-in to the fast rundown behavior for just your COM objects by implementing the IFastRundown marker interface.