Understanding COM Component Registration

Disclaimer: This article is now very old (in Internet years), so you are at your own risk in heeding any advice herein.

What are COM components?

COM components are binary files of compiled code that executable programs rely on to function. Common examples include:

  • DLLs – Dynamic Linking Libraries
  • OCXs – ActiveX controls
  • TLBs – Type Libraries, which catalog a component’s resources
  • other EXEs – Executables

Other less common files that can be registered with COM include Java class files (*.class) and ASP or WSH scriptlets for use on IIS web servers (*.wsc).

Why and how are they registered?

In order for the OS to find a component when a program needs it, it must be registered with the system. The system then records it in the Registry.

Usually a component is registered by running the program REGSVR32.EXE, which assumes that the component has been properly coded to support the DLLRegisterServer() public method. Executing regsvr32.exe c:\full\path\to\the.dll should respond with a dialog box indicating success or failure of the registration.

Examples:

Type regsvr32 c:\windows\system32\wshcon.dll at the command prompt, and the system responds with this dialog:

DllRegisterServer succeeded

In contrast, running the command regsvr32 c:\windows\system32\aclui.dll will fail because this DLL is not set up to self-register. The following dialog box will appear:

DllRegisterServer failed

In a manner similar to REGSVR32.EXE, MSIEXEC.EXE can self-register COM objects as well. Usually this is performed automatically by the MSI package.

Why should I know this when repackaging applications for Windows Installer?

The “SetupCapture” features of Wise Package Studio (WPS) or Wise for Windows Installer (WfWI) are not always smart enough to import the Registry settings properly. The SetupCapture should be able to recognize the component’s self-registration entries and ignore them when importing, but often it just reads in these values as Registry keys which must be set during the installation, even if it has set the component to self-register as well.

Evidence that your SetupCapture has mistakenly created Registry entries for COM registrations include:

  • There are Registry entries under the HKEY_CLASSES_ROOT hive.
  • The Package Validation program returns errors similar to this: “Reg key ‘primarykey1’ is used in an unsupported way. ProgId should be registered via the ProgId table.” (Or it could mention “CLSIDs”, “CLSID associations”, “file associations”, “Version Independent ProgID”, “Shell extension verbs”, or “TypeLibs”).
  • The ConflictManager highlights Registry conflicts which is cannot resolve on its own. This is usually because two or more install packages are directly writing the COM registrations into the Registry for the same or similar DLLs, even perhaps if they are in different paths.

First we need to understand how the Registry tree HKEY_CLASSES_ROOT (hereafter referred to as HKCR) works. In truth, the HKCR root doesn’t really exist; it is a shortcut to other sections of the Registry. On Windows NT 4.0 or earlier, HKCR only points to HKEY_LOCAL_MACHINE (a.k.a. HKLM) \SOFTWARE\Classes. On Windows 2000 and newer OS’es, there may also be HKEY_CURRENT_USER (HKCU) \SOFTWARE\Classes entries which override the HKLM ones; these are created when the user installs (or is “assigned”) an application but does not have the rights to install it for all users (in HKLM\SOFTWARE\Classes). In the following notes I will use HKCR as the base of the Registry keys, but please understand that this most often (and best) refers to HKLM\SOFTARE\Classes\…

CLSID

The CLSID, or class identifier, is an 128-bit number, expressed in hexadecimal and enclosed in curly-brackets, e.g. “{075BB8A1-B7D8-11D2-A1C6-00609778EA66}". This unique number identifies the component to the system.

One of the following values must exist to instruct the system where to find the component:

  • HKCR\CLSID\<CLSID>\LocalServer = <full path to 16-bit file>
  • HKCR\CLSID\<CLSID>\LocalServer32 = <full path to 32-bit file>
  • HKCR\CLSID\<CLSID>\InprocServer = <full path to 16-bit file>
  • HKCR\CLSID\<CLSID>\InprocServer32 = <full path to 32-bit file>

Other optional values include:

  • HKCR\CLSID\<CLSID>\(default) = <human-readable class name>
  • HKCR\CLSID\<CLSID>\DefaultIcon = <*path to file, icon index #*>
  • HKCR\CLSID\<CLSID>\Insertable
  • HKCR\CLSID\<CLSID>\Interface
  • HKCR\CLSID\<CLSID>\ProgID = <ProgID>

ProgID

The ProgID, or program identifier, is a Registry entry that can be associated with a CLSID. Its format is <Program>..<Version>, such as Word.Document.8 which refers to an MS Word XP/2002 document. Format is as follows:

  • HKCR\<ProgID>\\
  • HKCR\<ProgID>\(default) = <human-readable component name>
  • HKCR\<ProgID>\CLSID\(default) = <CLSID>
  • HKCR\<ProgID>\…

There are also version-independent program ID’s with the format <Program>.<Component>, as follows:

  • HKCR\<Versionless-ProgID>\\
  • HKCR\<Versionless-ProgID>\CLSID = <CLSID>
  • HKCR\<Versionless-ProgID>\CurVer = <ProgID>

File Extension/Association

The File Extension assists the OS in knowing which program to run when you open a document with that extension by referring documents of a certain file extension to the appropriate ProgID. For example, when you double-click a Word .doc file, the system looks up the extension .doc and finds the reference to the ProgId Word.Document.8 where it can find the full path to the executable program msword.exe.

  • HKCR\CLSID\<*.ext*>\(default) = <*ProgID*>

Interface

If the component needs to register an interface, it requires the following syntax:

  • HKCR\Interface\<IID>\\
  • HKCR\Interface\<IID>\BaseInterface
  • HKCR\Interface\<IID>\NumMethods
  • HKCR\Interface\<IID>\ProxyStubCLSID or ProxyStubCLSID32 = <CLSID>

AppID

Some EXE components group their registration information together with other related components, under a single AppID, as follows. The AppID is a string which looks like a filename, e.g. “MYAPP.EXE”.

  • HKCR\AppID\<AppID>\\
  • HKCR\AppID\<AppID>\AppID = <AppID>
  • HKCR\AppID\<AppID>\DllSurrogate or DllSurrogateExecutable = <path to file>
  • HKCR\AppID\<AppID>\LocalService and ServiceParameters
  • HKCR\AppID\<AppID>\…

TypeLib

Type Libraries are required by some COM objects and are included in a separate file with an extension of .TLB. The following Registry keys are also set in this case:

  • HKCR\Interface\<IID>\TypeLib\(default) = <TypeLib>
  • HKCR\TypeLib\<TypeLib>\<*#.#*>\<*#*>\win32\(default) = <*path to .TLB file*>
  • HKCR\TypeLib\<TypeLib>\…
Eric W. Wallace
Eric W. Wallace
Leadership in Systems & Software Development

System architect. Autodidact. Dad extraordinaire. A force against entropy.

Related