7 replies to this topic

[jamesmhall]

I have what *should* be a simple installer, but I am having an ugly problem. For some reason in the InstallFinalize portion of the installation it seems to be creating the \SOFTWARE\Classes key. (Line 01498 below)

This doesn't cause a problem for the installation, but during the uninstall, this triggers a 1404 permission error message on some machines when it tries to remove the key. On other machines, it totally hangs the explorer shell to the point that Ctrl+Alt+Del doesn't work and user has to do a hard power-cycle to get their OS back.

Subsequent installs, removals, and repairs trigger a 1705 error which again results in crashing the shell when the uninstall again tries to remove the key.

This key is created between the registering of the interfaces, and registration of the Explorer Bar with IE. I created this msi as a Web Project in InstallShield 12 Pro. I have already wasted a couple days tracking this problem down and could use a fresh set of eyes. Educated guesses welcomed! :-)

Thanks, James

01495: (Unknown): WriteRegistryValues: Key: \Software\Classes\Interface\{E5C573D1-EEBC-46BC-BEE2-346AEB007268}\TypeLib, Name: , Value: {45D993C6-AA90-4B46-A755-AFC551AD1FE3}
01496: (Server): MSI (s) (38:50) [15:19:34:546]: Executing op: RegAddValue(Name=Version,Value=1.0,)
01497: (Unknown): WriteRegistryValues: Key: \Software\Classes\Interface\{E5C573D1-EEBC-46BC-BEE2-346AEB007268}\TypeLib, Name: Version, Value: 1.0
01498: (Server): MSI (s) (38:50) [15:19:34:656]: Executing op: RegOpenKey(Root=-2147483647,Key=SOFTWARE\Classes,,BinaryType=0)
01499: (Server): MSI (s) (38:50) [15:19:34:671]: Executing op: RegCreateKey()
01500: (Unknown): WriteRegistryValues: Key: \SOFTWARE\Classes, Name: , Value:
01501: (Server): MSI (s) (38:50) [15:19:34:718]: Executing op: RegOpenKey(Root=-2147483647,Key=SOFTWARE\Microsoft\Internet Explorer\Explorer Bars\{50948372-C39B-407B-9174-538E7EF9A316},,BinaryType=0)

[Stefan Krueger]

Double check your registry view or the registry table in Direct Editor to check the attributes for that key.

[jamesmhall]

The Registry section was blank until I Exported COM Data from the DLL file. So, the source of the key is the DLL. However, there is no reference to HKCU\SOFTWARE\Classes in any of the source code for the DLL. I am guessing that it must have come out of atlbase.h or atlcom.h somehow. I do find it strange that this problem only occurs with InstallShield's MSI, and doesn't with regsvr32.exe.

I removed the entry in Direct Editor and built a new MSI. But, the entry was still in the resulting MSI file. A colleague suggested using Orca to edit the MSI post-build, and that worked.

So, now I have a batch script that copies the msi file, calls Orca so I can remove the entry by hand, then signs the MSI file afterwards. This gets me a shippable install, but leaves me with a non-automated build step with using Orca.

Obviously, I need to figure out the source of this key in the DLL, but it most likely lays somewhere in the use of windows PDK, and will be a pain to find. Is there a better way to automate this edit, or am I stuck with this ugly build step until the source of the key is found?

- James

[Stefan Krueger]

There are multiple way for a registry entry to get in InstallShield: The COM settings of a component, COM Extract at Build, Importing a .reg file - either once or at build, or maybe it's coming from a merge module. Yu could check the tables in Direct Editor where you should see all except entries added by a merge module or by any "at build" actions.

[Philippe Morvan]

I have also this problem (Error 1404, deleting\Sofware\Classes)
I am using Visual Sudio 2005 to build the .msi
I noticed that this problem appears when I add keys in registry like [Manufacturer]/[ProductName]/[ProductID]...
The result is terrific. When unistalling, registry is broken and my customers have to re-install Windows...
I hope to find a solution before they kill me...
PhM

[Glytzhkof]

If you can submit a sample MSI file perhaps we can get to the bottom of this?

[Philippe Morvan]

I think I found the origin of the problem :
I had some keys HKLM\Software\Classes\...
I choose "DeleteAtUninstall:True" for the key HKLM\Software\Classes, thinking Uninstaller would remove ONLY the keys I added.
In fact, Uninstaller tries to remove ALL HKLM\Software\Classes, breaking Windows !
PhM

[Glytzhkof]

That would indeed break windows. System restore or last known good configuration might help you get back up running though.

Be very careful writing anything to the registry outside:
HKCU\Software\*.*
HKLM\Software\*.*

All other areas of the registry is essentially off limits - HKCR being one exception.