1

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" /> 
4
  • Did you check an official guide? No access error usually means that you'll need to add impersonate="no" for your CA Commented Jan 17, 2020 at 15:26
  • @PavelAnikhouski I'm not using a custom action, it's just using the the built in RegistrySearch functionality. The link you provided does not mention anything about impersonate. Commented Jan 17, 2020 at 15:36
  • Sorry, the link above is about registry search. Did you run your msi on x64 or x86 bit OS system? Are you using Win64 anywhere? Look at this thread, it might be helpful Commented Jan 17, 2020 at 15:40
  • I don't have anything using Win64. Installed on a 64-bit OS. I don't believe this is related though as I have verified it is trying to read the correct key, however for sanity I will mark the ReigstrySearch and the component that writes them as Win64=no Commented Jan 17, 2020 at 15:52

2 Answers 2

1

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:

Sign up to request clarification or add additional context in comments.

Comments

0

After painfully trying each account manually to determine which one it was actually using I was able to get this working by granting permissions to the Interactive account. Which I am more comfortable with than Everyone.

<Permission User="Interactive" GenericAll="yes" /> 

But I still don't understand with process monitor shows a different account and why WiX does not set these automatically if they're required, but I will investigate that separately.

Update:

Based on comments the other permission elements granting IIS_IUSRS permission to a key are knocking out the existing permissions and if I put these in their own key it is fine. Ideally I don't want to do this as I'd end up with two keys for one application.

So I was exploring the permissions attribute and notice Append (doesn't compile) and ChangePermission (no effect) attributes, which don't appear to be documented anywhere. :(

Solution:

I changed my existing Permission element to use the PermissionEx element from the Util extension as this kept all existing permissions in place and only added the permissions I needed.

8 Comments

Do you have ANY custom actions at all in this setup? How do you launch and install the setup? As a user or via a deployment system? Are you doing any "runas" operations? Would be useful to see the WiX source - there is something here that is wrong. What does validation say for the built MSI?
Generally speaking I have seen stuff like this resulting from custom actions running in the wrong context (impersonation), and when custom ACL permissions are applied as part of the setup and every now and then I have seen it as an unreproducable bug that has not been seen on other machines. Try another machine? Maybe a virtual? I have also seen it when people kick off installation in weird ways doing "runas" and things like that. Is the result the same in silent and interactive uninstallation modes? As in try to uninstall from ARP and then to uninstall by running the actual MSI.
Some more context and explanation for the last suggestion above: Uninstall from Control Panel is different from Remove from .msi.
Hi Stein, apologies for the delay in getting back to you, yes there are some other custom actions. The install a user account (an administrator) running the .msi directly, nothing fancy. I will have a read through the link and investigate the effect the custom action has. All this action does is launch a file dialog to select a file. Happy to provide some source code, any particular bit?
What is the actual ACL on that registry key when you look at it outright after installation? Do you do any ACL permissioning in your MSI?
|

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.