detect client process termination from EXE COM Server

Question

I'm writing an EXE COM Server that exposes a class that lock a system resource. In normal execution the client release the resource (the COM executable shutsdown a couple of seconds later. In abnormal execution, the client app crashes, leaving the com sever with an instance having a positive reference count. The COM executable runs for ~12 minutes until termination. This means that the system resource is locked during this time.

Is there a way to detect client termination instantaneously, as in socket IPC or driver protocol? if not it would seem that COM is inferior to other IPC mechanisms.

Answer 1

I had the same question a couple of years ago. I found the answer here: How To Turn Off the COM Garbage Collection Mechanism. In short: no, there is no way to detect client termination instantaneously. Excerpts:

When a COM client terminates normally, it releases all references to its server object. When a client terminates abnormally however, there might be outstanding references to the server object. Without a garbage collection mechanism, the server code has no way of knowing when to reclaim the resources allocated for the COM object, which can then cause a resource leak. To address this problem, COM implements an automatic garbage collection mechanism in which the COM resolver process (RPCSS) on the client machine pings the server machine on behalf of the client process.

Alternatives to using COM's GC protocol (for example, using periodic application-level "pings"--method calls that inform the object that clients are still alive, or using an underlying transport mechanism such as TCP keepalives) are demonstrably much less efficient. Therefore, DCOM's default GC mechanism should be used for any objects that must be shut down when their clients disappear or otherwise misbehave if those objects would effectively become memory leaks on the server.

The resolver on the server machine keeps track of the pings for each server object. The ping period is 2 minutes and, currently, it is non- configurable. When the resolver on the server machine detects that an object has not been pinged for 6 minutes, it assumes that all clients of the object have terminated or otherwise are no longer using the object. The resolver will then release all external references to the object. It does this by simply having the object's stub manager (the COM runtime code that delivers calls to each object) call ::Release() on the object's IUnknown interface. At this point, the object's reference count will be zero so far as the COM runtime is concerned. (There may still be references held by local (same-apartment) clients, so the object's internal reference count may not necessarily go to zero at this point.) The object may then shut itself down.

NOTE: Garbage collection applies to all servers regardless of whether their clients are local or remote, or a combination of local and remote. The underlying pinging mechanism is different in the local case as no network packets are generated, but for all practical purposes, the behavior is the same.