[wix-devs] Burn bug: ARP entry

Hoover, Jacob Jacob.Hoover at greenheck.com
Tue Jan 16 14:41:46 PST 2018


I have the logs, for WixStdBA and my authoring it definitely isn't. I would expect a user canceling the install during ApplyExecute to be one of the more common things, and would be accounted for.

>From my quick digging,  ApplyExecute returning a rollback doesn't trigger the core to uncache. DoRollbackCache is only triggered if ApplyCache failed.

Note, for my test, the handful of unchanged packages do have a correct rollback cache action, so it looks like the plan is correct, just that we neglected to trigger it.

I was pondering adding a DoRollbackCache call inside of ApplyExecute if failed, however it seems the rollback cache plan is missing a terminating checkpoint, so it isn't as simple as calling that method to roll back the cache of the last package.

    // Cache checkpoints happen before the package is cached because downloading packages'
    // payloads will not roll themselves back the way installation packages rollback on
    // failure automatically.


-----Original Message-----
From: Rob Mensching [mailto:rob at firegiant.com] 
Sent: Tuesday, January 16, 2018 3:16 PM
To: WiX Toolset Developer Mailing List <wix-devs at lists.wixtoolset.org>; Bob Arnson <bob at firegiant.com>
Cc: Hoover, Jacob <Jacob.Hoover at greenheck.com>
Subject: RE: Burn bug: ARP entry

" And finally, would it make sense to add an optional feature to allow for invoking a repair on the previous bundle if the upgrade bundle can break the old bundle?"

I thought Burn did this. Maybe it doesn't in failure cases? Also, should consider getting the "MEND" operation in v4 so it isn't a full repair just a "fix things that look broken".



-----Original Message-----
From: wix-devs [mailto:wix-devs-bounces at lists.wixtoolset.org] On Behalf Of Hoover, Jacob via wix-devs
Sent: Tuesday, January 16, 2018 12:48 PM
To: WiX Toolset Developer Mailing List <wix-devs at lists.wixtoolset.org>; Bob Arnson <bob at firegiant.com>
Cc: Hoover, Jacob <Jacob.Hoover at greenheck.com>
Subject: Re: [wix-devs] Burn bug: ARP entry

I can confirm that removing all the rollback boundaries does in fact allow the ARP entry to be removed, however the cached packages seem to still stick around. I am going to verify this again with a newer version to ensure that the package cache wasn't tainted by the previous packages rollback boundaries.

Does anyone have any pointers on how to read the plan dump from a debug build, specifically around the rollbacks? I would have expected after the MSI logs for the user hitting cancel (Error 0x80070642: Failed to install MSI package.) that I would have seen the rollback happen, but I am only seeing it happen for the MSI that I canceled, and it not going back any further.

