4 replies to this topic

[Gareth at Serif]

Hi there,

I have this problem being reported very seldomly from users of various apps for which I have built the installs using WiX. In this particular example, the error reads:
Could not open key: HKEY_LOCAL_MACHINE\Software\Classes\Serif.PanoramaPlus\CLSID. Verify that you have sufficient access to that key, or contact your support personnel.

I retreived a log file of the installation from this particular user, and the failiure extract is like this:
MSI (s) (FC:14) [00:20:18:729]: Executing op: RegOpenKey(,Key=CLSID\{45E01088-E097-4FDB-907C-7B19E0E0AE3D}\Verb,,BinaryType=0)
MSI (s) (FC:14) [00:20:18:729]: Executing op: RegAddValue(,,)
WriteRegistryValues: Key: \Software\Classes\CLSID\{45E01088-E097-4FDB-907C-7B19E0E0AE3D}\Verb, Name: , Value:
MSI (s) (FC:14) [00:20:18:739]: Executing op: RegOpenKey(,Key=CLSID\{45E01088-E097-4FDB-907C-7B19E0E0AE3D},,BinaryType=0)
MSI (s) (FC:14) [00:20:18:739]: Executing op: RegAddValue(,Value=PanoramaPlus Catalog,)
WriteRegistryValues: Key: \Software\Classes\CLSID\{45E01088-E097-4FDB-907C-7B19E0E0AE3D}, Name: , Value: PanoramaPlus Catalog
MSI (s) (FC:14) [00:20:18:739]: Executing op: RegOpenKey(,Key=Serif.PanoramaPlus\CLSID,,BinaryType=0)
MSI (s) (FC:14) [00:20:18:739]: Executing op: RegAddValue(,Value={45E01088-E097-4FDB-907C-7B19E0E0AE3D},)
WriteRegistryValues: Key: \Software\Classes\Serif.PanoramaPlus\CLSID, Name: , Value: {45E01088-E097-4FDB-907C-7B19E0E0AE3D}
MSI (s) (FC:14) [00:20:18:739]: Note: 1: 1402 2: HKEY_LOCAL_MACHINE\Software\Classes\Serif.PanoramaPlus\CLSID 3: 5
Error 1402. Could not open key: HKEY_LOCAL_MACHINE\Software\Classes\Serif.PanoramaPlus\CLSID. System error 5. Verify that you have sufficient access to that key, or contact your support personnel.
MSI (s) (FC:14) [00:20:20:972]: Product: Serif PanoramaPlus 3 -- Error 1402. Could not open key: HKEY_LOCAL_MACHINE\Software\Classes\Serif.PanoramaPlus\CLSID. System error 5. Verify that you have sufficient access to that key, or contact your support personnel.
Action ended 00:20:21: InstallFinalize. Return value 3.

So, as you can see, everything was being added to the registry in the usual way until it hit this particular point where it did the RegOpenKey, RegAddValue and then reported a failiure in the opening (so why did it move onto writing?).

What is interesting is that in all cases of this type of error reported back that I've been able to investigate, the key already existed. This ties in with most Google results in stating the obvious - it's a permissions issue. however, the two times I've been able to follow it up as far as checking registry permissions, they all had adequate permissions and have merily edited and/or deleted the problematic key in order to acheive a succesful install.

So, has anyone experienced this sort of thing and have any recomendations as to how to solve it? Of course, I'd like to write this type of com registration without contraveining ICE33 and use the ProgID and CLSID tables, but I haven't figured out how to do this in WiX yet (and most people recommend against it anyway).

Furthermore, I was looking into forcing write permissions to keys I'm adding with the LockPermissions table, but the only UserID that all systems have is 'Everyone' and I very much doubt that system administrators would appreciate me setting a reg key to give full control to everyone!

Thanks for any sugestions/thoughts you can put forward,
Gareth at Serif

[Stefan Krueger]

Yes this looks like a permission problem. System error 5 = access denied. Remember that (if your install runs with admin rights) Windows Installer writes registry entries using the system account, so that account needs to have sufficient access rights to the key.

[Gareth at Serif]

Hi Stefan, thanks for looking in. I have a lanch condition of 'Privileged' so the user that is installing should have the required rights... unless the installation that created the key I'm trying to over-write gave it peculiar permissions.

The particular example I've used above was from a single-user machine, and when you view permissions of that particular key only one user was listed, in the only user group (Everyone) with both check-boxes for 'full control' enabled.

I tried disabling and re-enabling full control to see if it'd straigten out any registry corruption, but nothing useful came of it. That same user was able to delete the key and then the install completed successfully, which is nice, but I hoped there was something the install could achieve in this respect.

Edited by Gareth at Serif, 02 October 2006 - 15:31.

[Glytzhkof]

As Stefan stated above MSI files run with different security context in different stages of installation. Immediate mode custom actions and the MSI GUI are run in user context, but deferred mode custom actions between InstallInitialize and InstallFinalize are run with the LocalSystem account. As such the LocalSystem account may be denied access to the key in question, even if the user who launched the setup has full access to the key.

[Gareth at Serif]

Thanks for your input Glytzhkof, I had long since forgotten about the LocalSystem Account and am now trying to familiarise myself with the possible effects as described in http://windowssdk.ms...y/ms684190.aspx

However, I'm not certain how the permissions on a registry key being given 'full control' to the 'Everyone' User Group could possibly have write permission issues with the LocalSystem Account.

The effect I've described is very rare and installs succesfully on thousand's of machines in our customer base, so I do assume that it'll only happen on a dirty machine in a particular state. I just don't know how yet.

Regards,
Gareth