View Full Version : failure to self-register on some XP machines

07-19-2005, 09:16 AM
I upgraded to v 11 to hopefully solve a problem but it's not solved. At one customer site using my installer, the .ocx's and .dll's that were built to self-register don't. The ones that don't are not the ones in the /win/sys folder, but the ones that necessarily need to go into the same folder as the program. The program installs currectly at dozens of other sites.

I have tried using v11's option to use the Windows installer for this process and that is not working either.

I have used the regcap tool to capture the registry entries for these files, imported the .reg files into IS, and IS cannot get the registry entries made as needed.

I have created a batch file to run "regsvr32 /s filename" it it doesn't get the job done.

Something does work though: Dragging the self-registering files onto a desktop icon for regsvr32.

I have Googled this issue and found references to one possible issue:

The original ocx/dll was written to put it entry into HKEY_CLASSES_ROOT and the entry needs to be in not in HKEY_CURRENT_USER\Software\Classes because of the user-specific nature of the way XP reads from the registry.

There is a tool which I could use to change the way the DLL self-registers. I haven't tried this yet as it seems like a lot of surgery for what might be a simple problem.

One other idea I have is that there is an XP SP2 policy at the customer site which won't let any autmated process running (even when I'm logged in) modify a registry unless I use the drag technique I noted.

Any ideas appreciated.

07-20-2005, 02:37 PM
I'm posting the solution that I figured out after a lot of Googling the issue. In case this helps anyone else:

Please see:

for a discussion regarding this phenomenon, and a tool available at that site that solves the registry issue.

Referring to my prior post, I can only guess that the reason that dragging the .ocx's over regsvr worked (which can't be done by InstallShield) and neither the Installshield nor the Windows self-registration handlers didn't, was that the dragging process mimics what this tool does.

What does the tool do? It changes how a .dll or .ocx self-registers, with the solution being that it has the self-registration target HKEY_CURRENT_USER\Software\Classes rather than HKEY_LOCAL_MACHINE.

The original reason that the self-registration failed was - my best guess - an incompatiblity between the way the .dll was compiled and the way that newer XP systems handle self-registration in an environment when different users are treated much more independently than in past OS's or even past SP's or policy settings of XP. As I noted, there is onely one site out of dozens that my install didn't work, and it's probably not a coincidence that this location has the latest SP and a more restrictive security policy default.

So I have Installshield call a batch file when it is done with the main install, and that batch file repeatedly makes calls to the tool, with the parameter being the name of the .dll to register in this more compatible way.

07-20-2005, 07:24 PM
The way this is usually done is to let InstallShield extract the registry entries, and the COM registration entries get put into the Class table in the MSI file. This causes registration in HKCU if it's a per-user install or HKCR if it's a per-machine install. Capturing everything and putting it in the registry tables usually subverts this scheme. The Registry table in the MSI file will however do the right thing if you set the Root value to -1 (MSI SDK docs) because that causes the registration entries to be per-user or per-machine. So that Codeproject article is interesting but unnecessary if the MSI file Class table is used to install the COM registration.

07-22-2005, 01:46 AM
Thanks for that info. If I might plead ignorant, do you have the time to describe, in InstallShield 11 user interface terms, what would be done ? I'm trying to match your description against what I can find in the user interface.


07-22-2005, 12:09 PM
I'm using 10.5, but the principle is the same. You can do either of these:
1. Use the component wizard to add a new component and select COM Server - there's a checkbox for Extracting COM registration info. The results show up in the IDE.
2. Set COM Extract at Build in the component view for the component containing the COM Dll. The Dll needs to be the key path file. You can't see the result in the IDE, but if you run Orca (the Windows Installer SDK MSI file editor) you can see the content in the Class table.

I thought there was a way to run the component wizard again on an existing component, but I can't find it!

Stefan Krueger
07-25-2005, 06:17 AM
In Components view (or Setup Design view) select the component. Expand the Advanced Settings branch. Select COM Registration. in the right window right click the top node COM Registration. You should see two options: "Extract Com Data for Key File" and "Refresh Com Data for Key File"