1

I'm building an an installer using a Visual Studio 2008 deployment (setup) project. The project has a Launch Condition "Privileged" so that only administrators can run it. It uses a merge module provided by a third party to register a COM component. The COM component is exposed via a .NET interop DLL, which is in turn used by the program for which I am building the installer. (Specifics: this is an Intuit merge module which installs the QBFC framework).

After the install completes, the COM component can not be loaded. The error is "class not registered". But when I go to the registry, I can see that all of the correct entries are there under HKEY_CLASSES_ROOT\CLSID\{the class id} - where the class id matches the class id of the error message. If I then open a command prompt in administrative mode and re-register the DLL the COM server using Regsvr32, everything is fixed, but I can't see any change to KEY_CLASSES_ROOT\CLSID

When I examine the system using process monitor while it is getting the class not registered error, I can see that the application is getting a "name not found" error when it tries to open the CLSID, even though the CLSID is definitely there (I have double and triple checked). I'm thinking this must have something to do with permissions. An alternate theory is that perhaps the "class not registered" message is coming from a dependent component, but this wouldn't explain what I'm seeing in process monitor.

All of these test results come from a Windows 7 Ultimate 32 bit operating system.

What steps would you take to get to the bottom of this problem?

Paul Keister
  • 12,851
  • 5
  • 46
  • 75
  • Look in HKLM\Software\Wow6432Node\Classes\CLSID. Home of the 32-bit COM registration keys. – Hans Passant Jul 09 '11 at 01:34
  • Hans, that's a good catch but I forgot to mention that my test results are from a 32 bit image. – Paul Keister Jul 09 '11 at 18:14
  • If "32 bit image" means a 32-bit COM server then you definitely want to look in Wow6432Node. Avoid keeping us guessing at important details like whether or not you run this on a 64-bit operating system. – Hans Passant Jul 09 '11 at 18:22
  • Sorry, I mean to say 32 bit operating system image, Windows 7 Ultimate 32 bit, to be precise. – Paul Keister Jul 11 '11 at 04:09

1 Answers1

2

One thing that it might be is an issue with the component category cache. It's a long shot, but if you add a step to your install to delete the keys under HKEY_CLASSES_ROOT\Component Categories\ does it help? If so, you need to figure out which comcat cache you need to delete (i.e. which one your objects are using).

The other thing you can do is export the entire registry, do your install, export the registery, do the regsvr32 thing, export the registry. Then windiff each revision of the exported registry file. That may give you an idea of what changed, at least.

Lastly, make sure you're doing 64bit registration correctly if it's a 64bit machine.

i_am_jorf
  • 53,608
  • 15
  • 131
  • 222
  • 1
    Exporting the entire registry and doing a diff is what sorted this out. This led me to realize my registry knowledge is out of date. For example, the HKEY_CLASSES_ROOT key is now completely simulated by merging data from other source keys, depending on the user context. Doing a full registry export revealed that the registrations were happening in the current user hive instead of in HKEY_LOCAL_MACHINE\Software\Classes where they belong. – Paul Keister Jul 11 '11 at 23:17
  • Yeah, there are some good articles on MSDN about this. E.g., http://msdn.microsoft.com/en-us/library/aa965884(v=vs.85).aspx – i_am_jorf Jul 19 '11 at 19:06
  • 1
    Also see http://msdn.microsoft.com/en-us/library/windows/desktop/ms724498(v=vs.85).aspx – Matt Smith Mar 25 '13 at 18:28