Class table generated InprocServer32 value problem.

Question

I'm installing an Active X control that contains some COM servers. I'm using InstallShield's COM Extract at Build option to generate the registry information. This results in a lot of entries in the Registry and Class tables. (The extracted information is pretty much the same using Wix).

It appears that my COM Sever is correctly being installed except for an additional value called "InprocServer32" in the InprocServer32 key that looks like this:

HKCR\CLSID\{MY-COM-GUID}\InprocServer32
    (Default) = C:\Path-to-my\file.ocx
    InprocServer32 = 8tYCAGak)9S9&~swl.$?MyFeatureName>*&N$B'fk?As1x2J653?'

The only think I can make out from the extra value is the MyFeatureName which is the internal name of the MSI feature that contains the .ocx file. The key is not listed in the Registry table so it must be generated by the Class table.

The problem I'm having only happens in Windows Server 2008. It seems that the app trying to use the COM server is failing to find the path to the .ocx file from the (Default) value and instead it is finding the InprocServer32 value. This results in the app launching the MSI and then having the MSI being stuck in what seems like an infinte loop.

I'm wondering if this is a known issue in Windows Server 2008 or whether there is a way to prevent that extra value from being generated by msiexec.

Answer 1

I can't help you diagnose what's going on, I'll just mumble a bit about what this all means. This is a counter-measure against DLL Hell. It is supposed to protect your application against some kind of other install program that could overwrite your COM server registry keys. Specifically the (Default) key which gives the location to your server DLL.

From the fake InprocServer32 value, the app can auto-detect that the Default key was overwritten and automatically launch MSI again to repair the damage. Which is what you see happening.

I thoroughly dislike the feature, it is just one more fail point in something that is already hard to troubleshoot when it blows up. And it is a useless feature, it assumes that the other installer doesn't use the exact same counter-measure. Which would have worked 10 years ago.

No idea what you'd do to troubleshoot this particular failure. Other then just punt this cr*p and let the servers just SelfReg themselves. At least you'll have something to work with when that doesn't work.

Answer 2

I'd read this article and see if it helps you get where you want to be:

RobMen's Recommendation: Do not advertise COM information in MSI

You might want to turn off InstallShield's COM Extract at Build and instead do a One-Time COM Extract on the component in question. Then you can go into the Component Advanced section and manually manipulate the registry / com table information to be how you want it to be.

If you use WiX at all, another workflow / trick is to use Heat to build an MSI or MSM around your COM server. Then use InstallShield to edit the MSI/MSM in direct mode and the Registry view to export the Registry Keys/Values to a .REG file. Then import that .REG file into your Component in your real install project.