Wix upgrade goes into maintenance mode and never does upgrade

Question

I am running Wix 3.11.1 and when trying to do an upgrade the upgrade goes into maintenance mode and leaves two entries in Add/Remove programs list.

A short version of Product.wxs has the following:

 <Product Id="*"  Name="Boo" Language="1033" Version="1.1.0.0" Manufacturer="Foo"
          UpgradeCode="PUT-GUID-HERE">

    <Package InstallerVersion="200"  Compressed="yes" InstallScope="perMachine"/>

<MajorUpgrade AllowDowngrades="no" AllowSameVersionUpgrades="yes" 
              DowngradeErrorMessage="!(loc.NewerVersionInstalled)" />

Upgrade Code: 3F55CE54-8409-4918-9906-D8AD18794BFC

And the product and package code are:

1.0

Product Code FC49F622-02E6-40D9-ACD9-92BDD4AF5979

Package Code 6C49FAA1-5B11-4173-80A7-A7B3FA4313AE

1.1

Product Code 4871555F-F369-4159-9EF0-4BBDF07B6842

Package Code 3594D7C2-D5AC-4A41-A8C6-6E3D63C6ACA0

When I run the installer with logging I get the log information shown below. When the upgrade code is the same and product and package codes are different, and the version is incremented in the first three digits I thought an upgrade should occur but is isn't. Also both versions are per-machine so that should not stop the removal of previous version. The log shows maintenance mode and never performs removal of previous version. I have an upgrade table in the msi and it shows the max value of 1.1 and WIX_UPGRADE_DETECTED as the action. Does anyone know what would cause this to enter maintenance mode rather do a major upgrade?

Log File

    MSI (s) (68:9C) [15:04:38:423]: Doing action: RemoveExistingProducts
Action 15:04:38: RemoveExistingProducts. Removing applications
Action start 15:04:38: RemoveExistingProducts.
RemoveExistingProducts: Application: {FC49F622-02E6-40D9-ACD9-92BDD4AF5979}, Command line: UPGRADINGPRODUCTCODE={4871555F-F369-4159-9EF0-4BBDF07B6842} CLIENTPROCESSID=8344 CLIENTUILEVEL=0 MSICLIENTUSESEXTERNALUI=1 REMOVE=ALL
MSI (s) (68:BC) [15:04:38:423]: Resetting cached policy values
MSI (s) (68:BC) [15:04:38:423]: Machine policy value 'Debug' is 0
MSI (s) (68:BC) [15:04:38:423]: ******* RunEngine:
           ******* Product: {FC49F622-02E6-40D9-ACD9-92BDD4AF5979}
           ******* Action: 
           ******* CommandLine: **********
