COM and Registry

If you are working with COM there are several registry entries that are important and that you need to understand. I will try in this post to clarify them. But before that, let’s enumerate the three possible COM server scenarios. (As a side note, a COM server is a DLL or EXE can contains one or more COM objects; a client is an entity that uses a COM object, which means a COM server can also be the client of another COM server.)

  • inproc: the COM server is loaded into the client process; in this case accessing the COM methods is as simple as using an interface pointer when the client and the in-proc server are in the same thread
  • local: the COM server and the client are loaded in different processes on the same machine; communication is achieved with the use of proxies and stubs via Lightweight RPC
  • remote: the COM server and the client are loaded in different processes on different machines; communication is achieved with the use of proxies and stubs via RPC

In order for the COM Library to be able to locate and instantiate the COM objects correctly, different information is stored in the Windows Registry. The most important information is located under the keys CLSID, TypeLib, Interface and AppID from HKEY_CLASSES_ROOT. The images below show examples for IIS.

HKEY_CLASSES_ROOT\CLSID
Every coclass from the COM server has at least an entry under this key, specifying the CLSID and the ProgID. The CLSID is a GUID that uniquely identifies the class, and the ProgID (programmatic identifier) is a string that identifies the class in a more human readable form. Each ProgID is mapped to a CLSID. The following image shows the mapping for the IIS ProgID.

For each COM class, there must be a key under HKEY_CLASSES_ROOT\CLSID, with the CLSID as the name. The most important sub-keys here are:

  • ProgID: the programmatic identifier, mapped on the CLSID; cam contain a version number (as a suffix)
  • VersionIndependentProgID: a programmatic identifier without the version information
  • InprocServer32: specifies the path of the DLL for the inproc servers
  • LocalServer32: specifies the path of the COM executable for the local (out-of-process) servers
  • TypeLib: indicates the LIBID of the type library that contains the coclass

Here are several screenshots from registry for IIS CLSID.


HKEY_CLASSES_ROOT\TypeLib
Each type library has a key under HKEY_CLASSES_ROOT\TypeLib, with the name of the LIBID. The sub-keys provide information about the physical location of the type library file (.tlb file) and others, such as flags (FLAGS key) the directory that contains the help file for the type library (HELPDIR key). A LIBID is a GUID that uniquely identifies a type library. A *.TLB file is a binary version of an IDL file. This is used by languages such as VB, Java, Javascript and many others in order to be able to use the COM objects.

The following image shows the type lib information for IIS.

HKEY_CLASSES_ROOT\Interface
Information for all interfaces defined in an IDL file (type library) must be added to the registry. Under HKEY_CLASSES_ROOT\Interface must be a key with the IID of the interface. The IID (interface identifier) is a GUID that uniquely identifies an interface. The most important sub-keys are:

  • TypeLib: the LIBID of the type library containing the interface
  • ProxyStubClsid32: the CLSID of the marshaller used to marshal the interface; value {00020424-0000-0000-C000-000000000046} identifies oleaut32.dll, which is the universal marshaler.

The following images show the registry entry for the interface IISBaseObject.

HKEY_CLASSES_ROOT\AppID
An AppID (application identifier) is a GUID that uniquely identifies a COM server and is used to describe security and activation settings; it is used for out-of-proc (local or remote) scenarios. Usually the AppID is the same with a CLSID of a coclass from the COM server (without the risk of collision, because the CLSID and the AppID server different purposes). The most important settings are:

  • AccessPermission: defines the ACL of users that can access the server
  • AuthenticationLevel: defines the authentication level
  • DllSurrogate: identifies the surrogate that can host the DLL; if no value is specified, the default dllhost.exe surrogate is used
  • LaunchPermissions: defines the ACL of users that can launch the application
  • RemoteServerName: identifies the remove server machine

The following images shows the values for an AppID key.

2 Replies to “COM and Registry”

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.