What happens to my COM server-side object when clients die unexpectedly?

Suppose you have a COM server object that runs out-of-process. A client connects to the COM server and creates an object. And then the client crashes. What happens to the server object?

It will get released eventually.

COM periodically checks whether the clients are still alive, and it runs down interfaces from dead clients. Run-down (often spelled rundown) is a technical term used by COM to refer to cleaning up abandoned objects.

Knowledge Base 171414 describes the mechanism in some detail. (There are a bunch of optimizations in play here. You can read the Knowledge Base article to learn about some of them.) The short version is that every two minutes, the COM client pings the server to say, "Hey, I'm still alive." If the COM server doesn't hear from the client for six minutes, then it assumes that the client is dead and runs down the objects for that client.

Therefore, if a client dies, your server object will be cleaned up between six and twelve (eight?) minutes later.

Comments (11)
  1. ifm says:

    The ping do correct bounds checking I hope.

  2. Nick says:

    Of course Microsoft's heart bleeds, when a client dies!

  3. Both "six to twelve minutes" and "six to eight minutes" seem wrong. The answer is actually "four to six minutes" as stated.

  4. Pat says:

    less than six minutes

    Better case: Just before ping : 0 minutes

    Worst case: Just after ping : 6 minutes

  5. Alex says:

    Four to six minutes is right.

    Minute 0: Last known ping

    Minute 2: Server doesn't receive ping; believes Client may have been dead for 2 minutes.

    Minute 4: Server doesn't receive ping; believes Client may have been dead for 4 minutes.

    Minute 6: Server doesn't receive ping; believes Client may have been dead for 6 minutes. Server runs down Client's objects.

    If the client died at Minute 0 just after its ping, it'll have been dead for 6 minutes when the server runs down. If it died just before its next ping at minute 2, it'll have been dead for 4 minutes

  6. Joshua says:

    Alex is omitting ping transit time, usually max transit time is 120 seconds (2 minutes).

  7. Dominic says:

    What happens to an instance referred?

    Is it paged out like a reniced process on Sun?

    Does it pause in the background — and then run?

    Maybe it just polls with a heavy load.

    Or does it explode?

  8. Marek says:

    What if the client does some heavy processing (or is paused by debugger, anti-virus scanner, stuck waiting on disk or network, modal dialog) and respond after (let's say) 10 minutes? Does it crash because the resources on server-side are now destroyed?

    [This is answered in the linked KB article, specifically optimization (a). -Raymond]
  9. Gabe says:

    It looks like the linked KB article is about DCOM specifically, and does not address the situation where a COM client and server are on the same computer (other than to say that it is a different mechanism).

    So, Marek, the client doesn't send the pings; the RPCSS process does. It just sends a single ping from one machine to another. This actually allows the server machine to detect a client machine crash, not a client process crash. If the client process crashes, presumably RPCSS detects that and just sends a Release to the server.

  10. Steve says:

    Gabe: I would assume the RPCSS can detect when the client process terminates (via a crash or otherwise) when the HANDLE to the client process becomes signalled.

Comments are closed.

Skip to main content