And finally, would it make sense to add an optional feature to allow for invoking a repair on the previous bundle if the upgrade bundle can break the old bundle?
Ex:
Bundle A contains MSI A v1.0, and another random package.
Bundle B contains MSI A v1.1 (it's a major upgrade of v1.0) , and another random package.

Install bundle A.
Install Bundle B, and time hitting cancel such that MSI A v1.1 was installed (and hence 1.0 removed).  This cancel will cause the rollback to remove v1.1 but as it doesn't know about bundle A, 1.0 won't be reinstalled.

-----Original Message-----
From: wix-devs [mailto:wix-devs-bounces at lists.wixtoolset.org] On Behalf Of Hoover, Jacob via wix-devs
Sent: Monday, January 8, 2018 11:27 AM
To: Bob Arnson <bob at firegiant.com>; WiX Toolset Developer Mailing List <wix-devs at lists.wixtoolset.org>
Cc: Hoover, Jacob <Jacob.Hoover at greenheck.com>
Subject: Re: [wix-devs] Burn bug: ARP entry

I am thinking the issue may relate to my usage of a RollbackBoundary. Still working on making a debug build to verify.

I do know my bundle has a few prerequisites that I wanted the bundle to leave installed, unless it's the last instance of the bundle to be removed. What is going to happen if I specify @Vital = No, and a user cancels during a major upgrade?

-----Original Message-----
From: Bob Arnson [mailto:bob at firegiant.com]
Sent: Friday, January 5, 2018 4:38 PM
To: WiX Toolset Developer Mailing List <wix-devs at lists.wixtoolset.org>
Cc: Hoover, Jacob <Jacob.Hoover at greenheck.com>
Subject: RE: Burn bug: ARP entry

Rollback should unregister. You might try with a debug build of the engine to get the plan dump.

-----Original Message-----
From: wix-devs [mailto:wix-devs-bounces at lists.wixtoolset.org] On Behalf Of Hoover, Jacob via wix-devs
Sent: Friday, 5 January, 2018 17:04
To: WiX Toolset Developer Mailing List <wix-devs at lists.wixtoolset.org>
Cc: Hoover, Jacob <Jacob.Hoover at greenheck.com>
Subject: [wix-devs] Burn bug: ARP entry

I just had a strange issue reported that I am able to reproduce. When canceling an upgrade, the ARP entry is not removed.

Ex:
Bundle v1 and v2. V2 is a Major Upgrade of v1.

Install v1.
Begin installing v2, but as soon as Apply starts executing the first package in the chain hit cancel.

At this point, ARP will have both v1 and v2.  I would have expected canceling to rollback not only the ARP entry, but to remove the bundle from the cache, but this doesn't seem to be the case. (Note, I am seeing this with WixStdBA but not the Wix MBA.)


(Canceling during cache which works)
[2D30:1FE0][2018-01-05T15:10:22]e000: Error 0x80070642: Failed while caching, aborting execution.
[1A44:3694][2018-01-05T15:10:22]i372: Session end, registration key: SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{GUID}, resume: None, restart: None, disable resume: No
[1A44:3694][2018-01-05T15:10:22]i330: Removed bundle dependency provider: { GUID }
[1A44:3694][2018-01-05T15:10:22]i352: Removing cached bundle: { GUID }, from path: C:\ProgramData\Package Cache\{ GUID }\
[1A44:3694][2018-01-05T15:10:23]i371: Updating session, registration key: SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{ GUID }, resume: None, restart initiated: No, disable resume: No
[2D30:1FE0][2018-01-05T15:10:23]i399: Apply complete, result: 0x80070642, restart: None, ba requested restart:  No

(Canceling during apply)
[3B74:43FC][2018-01-05T15:14:17]e000: Error 0x80070642: Failed to install MSI package.
[3B74:43FC][2018-01-05T15:14:17]e000: Error 0x80070642: Failed to execute MSI package.
[255C:402C][2018-01-05T15:14:17]e000: Error 0x80070642: Failed to configure per-machine MSI package.
[255C:402C][2018-01-05T15:14:17]i319: Applied execute package: XXXX, result: 0x80070642, restart: None
[255C:402C][2018-01-05T15:14:17]e000: Error 0x80070642: Failed to execute MSI package.
[3B74:43FC][2018-01-05T15:14:17]i318: Skipped rollback of package: XXXX, action: Uninstall, already: Absent
[255C:402C][2018-01-05T15:14:17]i319: Applied rollback package: XXXX, result: 0x0, restart: None
[3B74:43FC][2018-01-05T15:14:17]i329: Removed package dependency provider: { GUID }, package: XXXX
[3B74:43FC][2018-01-05T15:14:17]i351: Removing cached package: XXXX, from path: C:\ProgramData\Package Cache\{ GUID }v4.25.21.1383\
[3B74:43FC][2018-01-05T15:14:17]i372: Session end, registration key: SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{ GUID }, resume: ARP, restart: None, disable resume: No
[3B74:43FC][2018-01-05T15:14:17]i371: Updating session, registration key: SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{ GUID }, resume: ARP, restart initiated: No, disable resume: No
[255C:402C][2018-01-05T15:14:17]i399: Apply complete, result: 0x80070642, restart: None, ba requested restart:  No
[255C:402C][2018-01-05T15:14:31]i500: Shutting down, exit code: 0x642

Thanks,
Jacob



More information about the wix-devs mailing list