Cancelling an uninstall process at a certain time launches MSI's install UI sequence

[wixbot]

This bug was discovered on Windows 10 x64, insider preview build 10162.
Bug was present in 3.9.1208.0, 3.10.0.1823 and 4.0.2926.0.

I have a burn bootstrapper with conditions to launch 1 of four MSI packages, split into 32 and 64 bits on the one hand and 2 languages on the other. During installation I use the MSI package's UI sequence, in lieu of only using the Burn UI. The uninstall process, of course, only uses the Burn UI.

The bug manifests if I press the cancel button just after the desktop shortcut is removed. Not as soon as the shortcut is removed, but a half-beat afterwards.

It's as if the rollback (re-install) call to msiexec somehow loses the /quiet flag, and the user gets to see the install process.

If you then cancel out of the MSI dialog, the system is left in a state where the MSI has effectively been uninstalled - items in ProgramFiles removed as well as shortcuts - but the bootstrapper still has an entry in ARP.

The MSI installs 1 application, 1 service program, and NDIS based drivers by way of the DifXAppExtension.

The following logs are mostly in English, though some strings might be in Japanese.

Bundle uninstall log

MSI package uninstall log

MSI package rollback log

Before uninstall - note "Sample Program" shortcut on the left side of the desktop

Start uninstall

Press cancel just after "Sample Program" shortcut is removed by installer

MSI package's install sequence welcome screen displayed

MSI package's install dialog cancellation confirmation

MSI package's "installation was interrupted" exit dialog

Burn's final error dialog

Originally opened by valdimar

[wixbot]

Clarifying "Sample Program" shortcut on desktop

Originally posted by valdimar

[wixbot]

When you use @DisplayInternalUI, Burn runs your MsiPackage with UI during install. It has to because there are no rules about how @DisplayInternalUI works, so it can be required that the user provide input. We can't change that in v3.x; in v4.0, we can't enforce it but it could be a documented policy that @DisplayInternalUI MsiPackages must be silently installable too.

Release changed from v3.9 to v4.x
Resolution set to suspend
Status changed from Untriaged to Resolved

[wixbot]

This is happening during uninstall.

I designed the bundle with @DisplayInternalUI in mind, and Burn correctly displays the MsiPackage's UI sequence during install.

It was my understanding that Burn never displayed the MsiPackage's UI during uninstall, and this has usually borne true. I attempted to explain with the above that if the user cancels the uninstall, usually Burn exits normally, except for this small window of time after the desktop shortcut is removed; then it displays the install UI when it should be rolling back the uninstall.

Originally posted by valdimar

[wixbot]

This bug was marked as "resolved" due to a misunderstanding. Please re-evaluate.

Originally posted by valdimar
Status changed from Resolved to Untriaged

[wixbot]

No, the issue was understood. You can hear triage's comments in the weekly meeting (summary here).

The problem is that this is the behavior for WiX v3.x. Changing it could break other people. For example, with an MSI that cannot be silently installed (thus required DisplayInternalUI='yes') then "fixing" this behavior would prevent that MSI from being installed during rollback. So the UI is displayed.

The bug was moved to WiX v4.x where breaking changes can be made. Then since DisplayInternalUI is generally discouraged the bug was resolved suspend. That indicates we're not really interested in this bug. If the bug is really important to someone and they can provide a clean fix that doesn't add significant technical overhead, we'll totally review the proposal/pull request. Otherwise, there are many other bugs that are higher priority.

Originally posted by robmen
Status changed from Untriaged to Resolved

[wixbot]

All right, fair enough.

We rely on DisplayInternalUI during install, so I guess we'll have to take this uninstall behavior that comes with it.

Originally posted by valdimar

[wixbot]

Thank you for the quick triage and correspondence, by the way.

Originally posted by valdimar

[wixbot]

Note: we'd recommend looking at moving away from DisplayInternalUI eventually. It simply does not work as well as one would hope and a better experience can be provided via a Bundle's UI.

Originally posted by robmen

[wixbot]

Yes, I was aware of the official recommendation regarding DisplayInternalUI, but due to time constraints we went with this design. I expect us to avoid it in future projects. Thanks for the advice.

Originally posted by valdimar