MajorUpgrade removes old version, but doesn't install the new version unless the MSI is run a second time

Question

I have two MSIs that are identical except for their ProductIds and Versions. I'm testing the MajorUpgrade pathway to make sure it's seamless for end users.

The MSI with the higher version shuts down the Windows service, and removes all the artifacts, but then fails at installing the "new" binaries with a 1603 error. In fact, it looks like it's executing the uninstall, including file and registry cleanup, but then failing to execute the installation.

If I run the higher versioned MSI again, the install works just fine: files and directories are created, and the Windows service is started, as well as the executable I've set to run after installation completes.

I generated a detailed log (snippets below), but fixing what appears to be the problem (the files aren't copied to the right places) isn't obvious.

Wix code:

<Product Id="*"
    Name="product name"
    Language="1033"
    Version="1.2.0"
    Manufacturer="Company Name"
    UpgradeCode="stable-upgrade-guid">

<!-- snip -->

<Property Id="WixShellExecTarget" Value="[#TheProgram.exe]" />
    <CustomAction Id="LaunchApplication"
                  BinaryKey="WixCA"
                  DllEntry="WixShellExec"
                  Impersonate="yes" />

    <MajorUpgrade DowngradeErrorMessage="A later version of [ProductName] is already installed. Setup will now exit." />

    <InstallExecuteSequence>
      <Custom Action="CheckForRunningProcesses_CA" After="InstallValidate" />
      <Custom Action="LaunchApplication" After="InstallFinalize"/>
    </InstallExecuteSequence>

I generated the log below with msiexec /i "product.msi" /l*v "upgrade.log". This seems to be the relevant bit:

MSI (s) (70:B0) [14:30:58:905]: Note: 1: 2318 2:  
MSI (s) (70:B0) [14:30:58:905]: Note: 1: 1321 2: C:\Config.Msi\ 3: 5 
MSI (s) (70:B0) [14:30:58:905]: Note: 1: 2205 2:  3: Error 
MSI (s) (70:B0) [14:30:58:905]: Note: 1: 2228 2:  3: Error 4: SELECT `Message` FROM `Error` WHERE `Error` = 2911 
DEBUG: Error 2911:  Could not remove the folder C:\Config.Msi\.
The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2911. The arguments are: C:\Config.Msi\, , 
MSI (s) (70:B0) [14:30:58:908]: Note: 1: 2318 2:  
MSI (s) (70:B0) [14:30:58:908]: Calling SRSetRestorePoint API. dwRestorePtType: 0, dwEventType: 103, llSequenceNumber: 14, szDescription: "".
MSI (s) (70:B0) [14:30:58:909]: The call to SRSetRestorePoint API succeeded. Returned status: 0.
MSI (s) (70:B0) [14:30:58:909]: Unlocking Server
MSI (s) (70:B0) [14:30:58:911]: PROPERTY CHANGE: Deleting UpdateStarted property. Its current value is '1'.
Action ended 14:30:58: InstallFinalize. Return value 1.
MSI (s) (70:B0) [14:30:58:912]: Doing action: LaunchApplication
MSI (s) (70:B0) [14:30:58:912]: Note: 1: 2205 2:  3: ActionText 
Action 14:30:58: LaunchApplication. 
Action start 14:30:58: LaunchApplication.
MSI (s) (70:58) [14:30:58:915]: Invoking remote custom action. DLL: C:\WINDOWS\Installer\MSI12D1.tmp, Entrypoint: WixShellExec
WixShellExec:  Error 0x80070002: ShellExec failed with return code 2.
WixShellExec:  Error 0x80070002: failed to launch target
CustomAction LaunchApplication returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox)
Action ended 14:30:58: LaunchApplication. Return value 3.
Action ended 14:30:58: INSTALL. Return value 3.

I believe ShellExec return code 2 means "file not found". (Indeed, the program files directory isn't present.)
I'm not sure what LaunchApplication having a return value of 3 means. I would guess "file not found".

Any idea why the MajorUpgrade removes the old version, but doesn't install the new version, but on a subsequent run, it does?

It's not exactly a duplicate. Similar symptom, completely different log files. The solution was the same, but the root problem was different. — rianjs

rianjs rianjs · Accepted Answer · 2017-09-18T19:47:01

Naturally I discover the answer moments after asking the question. The clue was in this StackOverflow question, which somehow I hadn't seen...

To work around the problem, you need to move your RemoveExistingProducts action later. If you're using the MajorUpgrade element then Schedule='afterInstallExecute' or Schedule='afterInstallFinalize' should do the trick. You'll need to be more careful with the Component Rules.

Changing the MajorUpdate's schedule to afterInstallExecute was the fix:

<MajorUpgrade
      DowngradeErrorMessage="A later version of [ProductName] is already installed. Setup will now exit."
      Schedule="afterInstallExecute" />

Not at all obvious.

MajorUpgrade removes old version, but doesn't install the new version unless the MSI is run a second time

1 Answers