0x80010007 RPC_E_SERVER_DIED: Causes and Solutions

I often work with a variety of tools and development platforms. Recently, I have been working on VB.NET project for a client’s flagship product, a business management software weighing in at 92 million lines of code. The project interacts with a large data model represented by a hierarchy of VB6 objects exposing COM interfaces.

Fortunately, Microsoft’s development tools include support for fairly transparent and ostensibly hassle-free inter-operation with COM object. Unfortunately, the inter-operation is often fraught with hassles. One problem with COM that crops up in a variety of situations recently occurred on this project:

The callee (server [not server application]) is not available and disappeared; all connections are invalid. The call may have executed. (Exception from HRESULT: 0x80010007 (RPC_E_SERVER_DIED))

This error crops up in many different settings, from basic COM Interop in .NET applications, to event handling across a COM boundary, to Javascript code executing in Internet Explorer. In the latter case, the issue is generally accessing a Javascript object that corresponds to some COM object used by Internet Explorer that has been freed, most commonly a browser window that has been closed.

In all cases, the problem is accessing a COM object that has been freed. In theory, a COM object should not be freed if there are still references to it, so this problem should never occur since you could never access the object without a reference to it, and if you had one, the object would not have been freed. None-the-less, whether it is references in Javascript that aren’t tracked by Internet Explorer, or references from .NET code that should be tracked, but aren’t, the problem does arise occasionally.

In my particular case, a COM object was stored in a Shared class variable in a Singleton pattern. Sometimes when accessing the Singleton, this error would occur. Since the Singleton is stateless, there is a simple but ugly solution that works reliably. The solution, ugly as it is, was to detect this circumstance, and, if the exception occurs, clear the Singleton and create a new one.

This entry was posted in Uncategorized. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s