Registry key not updating when value was set to 0 when using WiX Toolset

Viewed 1426

The registry key value's isn't being updated with its intended data by WiX Toolset for a MSI. If the k:v is missing, it adds it. If the k:v's data is set to 0, it ignores it completely, which is the actual problem here (I think)

The basic goal is to verify this registry key value exists with the intended data-value before installation, and the reboot prompt triggers if the key had to be added/updated.

<?xml version="1.0" encoding="UTF-8"?>
<Wix xmlns="http://wixtoolset.org/schemas/v4/wxs">
    <Product Id="*" Name="SampleInstaller" Language="1033" Version="1.0.0.0" Manufacturer="ACME" UpgradeCode="cf6248e9-d7da-4996-9b8e-90072e8510f6">
        <Package InstallerVersion="200" Compressed="yes" InstallScope="perMachine" Platform="x64"/>
        <MajorUpgrade DowngradeErrorMessage="A newer version of [ProductName] is already installed." />
        <Feature Id="ProductFeature" Title="SampleInstaller" Level="1">
            <ComponentGroupRef Id="ProductComponents" />
        </Feature>    
    </Product>

    <Fragment>
    <Directory Id="TARGETDIR" Name="SourceDir">
      <Directory Id="ProgramFilesFolder64">
        <Directory Id="INSTALLFOLDER" Name="SampleInstaller" />
      </Directory>
    </Directory>
    <Property Id="VKB_QUERY_HKCU" Secure="yes">
      <RegistrySearch Id="VkbVisibleHkcu"
            Win64="yes"
            Type="raw"
            Root="HKCU"
            Key="Software\Microsoft\TabletTip\1.7"
            Name="TipbandDesiredVisibility"/>
    </Property>
    <ComponentGroup Id="ProductComponents" Directory="INSTALLFOLDER">
      <Component Id="ShowVKB_Registry_HKCU" Guid="{97AB4B1D-C9C8-4B34-9328-FF8CA3ED8992}" Directory="INSTALLFOLDER">
        <RegistryKey Id="VKB_Registry_Key_HKCU" Root="HKCU" Key="Software\Microsoft\TabletTip\1.7" ForceCreateOnInstall="yes" ForceDeleteOnUninstall="no">
          <RegistryValue Id="VKB_Registry_Value_HKCU" Action="write" Type="integer" Name="TipbandDesiredVisibility" Value="1"/>
        </RegistryKey>
      </Component>
    </ComponentGroup>
    <InstallExecuteSequence>
      <ScheduleReboot After="InstallFinalize">NOT (VKB_QUERY_HKCU = "#1")</ScheduleReboot>
    </InstallExecuteSequence>
    </Fragment>  
</Wix>

Also, it seems like the exit code from MSIEXEC is always returning 0 instead of 3010 of 1641 when checking $LastExitCode and %errorlevel%. I haven't messed with the different reboot behaviors, but I thought having the reboot prompt would have caused my installer to exit non-zero, so any guidance there is also appreciated.

2 Answers

Do that install and create a verbose log with:

msiexec /I [path to msi] /l*vx [path to a text log file]

and look at the property values etc. The most likely reason you're not getting the 3010 exit result is that the ScheduleReboot is conditioned false.

Assuming that everything is otherwise working as intended, the problem might be that you need to set Secure to Yes in your property declaration, otherwise the value won't be transferred from the UI sequence registry search into the execute sequence. If the log shows it gettingthe correct value at the start of the install but losing it later this is most likely the issue.

One of your comments refers to %errorlevel% but it's not clear why this is relevant. If you are initiating this from a batch file or similar then this is useful information to add. Also, if you are installing this in some way that is separate from the current interactive user then this is also useful to know.

The log seems to indicate that everything is fine. The properties have values that look correct, and the ScheduleReboot action is performed. The only issue I see is that Windows Installer did not show the dialog asking the user to do the reboot, so it does the non-interactive thing, which is to return 3010 to tell the caller that a reboot is required. There are no obvious reasons why Windows Installer didn't prompt for the reboot (which is what ScheduleReboot does) but if the install is running in a non-interactive user context then Windows will not show a desktop dialog to another user (or to no user nobody is logged on).

So, the sample works, but you can't test it repeatedly by re-running install. You have to uninstall it first, or stumble upon the reason like I did, and re-compile before re-running.

I noticed that the sample was only working right after a re-compile. So, I'm guessing the installer has a GUID or something tied to it at compile-time, which is then included with your installation. And when re-running the installation, it would just quickly run and close, not ask you to uninstall first or remove the existing product, so I was assuming that it just wasn't evaluating that my installer had to write the keys, and just ended when not having to do more.

So basically it was a test bug/lack of intrinsic WiX knowledge.

So, always uninstall your MSI before re-running it unless you are specifically trying to trigger upgrade behavior.

I'm not sure why I wasn't getting an error about the product already existing. I would have thought for sure that would be the default behavior.

Related