Suppressing a ForceReboot action initiated, during an upgrade, by a related bundle

[l0rd]

Hi,

We are currently in trouble because we have released an installer with a ForceReboot action that is triggered during an upgrade when it should not:

<InstallExecuteSequence>
  ...
  <ForceReboot Before="StopServices" Condition="(NOT WIX_UPGRADE_DETECTED) AND (NOT BURNMSIUNINSTALL) AND (NOT AFTERREBOOT)" />
</InstallExecuteSequence>

Users aren't facing this yet, but it will happen at the next version's release. The action is executed when the features of the currently installed bundle are uninstalled. How can the new version bundle suppress the ForceReboot action triggered by the currently installed bundle?

From the setup.exe logs:

...
MSI (s) (84:38) [19:05:24:145]: SECREPAIR: Hash Database: C:\Windows\Installer\SourceHash{18107131-1820-4878-8AEE-65AAE37BC1E3}
MSI (s) (84:38) [19:05:24:145]: Note: 1: 2318 2:  
Action start 19:05:24: ProcessComponents.
MSI (s) (84:38) [19:05:24:587]: Doing action: UnpublishFeatures
Action ended 19:05:24: ProcessComponents. Return value 1.
Action start 19:05:24: UnpublishFeatures.
MSI (s) (84:38) [19:05:24:589]: Doing action: ForceReboot
Action ended 19:05:24: UnpublishFeatures. Return value 1.
Action start 19:05:24: ForceReboot.
...

[wmanning]

Maybe this (set REBOOT MSI property to Suppress or ReallySuppress): https://learn.microsoft.com/en-us/windows/win32/msi/reboot
Source: https://stackoverflow.com/questions/31431791/how-to-force-an-installer-to-not-reboot-after-repair

[l0rd]

@wmanning Thank you for your suggestion but I have tried to set REBOOT to ReallySuppress but it had no effect and from the doc:

Burn controls the follow MSI properties so they cannot be set with MsiProperty: ..., REBOOT, ...

And the SO answer suggests to avoid that option.

The alternative suggestion is avoiding the root cause. And in our case there is a Property that controls the ForceReboot:

<SetProperty Id="DO_REBOOT" Before="AppSearch" Value="1" Sequence="first" ... />
<InstallExecuteSequence>
  ...
  <ForceReboot Before="StopServices" Condition="...AND (DO_REBOOT = 1)" />
</InstallExecuteSequence>

Do you know how I could set that Property to zero before the UnpublishFeatures action?

[wmanning]

Sorry overlooked you're doing it in burn.
InstallValidate, InstallInitialize, ProcessComponents are before the UnpublishFeatures action in InstallExecuteSequence. Maybe you could do a custom action (aka use SetProperty) setting that property to zero before or after one of those components.

FYI, I got the above three from the book Wix 3.6: A Developer's Guide to Windows Installer XML.

[wmanning]

That is not any better since you have to modify the MSI and if you have to do that overriding REBOOT is also an option.

[l0rd]

I don't know how to set a property when the old MSI is invoked for uninstallation. From the logs I see:

Applying execute package: (...), action: Install, path: (...), arguments: ' DO_REBOOT=0...'
....
Applying execute package: (...), action: Uninstall, path: (...), arguments: ' -log "..."'

The bundle sets the property DO_REBOOT when invoking the new MSI package (with action: Install) but I doesn't set it when invoking the old MSI (with action: Uninstall).

That's how we define the property in the bundle:

<Wix xmlns="http://wixtoolset.org/schemas/v4/wxs" xmlns:bal="http://wixtoolset.org/schemas/v4/wxs/bal" xmlns:util="http://wixtoolset.org/schemas/v4/wxs/util">
  <Bundle Name=(...)>
   <Chain>
      <MsiPackage Id="(...)" SourceFile="(...)" Vital="yes">
        <MsiProperty Name="DO_REBOOT" Value="0" />
(...)

[wmanning]

I don't think there is an easy way.

Depending on how your original MSI was built it might be possible to create a minor upgrade MSI and then convert that to a patch (msp) to "repair" the existing MSI. I don't think a patch is considered an upgrade as the original MSI remains in place. So that might be a way to update the property. I have never did this though and could be wrong.

• Use the Patch element and PatchFamily element.
• The book I mentioned above goes into this in some detail.
• You'll also need something like the Remember Property Pattern technique so you can save properties between install, uninstall, and upgrade, etc. Might be able to use this to remember the property in your patch MSI and use it in your upgrade MSI to prevent reboot...

FYI:

• Burn has the ability to slipstream patches: Easier Authoring for Slipstreaming Patches. Just mention in case it's helpful.

Just an warning, :), I've been using the wixtooset for 10+ years for our own installer but far from an expert. Most users on this forum are mostly drive by's wanting help so not a lot of help available. There is firegiant and another user here, Christopher Painter, who I think does consulting as well. I would recommend contacting one of them.

[wmanning]

Might be useful as well: https://github.com/orgs/wixtoolset/discussions/6877

[l0rd]

This information is helpful. Thank you @wmanning. A lot of references to look at :-)

Looking at the links you shared, creating a Patch looks like the way to go.

However, I have found a simpler (but dirty) way to address the reboot problem. I have renamed a feature of the MSI package and used it in the MajorUpgrade section.

-- <MajorUpgrade RemoveFeatures="<old-feature>" Schedule="afterInstallExecute" />
++ <MajorUpgrade RemoveFeatures="<new-feature>" Schedule="afterInstallExecute" />

The update fails because the new-feature cannot be found in the previous MSI package. However, setting IgnoreRemoveFailure="true" makes the upgrade successful. The reboot isn't triggered either.

-- <MajorUpgrade RemoveFeatures="<old-feature>" Schedule="afterInstallExecute" />
++ <MajorUpgrade RemoveFeatures="<new-feature>" Schedule="afterInstallExecute" IgnoreRemoveFailure="true" />

This isn't ideal as we ignore failures in the uninstallation and may have other side effects that I am not aware of, but it seems to work fine, and I am considering going with that instead of implementing a patch.

[wmanning]

Assume both the existing MSI and the upgrade MSI has the same files, component rules are followed, and you weren't doing the installation via burn (and since you are using afterInstallExecute):

• The old MSI is not "uninstalled" and it will be left on the machine. So it will be like you have both installed. Since components are the same nothing will appear different other than some MSI registration stuff in the windows registry that tracks that the MSI is installed on the machine.
• All components will have a ref count of 2. You will have to uninstall both the existing and upgrade MSI to remove the components.

Now burn: I don't have a clear understanding on how burn works with MSI upgrades (been I while since I looked into that). Burn could just uninstall the existing package after the upgrade anyways (without only relying on the MSI upgrade to do that). If so, might be all good. Burn log file would say.

Do you see two entries of your MSI in add/remove programs when you install? With burn you can hide the MSI entries so can't see then in that case.
Does uninstall work correctly?

[l0rd]

We went with the patch / minor update method. The feature rename worked fine with /silent, but when using the GUI, an error message was shown to the user, which was not ideal.

So, the patch / minor update fixed the problem and was simple enough to set up. I am still trying to figure out for how many releases we will build the patch for the problematic version. At some point, we will stop creating it and block direct updates from <problematic-version> to <current-version>.

Thank you for your help @wmanning