MSI (s) (68:BC) [15:04:38:423]: Note: 1: 2203 2: C:\WINDOWS\Installer\inprogressinstallinfo.ipi 3: -2147287038 
MSI (s) (68:BC) [15:04:38:423]: Machine policy value 'LimitSystemRestoreCheckpointing' is 0
MSI (s) (68:BC) [15:04:38:423]: Note: 1: 1717 2: Boo 
MSI (s) (68:BC) [15:04:38:423]: Calling SRSetRestorePoint API. dwRestorePtType: 1, dwEventType: 102, llSequenceNumber: 0, szDescription: "Removed Boo".
MSI (s) (68:BC) [15:04:38:439]: The call to SRSetRestorePoint API succeeded. Returned status: 0, llSequenceNumber: 45.
MSI (s) (68:BC) [15:04:38:439]: End dialog not enabled
MSI (s) (68:BC) [15:04:38:439]: Original package ==> C:\WINDOWS\Installer\1179bb4.msi
MSI (s) (68:BC) [15:04:38:439]: Package we're running from ==> C:\WINDOWS\Installer\1179bb4.msi
MSI (s) (68:BC) [15:04:38:439]: APPCOMPAT: Uninstall Flags override found.
MSI (s) (68:BC) [15:04:38:439]: APPCOMPAT: Uninstall VersionNT override found.
MSI (s) (68:BC) [15:04:38:439]: APPCOMPAT: Uninstall ServicePackLevel override found.
MSI (s) (68:BC) [15:04:38:439]: APPCOMPAT: looking for appcompat database entry with ProductCode '{FC49F622-02E6-40D9-ACD9-92BDD4AF5979}'.
MSI (s) (68:BC) [15:04:38:439]: APPCOMPAT: no matching ProductCode found in database.
MSI (s) (68:BC) [15:04:38:439]: Machine policy value 'DisablePatch' is 0
MSI (s) (68:BC) [15:04:38:439]: Machine policy value 'AllowLockdownPatch' is 0
MSI (s) (68:BC) [15:04:38:439]: Machine policy value 'DisableLUAPatching' is 0
MSI (s) (68:BC) [15:04:38:439]: Machine policy value 'DisableFlyWeightPatching' is 0
MSI (s) (68:BC) [15:04:38:439]: APPCOMPAT: looking for appcompat database entry with ProductCode '{FC49F622-02E6-40D9-ACD9-92BDD4AF5979}'.
MSI (s) (68:BC) [15:04:38:439]: APPCOMPAT: no matching ProductCode found in database.
MSI (s) (68:BC) [15:04:38:439]: Transforms are not secure.
MSI (s) (68:BC) [15:04:38:439]: Command Line: UPGRADINGPRODUCTCODE={4871555F-F369-4159-9EF0-4BBDF07B6842} CLIENTPROCESSID=8344 CLIENTUILEVEL=0 MSICLIENTUSESEXTERNALUI=1 REMOVE=ALL 
MSI (s) (68:BC) [15:04:38:439]: PROPERTY CHANGE: Adding PackageCode property. Its value is '{6C49FAA1-5B11-4173-80A7-A7B3FA4313AE}'.
MSI (s) (68:BC) [15:04:38:439]: Product Code passed to Engine.Initialize:           '{FC49F622-02E6-40D9-ACD9-92BDD4AF5979}'
MSI (s) (68:BC) [15:04:38:439]: Product Code from property table before transforms: '{FC49F622-02E6-40D9-ACD9-92BDD4AF5979}'
MSI (s) (68:BC) [15:04:38:439]: Product Code from property table after transforms:  '{FC49F622-02E6-40D9-ACD9-92BDD4AF5979}'
MSI (s) (68:BC) [15:04:38:439]: Product registered: entering maintenance mode

Update:

This is indeed a bundle install. I looked at the msi being the culprit because I thought that Wix bundle would use msiexec to perform the uninstall.

In our build we use the search term "0.0.0.0" for the version in the bundle and msi then we do a replace with the correct version, and at the end of the build we revert the Bundle.wxs and Product.wxs.

When the installer is being worked on the developer must comment out the revert, in the build file, in order to work on the files. When the developer is done they need to set the version back to "0.0.0.0". In one of the installer checkins someone had to forgotten to change back to "0.0.0.0".

I tried the msi for the two versions by themselves, and upgrade did indeed remove the entry for the original install. However the bundle upgrade still leaves second entry, even though the version is correct.

Answer 1

Short Version

Many Instances: I think there are many versions of your package installed in many instances "on top of each other" - some of which are hidden from Add / Remove Programs because of the ARPSYSTEMCOMPONENT=1 setting being specified in (some of) the package(s). One of the installed instances has the same product code as the package you are trying to install - this triggers maintenance mode - since the product code is already registered as installed.

Package Code Confusion?: It is also possible that you have installed two or more versions of the same MSI with identical package codes (as opposed to product codes). This always causes mysterious problems - for example the problem you are seeing with maintenance mode (identical package GUIDs mean two different MSI files will be treated as the same file by definition - since the GUIDs are the same - X-Files ensues as msiexec.exe goes behind your back and runs from the old, cached MSI and not your new MSI).

Bundle?: As Phil writes, it could be a WiX bundle problem as well. Maybe try the script towards the bottom first to get a full list of what is installed - hidden from view or not.

---

Detailed Version

Possible Cause: It seems you are setting ARPSYSTEMCOMPONENT = 1 which will hide the setup from Add / Remove Programs (ARP). As far as I can see there are numerous package and product codes in the log that do not match the ones you specify in your question. It seems you may have several older, test versions installed on the system that could also be hidden from ARP, but are still installed on the box. Not sure why you say the current version shows up in ARP though? With ARPSYSTEMCOMPONENT set it should not do so.

