Search code examples
wixwindows-installer

Wix Toolset RegistrySearch Uninstall problem MSI INFO 1402 "Could not open key. Verify you have sufficient access to that key"

I am having a big problem trying to uninstall an application that I have created an installer for using WiX Toolset v3.11

I am using the "remember property" pattern to store some properties in a registry key so they can be read back during the uninstall. I will provide an example, but note there are 5 in total.

 <Property Id="MyProperty" Value="DefaultValue">
      <RegistrySearch Id="MyPropertyRegSearch" Root="HKLM" Key="Software\Company\Installer" Name="myproperty" Type="raw" />
 </Property>

then I have a component which handles the writing of the registry.

 <Component Id="InstallPropertiesWrite" Guid="*">
    <RegistryKey Root="HKLM" Key="Software\Company\Installer" Action="createAndRemoveOnUninstall">
        <RegistryValue Name="myproperty" Type="string" Value="[MyProperty]">
        </RegistryValue>
    </RegistryKey>
</Component>

all of this works fine.

My problem is when uninstalling I get an error in the install log which says

MSI (s) (CC:D4) [14:59:26:414]: Note: 1: 1402 2: HKEY_LOCAL_MACHINE32\Software\Company\Installer 3: 5 Info 1402.Could not open key: HKEY_LOCAL_MACHINE32\Software\Company\Installer. System error 5. Verify that you have sufficient access to that key, or contact your support personnel.

Now I have run process monitor to determine the exact key and account that is trying to access that registry key and it is HKLM\Software\WOW6432Node\Company\Installer which is correct, so I do not believe this is a 32/64-bit related problem. Process monitor also identified that the msiexec executable trying to access that key is running under the NT AUTHORITY\SYSTEM user.

I have verified that the SYSTEM account has "Full Control" permissions (via regedit) to that key but I still get the error.

I am a total loss of what could be wrong, any suggestions would be greatly appreciated, thank you in advance!

I can get it to read without error by adding permissions for "Everyone" to the required keys and that works, but this seems a big security flaw to me, and something I want to avoid if possible.

<Permission User="Everyone" GenericAll="yes" />
Solution

  • Permission Denied: Off the top of my head, unexpected access denied issues are often seen when you 1) apply erroneous ACL permissioning as part of your setup (easy to do) and also from other setups you have installed of course, 2) use overactive malware scanners that block things, 3) use custom actions that run in the wrong context (impersonation) and change things they shouldn't (no need to use C# to apply ACLs like this, or this, or this, or this - use built-in WiX constructs shown below), 4) when people invoke setups to run via weird mechanisms such as "runas" and similar, 5) some OS-changes of caliber can interfere with your custom ACLs - not that common, but possible, and finally 6) sometimes you see problems like these on random machines and you never work out the cause and the problem is never seen elsewhere. Just so it is mentioned. And there are other causes - of course.

    There used to be templates for standard OS permissions that could be re-applied to machines broken by faulty ACL-permissioning. I am not sure what these would be called today or if they still exist. Admin security templates or something to that effect.

    ACL: ACL permissions are complicated, and changing them can frequently lead to problems along the lines of what you see, and many further ones (active directory, system corruption, unexpected new problems after updates, etc...). It is a hard thing to do right. As a rule of thumb: stick to your own folders when messing with ACL. If you can. Or better yet avoid ACL permissioning altogether (list of some approaches to achieve this).

    WiX ACL Permissioning: There are indeed several ways to apply ACL permissioning with WiX, here is a list mid-page: Is WiX changing the permissions on my Notes.ini file?

    Repeating the gist of it here (confusing that long answer):

    The two PermissionEx elements should both be able to do what you need, which is to update and not replace the existing ACL. Note that a common problem with ACL is that the order of the access control elements make a difference, in other words: order of permission elements is important.

    util:PermissionEx: It looks like the util:PermissionEx element merges in new ACEs into the ACL rather than replace what is there. I am not 100% sure - will check.

    Example of WiX's util:PermissionEx - implemented in WixUtilExtension.dll:

    <Wix xmlns="http://schemas.microsoft.com/wix/2006/wi"
     xmlns:util="http://schemas.microsoft.com/wix/UtilExtension">

<..>

<Component Feature="MyFeature">
   <File Source="D:\MyFile.exe">
      <util:PermissionEx User="Everyone" GenericAll="yes" />
   </File>
</Component>
    1. You first have to add the namespace xmlns:util="http://schemas.microsoft.com/wix/UtilExtension" to the top level "Wix" element in the source file.
    2. Then you have to add a reference to the WixUtilExtension.dll if you are in Visual Studio (or set the path to it if you compile with candle.exe and light.exe on your own - see sample at bottom here - that sample is for GUI, but it is the same approach for the Util dll).
    3. Finally you add the permission you need to the file, registry or whatever element you need to add it to. Valid elements seen in the documentation are: CreateFolder, File, Registry, RegistryKey, RegistryValue. See documentation here.

    Links: