Here’s a problem a partner ran into last month. Suppose you have an ActiveX server (in this case it was a VB6 COM Executable) registered on x64 bit Windows Server 2008 or Vista. You open up Component Services and you find your server under “Component Services\Computers\My Computer\DCOM Config”. Those same COM servers however don’t show up in that location under 64 bit versions of Windows 7 or Windows Server 2008 R2. How come?
First some background. When you register a COM server (myserver.exe /regserver), the server’s registration code has full control over what is entered in the registry. Most of the time frameworks such as ATL, MFC or VB take care of this in plumbing code. Apparently VB6 ActiveX servers don’t add the AppID. Spelunking around a little with procmon, the MMC snap-in for component services apparently enumerates all COM servers and adds the missing entries. It still does this on all platforms, so why the problem?
As mentioned this problem only manifests itself on x64 Windows 7 and Windows Server 2008 R2. The x64 bit versions of Vista and WS08 don’t manifest this problem. So what has changed? The answer is COM Reflection. When you register the COM Server on platforms prior to Windows 7 on an x64 system, the CLSID is copied from HKCR\Wow6432\CLSID to HKCR\CLSID. The MMC Component Services snap-in enumerates and fixes up only the “native” HKCR\CLSID. Since the values for 32 bit servers is no longer copied to that hive, you won’t see it in the 64 bit snap-in.
There is a trivial workaround for this. You can open a 32 bit mmc by typing “mmc -32” on the command line. Then add the Component Services snap-in from there. That will fix up the missing AppID entries. Once the entries are added you can use the 64 bit DCOMCNFG again.