[wix-users] Previous package not found (and therefore not uninstalled) during major upgrade
Rob Mensching
rob at firegiant.com
Wed Feb 21 10:18:27 PST 2018
So, I have a theory why the upgrade logic isn’t “working”.
In the failed bundle log (thank you for providing all of the log files), https://keybase.pub/zanderz/wixupgrade/test/failure/Keybase_20180216193030.log, there is this:
[2200:27D8][2018-02-16T19:30:31]i301: Applying execute package: KeybasePrograms, action: Install, path: C:\Users\Michal\AppData\Local\Package Cache\{7DBE161A-7943-4288-BD53-35939F3CE32E}v1.0.40.19\Keybase.msi, arguments: ' ARPSYSTEMCOMPONENT="1" MSIFASTINSTALL="7" DOKANPRODUCT86="{65A3A986-3DC3-0100-0004-170726135020}" DOKANPRODUCT64="{65A3A964-3DC3-0100-0004-170726135020}" BUNDLEKEY="{76e53b26-5054-44a7-b2bd-506ac83f094e}"'
[2200:27D8][2018-02-16T19:31:32]e000: Error 0x80070643: Failed to install MSI package.
[2200:27D8][2018-02-16T19:31:32]e000: Error 0x80070643: Failed to configure per-user MSI package.
[2200:27D8][2018-02-16T19:31:32]w348: Application requested retry of package: KeybasePrograms, encountered error: 0x80070643. Retrying...
That means that the “balretry” logic (https://github.com/wixtoolset/wix3/blob/7c8457fa3802858add8981b92996e19574e762da/src/libs/balutil/balretry.cpp#L98-L170) kicked in. In this case, it’s the “Error 1303” (insufficient privileges) that is causing the retry.
The 1303 error is very likely the root issue.
But, you might be asking, “What happened to the upgrade logic?”
Well, the default MajorUpgrade logic schedules the upgrade “early”. We do this to absolutely minimize issues with Component Rules. The downside is that the old product is removed first then the new product is installed. If the new product fails to install, you end up with neither product installed.
So, my hypothesis is that the first attempt to install Keybase.msi successfully upgraded (removed) the old version and then hit a 1303. Since 1303 is on the retry list, Burn attempted to install the MSI again (because in a lot of cases, it’s a timing issue and retrying works). This time around, no upgrade is necessary but the new MSI failed again. Burn tries 3 times before giving up (you can see each retry in the log linked above).
This raises the next issue, on retry Burn overwrites the original log file. That hides (uh, destroys) information that could be useful for debugging. Not end of the world, certainly not blocking, but not ideal.
Anyway, that’s my theory. If you figure out what is inconsistently locking up the “C:\Users\Michal\AppData\Local\Keybase\Gui” folder, I expect you will have found your solution:
MSI (s) (EC:98) [19:31:48:642]: Product: Keybase Apps -- Error 1303. The installer has insufficient privileges to access this directory: C:\Users\Michal\AppData\Local\Keybase\Gui. The installation cannot continue. Log on as administrator or contact your system administrator.
The Burn logging design issue is a thing too.
PS: This is sort of in-depth analysis of an issue is what we do at FireGiant. We would also consider addressing the Burn design issue as well. I personally jumped in because this thread just happened to pique my interest. Normally, my sig applies. <smile/>
Keep coding, you know I am.
_____________________________________________________________
Short replies here. Complete answers over there: http://www.firegiant.com/
From: Steve Sanders [mailto:steve at keyba.se]
Sent: Wednesday, February 21, 2018 9:23 AM
To: Rob Mensching <rob at firegiant.com>
Cc: WiX Toolset Users Mailing List <wix-users at lists.wixtoolset.org>; Edwin Castro <egcastr at gmail.com>
Subject: Re: [wix-users] Previous package not found (and therefore not uninstalled) during major upgrade
Wow, Rob Mensching himself! Thanks for taking a look.
I am certain these installers were all run as user, not elevated. In one case I managed to duplicate it myself (out of 50+ upgrades), and in another case it was a knowledgeable colleague I trust to report accurately. I assume you're referring to the lack of permissions error to write in %localappdata%\Keybase\Gui ? I believe it is because one of our processes installed to that directory was still running because our custom actions to shut them down were not run because MajorUpgrade was not detected.
So far from the helpful info in this thread, it sounds like Windows itself is failing to find the previous installation in FindRelatedProducts, though the .msi files have proper upgrade tables.
Again, some of our processes are windowless (lower-case keybase.exe, kbfsdokan.exe, upd.exe) and we have visible processes called upper-case Keybase.exe which are electron based. Maybe the fact that these windowless ones can't be identified normally is a factor?
I have no idea what to do about this and the hacks I'm considering are 1. passing an argument from the burn bundle, which seems to detect MajorUpgrade even when the MSI can't, or 2. check a registry key to see if we're installed already
Option 3 is to rewrite it without Wix, like my colleagues keep suggesting, but I think it would just lead to new, different pain.
On Tue, Feb 20, 2018 at 7:33 PM, Rob Mensching <rob at firegiant.com<mailto:rob at firegiant.com>> wrote:
Is it possible, one MSI is installed per-user and the other being installed per-machine?
_____________________________________________________________
Short replies here. Complete answers over there: http://www.firegiant.com/
-----Original Message-----
From: wix-users [mailto:wix-users-bounces at lists.wixtoolset.org<mailto:wix-users-bounces at lists.wixtoolset.org>] On Behalf Of Steve Sanders via wix-users
Sent: Tuesday, February 20, 2018 5:31 PM
To: Edwin Castro <egcastr at gmail.com<mailto:egcastr at gmail.com>>
Cc: Steve Sanders <steve at keyba.se<mailto:steve at keyba.se>>; WiX Toolset Users Mailing List <wix-users at lists.wixtoolset.org<mailto:wix-users at lists.wixtoolset.org>>
Subject: Re: [wix-users] Previous package not found (and therefore not uninstalled) during major upgrade
I tried to detail above, and linked the actual logs - not sure what you're asking.
> When comparing side by side, the successful upgrade case contains:
```
PROPERTY CHANGE: Adding WIX_UPGRADE_DETECTED property. Its value is '{FC280A6D-DEED-4892-8C86-68467C1647CB}'.
PROPERTY CHANGE: Adding MIGRATE property. Its value is '{FC280A6D-DEED-4892-8C86-68467C1647CB}'.
```
> Also seen in a successful log is: `Command Line:
> UPGRADINGPRODUCTCODE={
7DBE161A-7943-4288-BD53-35939F3CE32E} CLIENTPROCESSID=6872 CLIENTUILEVEL=3
MSICLIENTUSESEXTERNALUI=1 REMOVE=ALL `
> and associated values of `UPGRADINGPRODUCTCODE` In the failure log,
> UPGRADINGPRODUCTCODE and WIX_UPGRADE_DETECTED don't
seem to be set.
On Tue, Feb 20, 2018 at 5:23 PM, Edwin Castro <egcastr at gmail.com<mailto:egcastr at gmail.com>> wrote:
> That's a bundle log rather than an MSI log. That detection is for the
> bundle rather than for the MSI. What does the bundle log say for the
> MSI package? What does the MSI log say?
>
> --
> Edwin G. Castro
>
> On Tue, Feb 20, 2018 at 5:12 PM, Steve Sanders <steve at keyba.se<mailto:steve at keyba.se>> wrote:
>
>> Positive it's a MajorUpgrade. Again, this problem happens only
>> intermittently with the same 2 bundles. In both success and failure
>> cases, the burn log contains:
>> [2200:27D8][2018-02-16T19:30:30]i102: Detected related bundle: {
>> 48d54dff-2ea8-461a-a1f3-bea0d2c2c26f}, type: Upgrade, scope: PerUser,
>> version: 1.0.39.39, operation: MajorUpgrade
>>
>> The app package has Product Id="*" , so it is always a major upgrade,
>> AFAIK.
>>
>> Logs are already verbose AFAIK, they're linked to above.
>>
>> On Tue, Feb 20, 2018 at 3:28 PM, Edwin Castro <egcastr at gmail.com<mailto:egcastr at gmail.com>> wrote:
>>
>>> Are you sure you have a MajorUpgrade? Is it at all possible that the
>>> Windows Installer thinks you're modifying or repairing a currently
>>> installed product? What does the verbose log say? What happens when
>>> the ProductVersion changes but the ProductCode does not?
>>>
>>> --
>>> Edwin G. Castro
>>>
>>> On Tue, Feb 20, 2018 at 3:22 PM, Steve Sanders via wix-users <
>>> wix-users at lists.wixtoolset.org<mailto:wix-users at lists.wixtoolset.org>> wrote:
>>>
>>>> I don't remember, maybe it was a FilesInUse chicken/egg problem, as
>>>> in https://buildmaestro.wordpress.com/2011/03/14/suppress-files
>>>> inuse-dialog-on-uninstall/
>>>> ? I could theoretically shut down our processes before that, but
>>>> would then need a rollback option to restart them on
>>>> failure/cancel/full disk, etc.
>>>> One of our requirements is to support silent update.
>>>>
>>>> On Tue, Feb 20, 2018 at 2:22 PM, Hoover, Jacob <
>>>> Jacob.Hoover at greenheck.com<mailto:Jacob.Hoover at greenheck.com>>
>>>> wrote:
>>>>
>>>> > If Language is null or an empty string (""), FindRelatedProducts
>>>> ignores
>>>> > *msidbUpgradeAttributesLanguagesExclusive* and detects all languages.
>>>> >
>>>> >
>>>> >
>>>> > The one thing I do think is strange, why do you suppress
>>>> InstallValidate?
>>>> >
>>>> >
>>>> >
>>>> > <InstallValidate Suppress="yes">FAKE_PROPERTY</InstallValidate>
>>>> >
>>>> >
>>>> >
>>>> > *From:* Steve Sanders [mailto:steve at keyba.se<mailto:steve at keyba.se>]
>>>> > *Sent:* Tuesday, February 20, 2018 4:07 PM
>>>> > *To:* Hoover, Jacob <Jacob.Hoover at greenheck.com<mailto:Jacob.Hoover at greenheck.com>>
>>>> > *Cc:* WiX Toolset Users Mailing List
>>>> > <wix-users at lists.wixtoolset.org<mailto:wix-users at lists.wixtoolset.org>>
>>>> >
>>>> > *Subject:* Re: [wix-users] Previous package not found (and
>>>> > therefore
>>>> not
>>>>
>>>> > uninstalled) during major upgrade
>>>> >
>>>> >
>>>> >
>>>> > According to Orca, the upgrade tables look like this, same as one
>>>> built
>>>> > with Wix 3.9 except for the version of course. Is it a problem
>>>> > that Language is empty?
>>>> >
>>>> >
>>>> >
>>>> > UpgradeCode VersionMin VersionMax Language Attributes
>>>> > Remove ActionProperty
>>>> >
>>>> > s38 S20 S20 S255 i4 S255 s72
>>>> >
>>>> > Upgrade UpgradeCode VersionMin VersionMax Language
>>>> > Attributes
>>>> >
>>>> > {C118F7EC-9A1D-4FF1-91F5-15D208499D7B}
>>>> > 1.0.39.39 513
>>>> WIX_UPGRADE_DETECTED
>>>> >
>>>> > {C118F7EC-9A1D-4FF1-91F5-15D208499D7B} 1.0.39.39
>>>> > 2 WIX_DOWNGRADE_DETECTED
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >
>>>> > UpgradeCode VersionMin VersionMax Language Attributes
>>>> > Remove ActionProperty
>>>> >
>>>> > s38 S20 S20 S255 i4 S255 s72
>>>> >
>>>> > Upgrade UpgradeCode VersionMin VersionMax Language
>>>> > Attributes
>>>> >
>>>> > {C118F7EC-9A1D-4FF1-91F5-15D208499D7B}
>>>> > 1.0.40.19 513
>>>> WIX_UPGRADE_DETECTED
>>>> >
>>>> > {C118F7EC-9A1D-4FF1-91F5-15D208499D7B} 1.0.40.19
>>>> > 2 WIX_DOWNGRADE_DETECTED
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >
>>>> > and one from 6 months ago:
>>>> >
>>>> > UpgradeCode VersionMin VersionMax Language Attributes
>>>> > Remove ActionProperty
>>>> >
>>>> > s38 S20 S20 S255 i4 S255 s72
>>>> >
>>>> > Upgrade UpgradeCode VersionMin VersionMax Language
>>>> > Attributes
>>>> >
>>>> > {C118F7EC-9A1D-4FF1-91F5-15D208499D7B}
>>>> > 1.0.26.918 513 WIX_UPGRADE_DETECTED
>>>> >
>>>> > {C118F7EC-9A1D-4FF1-91F5-15D208499D7B} 1.0.26.918
>>>> > 2 WIX_DOWNGRADE_DETECTED
>>>> >
>>>> >
>>>> >
>>>> > On Tue, Feb 20, 2018 at 1:17 PM, Steve Sanders <steve at keyba.se<mailto:steve at keyba.se>>
>>>> wrote:
>>>> >
>>>> > I tried to figure out what the Upgrade table is and how to find
>>>> > it,
>>>> but
>>>> > nearest I can tell, Wix is supposed to handle/populate it from
>>>> > the MajorUpgrade element:
>>>> > <MajorUpgrade DowngradeErrorMessage="A newer version of Keybase
>>>> > is
>>>> already
>>>> > installed." AllowSameVersionUpgrades="yes" />
>>>> >
>>>> >
>>>> >
>>>> > This hasn't changed for more than a year - I suppose it is
>>>> > possible
>>>> that
>>>> > wix 3.11 changed the way it populates this upgrade table? I will
>>>> > try dumping it from some MSIs using Orca and see.
>>>> >
>>>> >
>>>> >
>>>> > On Tue, Feb 20, 2018 at 10:48 AM, Hoover, Jacob <
>>>> > Jacob.Hoover at greenheck.com<mailto:Jacob.Hoover at greenheck.com>> wrote:
>>>> >
>>>> > Well, if FindRelatedProduct is truly failing then it's a windows
>>>> installer
>>>> > issue. However I seriously don't think this is the issue. Per
>>>> > https://msdn.microsoft.com/en-us/library/windows/desktop/
>>>> > aa368600%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396<tel:2147217396> I would
>>>> compare
>>>> > the Upgrade table from an old "never broken" install and a newer
>>>> "sometimes
>>>> > broken" installer.
>>>> >
>>>> >
>>>> >
>>>> > -----Original Message-----
>>>> > From: wix-users [mailto:wix-users-bounces at lists.wixtoolset.org<mailto:wix-users-bounces at lists.wixtoolset.org>]
>>>> > On
>>>> Behalf
>>>> > Of Steve Sanders via wix-users
>>>> > Sent: Tuesday, February 20, 2018 12:38 PM
>>>> > To: WiX Toolset Users Mailing List
>>>> > <wix-users at lists.wixtoolset.org<mailto:wix-users at lists.wixtoolset.org>>
>>>> > Cc: Steve Sanders <steve at keyba.se<mailto:steve at keyba.se>>
>>>> >
>>>> > Subject: Re: [wix-users] Previous package not found (and
>>>> > therefore not
>>>> > uninstalled) during major upgrade
>>>> >
>>>> > I am positive because of the associated updater log, among other
>>>> reasons,
>>>> > which shows version 1.0.39-20180121191330+5e57981 (that's the
>>>> > semantic version, the windows version being 1.0.39.39) applied
>>>> > 2018/01/23
>>>> 11:57:11,
>>>> > then the updater considers that version current when it checks
>>>> > for
>>>> the next
>>>> > update:
>>>> > 2018/02/16 19:30:03 INFO Checking for update, current version is
>>>> > 1.0.39-20180121191330+5e57981
>>>> > (updater gets this version by running the installed program with
>>>> > the "version" argument.)
>>>> >
>>>> > Again, our custom actions are supposed to close our processes in
>>>> > the upgrade case, but if upgrade case is not detected, they can't
>>>> > close
>>>> the
>>>> > processes.
>>>> >
>>>> > I guess we could hack around this with some registry entries, but
>>>> detecting
>>>> > + applying upgrades is one of the main reasons to use a tool like
>>>> > + Wix
>>>> I
>>>> > thought. Again, this happens only intermittently, and didn't seem
>>>> > to happen ever with Wix 3.9.
>>>> >
>>>> > Thanks again, everyone, for taking a look.
>>>> >
>>>> > On Tue, Feb 20, 2018 at 3:23 AM, Nir Bar via wix-users <
>>>> > wix-users at lists.wixtoolset.org<mailto:wix-users at lists.wixtoolset.org>> wrote:
>>>> >
>>>> > > The failing log says the the RESTART MANAGER is disabled so
>>>> FilesInUse
>>>> > > is used. FilesInUse can only detect applications with a window.
>>>> > >
>>>> > > However, this has nothing to do with upgrade detection. I've
>>>> > > never encountered a false-false upgrade detection.
>>>> > > Are you absolutely sure that another version is already installed?
>>>> > >
>>>> > >
>>>> > >
>>>> > > --
>>>> > > Nir Bar, Independent WiX Expert. Creator of-
>>>> > > JetBA: WiX WPF Bootstrapper User Interface Framework
>>>> > >
>>>> > > JetBA++: WiX Native Bootstrapper User Interface Framework
More information about the wix-users
mailing list