Virtuals: As the motto always goes: test on virtuals when you see weird problems - in order to determine if you have an unclean test environment. Virtuals testing is crucial for me, but I often do it too late.

MSDN: ARPSYSTEMCOMPONENT.

---

UPDATE:

Culprit Mechanism: When you set the product code to auto-generate, every build will be able to install without maintenance mode showing up - even without authoring the upgrade table at all. When you combine this with hiding from Add / Remove Programs you suddenly can't tell what prior versions were installed. Duplicates installed on top of each other could pile up as you do test installs.

Since you do seem to auto-generate the product code, you should never experience the current problem: maintenance mode. This leads me to suspect a package code duplication problem. Or a bundle problem, as suggested by Phil. I have too little experience with bundles. Could it be a bundle bug? Or even a WiX bug?

---

Manual Uninstall: Maybe try to use the VBScript you can find here to export a list of MSI product codes currently installed on the system (whether they are hidden or not): How can I find the product GUID of an installed MSI setup? (towards bottom, under "Alternate Tools, section 3".

UPDATE: please see the inlined and modified script version below instead.

Once you have the list, try to uninstall the undesired test packages using:

msiexec.exe /x [ProductCode]

keep going with uninstalls until you have a "clean box".

Major Upgrade with full version spread: Alternatively, you can set a wide version range (min / max version) for your upgrade table to see if you can uninstall all existing versions with a regular major upgrade. Frankly I have never taken the time to test uninstall of multiple prior versions using major upgrades, but as far as I know it should work. N.B!: I don't think this will work if you have package code duplication.

Uninstall Related Products: Another answer showing how to uninstall all products sharing the same upgrade code. Note the disclaimer that a reboot could be triggered automatically when run in silent mode: Powershell: Uninstall application by UpgradeCode.

Uninstall By Product Name: And less sensible, but I will just add a link for safekeeping. Here is how you can uninstall an MSI package by product name: Is there an alternative to GUID when using msiexec to uninstall an application?

---

List All Installed MSI Products

UPDATE: Come to think of it, let me inline the linked script above with a couple of additions - this adds headers and publisher and package code to the export. This script should show all installed packages, including those hidden from Add / Remove Programs (if you also need Upgrade Code, then this is a little more complicated for technical reasons, here is a description of how it can be done in a clunky way - that link in turn has further links for how to retrieve upgrade codes with Powershell):

' Retrieve all ProductCodes (with ProductName and ProductVersion)

Set fso = CreateObject("Scripting.FileSystemObject")
Set output = fso.CreateTextFile("msiinfo.csv", True, True)
Set installer = CreateObject("WindowsInstaller.Installer")

output.writeline ("Product Code,Product Name,Product Version,Package Code, Publisher")

On Error Resume Next ' we ignore all errors

For Each product In installer.ProductsEx("", "", 7)
   productcode = product.ProductCode
   name = product.InstallProperty("ProductName")
   version=product.InstallProperty("VersionString")
   packagecode=product.InstallProperty("PackageCode")
   publisher=product.InstallProperty("Publisher")

   output.writeline (productcode & ", " & name & ", " & version  & ", " & packagecode & ", " & publisher)
Next

output.Close

Usage:

• Copy the script and paste into a *.vbs file on your desktop, and try to run it by double clicking. Your desktop must be writable for you, or you can use any other writable location.
• The output file is created in the folder where you run the script from (folder must be writable). The output file is called msiinfo.csv.
• Double click the file to open in a spreadsheet application, select comma as delimiter on import - OR - just open the file in Notepad or any text viewer.
• The content in the spreadsheet should be formatted in columns, if not do a manual file open and import the file selecting comma as the delimiter for the CSV file (comma separated values). Doing so will yield full spreadsheet capabilities, such as sorting by column - for example Publisher - so you see all your setups next to each other.

Answer 2

The log shows the upgrade was successful, installing the new product and removing the old one. The most likely explanation for the two entries in Programs&Features is that there is one for the actual MSI product and another from the WiX bootstrapper. You probably need to suppress the MSI one with ARPSYSTEMCOMPONENT=1 or with WiX bootstrapper support for suppressing the MSI's entry.