WIX/MSI setup writes to HKLM despite MSIINSTALLPERUSER=1

Question

I try to create a MSI Single Package using WIX (3.10). The user can select in the UI whether the package should install Per-User or Per-Machine. The package is initialized with ALLUSERS=2 and MSIINSTALLPERUSER=1. I did not set an InstallScope, as this would limit the Package to one or the other.

If the user selects Per-Machine the setup continues with ALLUSERS=2 and MSIINSTALLPERUSER="". - Everything works as expected.

If the user chooses Per-User installation ALLUSERS=2 and MSIINSTALLPERUSER=1 remain unchanged. If a non-privileged user runs the setup everything works as expected as well.

But if a privileged user executes the setup and chooses Per-User installation, registry keys that should be written to HKCU\Software\Classes\ are still written to HKCR / HKLM\Software\Classes\. This happens without UAC being invoked. I observed this behavior on a Windows 8.1 (current patch level).

This is not what I want. If the user selects Per-User installation, there should be nothing written to HKLM/HKCR.

Here is sample from the wxs-file:

<Component Id="MyRegistryComponent" Guid="{99999999-9999-9999-9999-999999999999}">
    <RegistryValue Id="MyRegistryComponent_MainKey" Root="HKCU" Key="Software\Classes\myapp.myclass" Value="myapp.myclass.foo" Type="string" />
</Component>

I checked the MSI with Orca. This RegistryValue has Root=1 in the Registry table of the MSI.

I tried/checked already:

I verified that the ALLUSERS and MSIINSTALLPERUSER properties are indeed set as stated above.
I tried setting ALLUSERS="" MSIINSTALLPERUSER=1 – No effect.
I changed Root="HKCU" to Root="HKMU" in the wxs. This results in Root=-1 in the MSI, but I does not change the final result after installation.

What am I missing here? Is possible that this behavior is caused by previous incomplete (un-)installations?

PhilDW PhilDW · Accepted Answer · 2016-09-19T17:31:57

When you say "This results in Root=-1 in the MSI, but I does not change the final result after installation." it's not clear which of the results you're referring to but:

HKCU will always go to HKCU, HKMU is what you need to switch between HKCU and HKLM in a single package setup. So using HKMU and producing a verbose log would be useful to see if there is a failure somewhere in there.
You will get changes in HKCR. That's usually the normal behavior because as this article explains:

https://msdn.microsoft.com/en-us/library/windows/desktop/ms724475(v=vs.85).aspx

Quote "The HKEY_LOCAL_MACHINE\Software\Classes key contains default settings that can apply to all users on the local computer. The HKEY_CURRENT_USER\Software\Classes key contains settings that apply only to the interactive user. The HKEY_CLASSES_ROOT key provides a view of the registry that merges the information from these two sources. HKEY_CLASSES_ROOT also provides this merged view for applications designed for previous versions of Windows."

HKCR is a virtual view that combines class registration for the current user with class registration for the machine to present a view of all class entries on the system. Other accounts (such as the system account) will see only HKLM, so what you see exactly depends on who you are.

I suggest that is what is needed here is a test case that uses HKMU as is required, and maybe post that test case. Keep in mind that seeing HKCR entries is normal, going by the documentation, so maybe that explains all that you are seeing.

WIX/MSI setup writes to HKLM despite MSIINSTALLPERUSER=1

1 Answers