[wix-devs] Burn bug: ARP entry

Hoover, Jacob Jacob.Hoover at greenheck.com
Fri Jan 19 09:29:53 PST 2018


[7210:09A8][2018-01-19T11:28:30]i000: --- Begin plan dump ---
[7210:09A8][2018-01-19T11:28:30]i000: Plan action: Install
[7210:09A8][2018-01-19T11:28:30]i000:      per-machine: true
[7210:09A8][2018-01-19T11:28:30]i000:      keep registration by default: false
[7210:09A8][2018-01-19T11:28:30]i000:      estimated size: 274708
[7210:09A8][2018-01-19T11:28:30]i000: Plan cache size: 274653
[7210:09A8][2018-01-19T11:28:30]i000:    Cache action[0]: CHECKPOINT id: 1
[7210:09A8][2018-01-19T11:28:30]i000:    Cache action[1]: PACKAGE_START id: FailingPackage.msi, plan index for skip: 6, payloads to cache: 2, bytes to cache: 241780, skip until retried: No
[7210:09A8][2018-01-19T11:28:30]i000:    Cache action[2]: ACQUIRE_PAYLOAD package id: FailingPackage.msi, payload id: FailingPackage.msi, source path: payload\failing\FailingPackage.msi, working path: C:\Users\hoover\AppData\Local\Temp\{83EF09CC-9FC9-478B-A714-8824A86828A3}\FailingPackage.msi, skip until retried: No
[7210:09A8][2018-01-19T11:28:30]i000:    Cache action[3]: CACHE_PAYLOAD package id: FailingPackage.msi, payload id: FailingPackage.msi, working path: C:\Users\hoover\AppData\Local\Temp\{83EF09CC-9FC9-478B-A714-8824A86828A3}\FailingPackage.msi, operation: move, skip until retried: No, retry action: 2
[7210:09A8][2018-01-19T11:28:30]i000:    Cache action[4]: ACQUIRE_PAYLOAD package id: FailingPackage.msi, payload id: cabAF8DAFFA35132BD6767F6D6CBE9566A2, source path: payload\failing\cab1.cab, working path: C:\Users\hoover\AppData\Local\Temp\{83EF09CC-9FC9-478B-A714-8824A86828A3}\cabAF8DAFFA35132BD6767F6D6CBE9566A2, skip until retried: No
[7210:09A8][2018-01-19T11:28:30]i000:    Cache action[5]: CACHE_PAYLOAD package id: FailingPackage.msi, payload id: cabAF8DAFFA35132BD6767F6D6CBE9566A2, working path: C:\Users\hoover\AppData\Local\Temp\{83EF09CC-9FC9-478B-A714-8824A86828A3}\cabAF8DAFFA35132BD6767F6D6CBE9566A2, operation: move, skip until retried: No, retry action: 4
[7210:09A8][2018-01-19T11:28:30]i000:    Cache action[6]: PACKAGE_STOP id: FailingPackage.msi, skip until retried: No
[7210:09A8][2018-01-19T11:28:30]i000:    Cache action[7]: SIGNAL_SYNCPOINT event handle: 0x41c, skip until retried: No
[7210:09A8][2018-01-19T11:28:30]i000:    Cache action[8]: CHECKPOINT id: 7
[7210:09A8][2018-01-19T11:28:30]i000:    Cache action[9]: PACKAGE_START id: SecondPackage.msi, plan index for skip: 14, payloads to cache: 2, bytes to cache: 32873, skip until retried: No
[7210:09A8][2018-01-19T11:28:30]i000:    Cache action[10]: ACQUIRE_PAYLOAD package id: SecondPackage.msi, payload id: SecondPackage.msi, source path: payload\second\SecondPackage.msi, working path: C:\Users\hoover\AppData\Local\Temp\{83EF09CC-9FC9-478B-A714-8824A86828A3}\SecondPackage.msi, skip until retried: No
[7210:09A8][2018-01-19T11:28:30]i000:    Cache action[11]: CACHE_PAYLOAD package id: SecondPackage.msi, payload id: SecondPackage.msi, working path: C:\Users\hoover\AppData\Local\Temp\{83EF09CC-9FC9-478B-A714-8824A86828A3}\SecondPackage.msi, operation: move, skip until retried: No, retry action: 10
[7210:09A8][2018-01-19T11:28:30]i000:    Cache action[12]: ACQUIRE_PAYLOAD package id: SecondPackage.msi, payload id: cab1C906C19D88FC6AB052BB72B38FC7E56, source path: payload\second\cab1.cab, working path: C:\Users\hoover\AppData\Local\Temp\{83EF09CC-9FC9-478B-A714-8824A86828A3}\cab1C906C19D88FC6AB052BB72B38FC7E56, skip until retried: No
[7210:09A8][2018-01-19T11:28:30]i000:    Cache action[13]: CACHE_PAYLOAD package id: SecondPackage.msi, payload id: cab1C906C19D88FC6AB052BB72B38FC7E56, working path: C:\Users\hoover\AppData\Local\Temp\{83EF09CC-9FC9-478B-A714-8824A86828A3}\cab1C906C19D88FC6AB052BB72B38FC7E56, operation: move, skip until retried: No, retry action: 12
[7210:09A8][2018-01-19T11:28:30]i000:    Cache action[14]: PACKAGE_STOP id: SecondPackage.msi, skip until retried: No
[7210:09A8][2018-01-19T11:28:30]i000:    Cache action[15]: SIGNAL_SYNCPOINT event handle: 0x420, skip until retried: No
[7210:09A8][2018-01-19T11:28:30]i000:    Rollback cache action[0]: CHECKPOINT id: 1
[7210:09A8][2018-01-19T11:28:30]i000:    Rollback cache action[1]: ROLLBACK_PACKAGE id: FailingPackage.msi, skip until retried: No
[7210:09A8][2018-01-19T11:28:30]i000:    Rollback cache action[2]: CHECKPOINT id: 7
[7210:09A8][2018-01-19T11:28:30]i000:    Rollback cache action[3]: ROLLBACK_PACKAGE id: SecondPackage.msi, skip until retried: No
[7210:09A8][2018-01-19T11:28:30]i000: Plan execute package count: 2
[7210:09A8][2018-01-19T11:28:30]i000:      overall progress ticks: 4
[7210:09A8][2018-01-19T11:28:30]i000:    Execute action[0]: ROLLBACK_BOUNDARY id: WixDefaultBoundary, vital: yes
[7210:09A8][2018-01-19T11:28:30]i000:    Execute action[1]: WAIT_SYNCPOINT event handle: 0x41c
[7210:09A8][2018-01-19T11:28:30]i000:    Execute action[2]: CHECKPOINT id: 2
[7210:09A8][2018-01-19T11:28:30]i000:    Execute action[3]: CHECKPOINT id: 3
[7210:09A8][2018-01-19T11:28:30]i000:    Execute action[4]: PACKAGE_PROVIDER package id: FailingPackage.msi, action: 1
[7210:09A8][2018-01-19T11:28:30]i000:    Execute action[5]: CHECKPOINT id: 4
[7210:09A8][2018-01-19T11:28:30]i000:    Execute action[6]: MSI_PACKAGE package id: FailingPackage.msi, action: Install, ui level: 258, log path: C:\Users\hoover\AppData\Local\Temp\Bootstrapper_20180119112827_000_FailingPackage.msi.log, logging attrib: 0
[7210:09A8][2018-01-19T11:28:30]i000:    Execute action[7]: CHECKPOINT id: 5
[7210:09A8][2018-01-19T11:28:30]i000:    Execute action[8]: REGISTRATION keep: yes
[7210:09A8][2018-01-19T11:28:30]i000:    Execute action[9]: PACKAGE_DEPENDENCY package id: FailingPackage.msi, bundle provider key: {eb292bef-2c4b-458a-a952-bb58b46b0ba9}, action: 1
[7210:09A8][2018-01-19T11:28:30]i000:    Execute action[10]: CHECKPOINT id: 6
[7210:09A8][2018-01-19T11:28:30]i000:    Execute action[11]: WAIT_SYNCPOINT event handle: 0x420
[7210:09A8][2018-01-19T11:28:30]i000:    Execute action[12]: CHECKPOINT id: 8
[7210:09A8][2018-01-19T11:28:30]i000:    Execute action[13]: CHECKPOINT id: 9
[7210:09A8][2018-01-19T11:28:30]i000:    Execute action[14]: PACKAGE_PROVIDER package id: SecondPackage.msi, action: 1
[7210:09A8][2018-01-19T11:28:30]i000:    Execute action[15]: CHECKPOINT id: 10
[7210:09A8][2018-01-19T11:28:30]i000:    Execute action[16]: MSI_PACKAGE package id: SecondPackage.msi, action: Install, ui level: 258, log path: C:\Users\hoover\AppData\Local\Temp\Bootstrapper_20180119112827_001_SecondPackage.msi.log, logging attrib: 0
[7210:09A8][2018-01-19T11:28:30]i000:    Execute action[17]: CHECKPOINT id: 11
[7210:09A8][2018-01-19T11:28:30]i000:    Execute action[18]: PACKAGE_DEPENDENCY package id: SecondPackage.msi, bundle provider key: {eb292bef-2c4b-458a-a952-bb58b46b0ba9}, action: 1
[7210:09A8][2018-01-19T11:28:30]i000:    Execute action[19]: CHECKPOINT id: 12
[7210:09A8][2018-01-19T11:28:30]i000:    Execute action[20]: CHECKPOINT id: 13
[7210:09A8][2018-01-19T11:28:30]i000:    Rollback action[0]: ROLLBACK_BOUNDARY id: WixDefaultBoundary, vital: yes
[7210:09A8][2018-01-19T11:28:30]i000:    Rollback action[1]: REGISTRATION keep: no
[7210:09A8][2018-01-19T11:28:30]i000:    Rollback action[2]: UNCACHE_PACKAGE id: FailingPackage.msi
[7210:09A8][2018-01-19T11:28:30]i000:    Rollback action[3]: CHECKPOINT id: 2
[7210:09A8][2018-01-19T11:28:30]i000:    Rollback action[4]: PACKAGE_PROVIDER package id: FailingPackage.msi, action: 2
[7210:09A8][2018-01-19T11:28:30]i000:    Rollback action[5]: CHECKPOINT id: 3
[7210:09A8][2018-01-19T11:28:30]i000:    Rollback action[6]: MSI_PACKAGE package id: FailingPackage.msi, action: Uninstall, ui level: 258, log path: C:\Users\hoover\AppData\Local\Temp\Bootstrapper_20180119112827_000_FailingPackage.msi_rollback.log, logging attrib: 0
[7210:09A8][2018-01-19T11:28:30]i000:    Rollback action[7]: CHECKPOINT id: 4
[7210:09A8][2018-01-19T11:28:30]i000:    Rollback action[8]: PACKAGE_DEPENDENCY package id: FailingPackage.msi, bundle provider key: {eb292bef-2c4b-458a-a952-bb58b46b0ba9}, action: 2
[7210:09A8][2018-01-19T11:28:30]i000:    Rollback action[9]: CHECKPOINT id: 5
[7210:09A8][2018-01-19T11:28:30]i000:    Rollback action[10]: CHECKPOINT id: 6
[7210:09A8][2018-01-19T11:28:30]i000:    Rollback action[11]: UNCACHE_PACKAGE id: SecondPackage.msi
[7210:09A8][2018-01-19T11:28:30]i000:    Rollback action[12]: CHECKPOINT id: 8
[7210:09A8][2018-01-19T11:28:30]i000:    Rollback action[13]: PACKAGE_PROVIDER package id: SecondPackage.msi, action: 2
[7210:09A8][2018-01-19T11:28:30]i000:    Rollback action[14]: CHECKPOINT id: 9
[7210:09A8][2018-01-19T11:28:30]i000:    Rollback action[15]: MSI_PACKAGE package id: SecondPackage.msi, action: Uninstall, ui level: 258, log path: C:\Users\hoover\AppData\Local\Temp\Bootstrapper_20180119112827_001_SecondPackage.msi_rollback.log, logging attrib: 0
[7210:09A8][2018-01-19T11:28:30]i000:    Rollback action[16]: CHECKPOINT id: 10
[7210:09A8][2018-01-19T11:28:30]i000:    Rollback action[17]: PACKAGE_DEPENDENCY package id: SecondPackage.msi, bundle provider key: {eb292bef-2c4b-458a-a952-bb58b46b0ba9}, action: 2
[7210:09A8][2018-01-19T11:28:30]i000:    Rollback action[18]: CHECKPOINT id: 11
[7210:09A8][2018-01-19T11:28:30]i000:    Rollback action[19]: CHECKPOINT id: 12
[7210:09A8][2018-01-19T11:28:30]i000:    Rollback action[20]: CHECKPOINT id: 13
[7210:09A8][2018-01-19T11:28:30]i000:    Dependency action[0]: PLANNED_PROVIDER key: {eb292bef-2c4b-458a-a952-bb58b46b0ba9}, name: (null)
[7210:09A8][2018-01-19T11:28:30]i000: --- End plan dump ---

-----Original Message-----
From: wix-devs [mailto:wix-devs-bounces at lists.wixtoolset.org] On Behalf Of Sean Hall via wix-devs
Sent: Friday, January 19, 2018 11:01 AM
To: WiX Toolset Developer Mailing List <wix-devs at lists.wixtoolset.org>
Cc: Sean Hall <r.sean.hall at gmail.com>
Subject: Re: [wix-devs] Burn bug: ARP entry

The plan from your example MSI should be fine.

On Fri, Jan 19, 2018 at 10:44 AM, Hoover, Jacob <Jacob.Hoover at greenheck.com>
wrote:

> For a synchronous cache, having apply execute calling DoRollbackCache 
> is fairly simple and just requires the cache rollback plan to have a 
> terminating checkpoint added. However, if we are doing asynchronous 
> cache, do we care at what point the cache plan was, or do we just 
> rollback the whole thing since the logic to remove cached packages 
> already handles the directory not existing?
>
> Do you want a debug build plan of my example MSI or a real world example?
>
> -----Original Message-----
> From: wix-devs [mailto:wix-devs-bounces at lists.wixtoolset.org] On 
> Behalf Of Sean Hall via wix-devs
> Sent: Thursday, January 18, 2018 5:46 PM
> To: WiX Toolset Developer Mailing List <wix-devs at lists.wixtoolset.org>
> Cc: Sean Hall <r.sean.hall at gmail.com>
> Subject: Re: [wix-devs] Burn bug: ARP entry
>
> I think we really need to see the plan. From what Jacob was saying, 
> the correct actions are already in the plan. It's just that no one's 
> executing the cache rollback actions.
>
> On Thu, Jan 18, 2018 at 5:43 PM, Rob Mensching <rob at firegiant.com> wrote:
>
> > Burn already has code to clean up the cache for Cache="no" Packages.
> > May be in the Plan() add execute rollback actions for all payloads 
> > that are planned to be cached (aka: not cached already). Then the 
> > rollback and just delete payloads based on actions (less thinking) 
> > and if payload does not exist (didn't get to it in async download) 
> > then the
> action is a no-op.
> >
> > In general, it's best to do all the "thinking" in the plan and keep 
> > cache/execute as simple execution of the plan (cache is a mess 
> > because of retry logic).
> >
> > Regards,
> >
> >   Rob Mensching
> >   CEO
> >   FireGiant
> > _______________________________________________________________
> >  FireGiant  |  Dedicated support for the WiX toolset  | 
> > http://www.firegiant.com/
> >
> > -----Original Message-----
> > From: wix-devs [mailto:wix-devs-bounces at lists.wixtoolset.org] On 
> > Behalf Of Sean Hall via wix-devs
> > Sent: Thursday, January 18, 2018 3:38 PM
> > To: WiX Toolset Developer Mailing List 
> > <wix-devs at lists.wixtoolset.org>
> > Cc: Sean Hall <r.sean.hall at gmail.com>
> > Subject: Re: [wix-devs] Burn bug: ARP entry
> >
> > I know I said ideally the Cache thread would take care of it, but 
> > that sounds pretty complicated to keep the Cache thread alive until 
> > the Apply thread completes. I think it would be easier to make the 
> > Apply thread detect whether it's in parallel cache mode, and if it's 
> > in synchronous mode then do the appropriate cache rollback actions 
> > itself. Ideally, this would be a simple "if synchronous then call 
> > this method over here that the cache thread would have called".
> >
> > On Thu, Jan 18, 2018 at 4:10 PM, Hoover, Jacob 
> > <Jacob.Hoover at greenheck.com
> > >
> > wrote:
> >
> > > Sorry for the spam but this has me a bit perplexed.  It looks like 
> > > Apply Execute, on failure to install a package it is only 
> > > un-caching the package that failed. This is setup by 
> > > PlanExecuteCacheSyncAndRollbac
> > k.
> > >
> > > I do think a more robust option is going to be to invoke the 
> > > entire rollback cache action sequence. That’s what my initial 
> > > "kludge" was doing however it was doing this from the main engine 
> > > thread.  Sean had commented that this should really happen from 
> > > the cache thread, so I am pondered that option.
> > >
> > > We would need to have the cache thread wait for the engine thread 
> > > to finish apply execute, and have it communicate with the cache 
> > > thread via some needed variables on the plan (adding 2 events and 
> > > a bool flag to indicate that apply execute is requesting the cache 
> > > rollback to
> > happen).
> > > HANDLE hEventCacheComplete;
> > > HANDLE hEventApplyExecuteComplete; BOOL fCacheExecuteRollback;
> > >
> > > Core apply would need to be tweaked to wait for the 
> > > hEventCacheComplete if not doing parallel cache.
> > > The ApplyExecute procedure, in LExit, would need to test its HR 
> > > and conditionally assign a value to fCacheExecuteRollback  and set 
> > > hEventApplyExecuteComplete.
> > > The cache thread would need to set hEventCacheComplete, then 
> > > conditionally wait for hEventApplyExecuteComplete as long as the 
> > > cache thread was SUCCEEDED(hr), then evaluate fCacheExecuteRollback.
> > >
> > > -----Original Message-----
> > > From: wix-devs [mailto:wix-devs-bounces at lists.wixtoolset.org] On 
> > > Behalf Of Hoover, Jacob via wix-devs
> > > Sent: Thursday, January 18, 2018 2:28 PM
> > > To: WiX Toolset Developer Mailing List 
> > > <wix-devs at lists.wixtoolset.org>; Rob Mensching 
> > > <rob at firegiant.com>; Bob Arnson <bob at firegiant.com>; Sean Hall 
> > > (r.sean.hall at gmail.com) <r.sean.hall at gmail.com>
> > > Cc: Hoover, Jacob <Jacob.Hoover at greenheck.com>
> > > Subject: Re: [wix-devs] Burn bug: ARP entry
> > >
> > > FYI, the 3.7 build has the same behavior.
> > >
> > > [67C0:4088][2018-01-18T14:26:26]i001: Burn v3.7.1224.0, Windows 
> > > v6.2 (Build 9200: Service Pack 0), path: C:\Temp\wix-tests\ 
> > > BundleCancel\Bootstrapper\bin\Debug\Bootstrapper.exe, cmdline: ''
> > >
> > > [67C0:4088][2018-01-18T14:26:27]i101: Detected package:
> > > FailingPackage.msi, state: Absent, cached: None
> > > [67C0:4088][2018-01-18T14:26:27]i101: Detected package:
> > > SecondPackage.msi, state: Absent, cached: None
> > >
> > > [204C:4028][2018-01-18T14:26:31]i000: Caching bundle from:
> > > 'C:\Users\hoover\AppData\Local\Temp\{2a9a1134-c048-
> > > 493f-828a-c46f06c1198e}\.be\Bootstrapper.exe' to:
> > > 'C:\ProgramData\Package
> > > Cache\{2a9a1134-c048-493f-828a-c46f06c1198e}\
> > Bootstrapper.exe'
> > > [204C:4028][2018-01-18T14:26:31]i320: Registering bundle 
> > > dependency
> > > provider: {2a9a1134-c048-493f-828a-c46f06c1198e}, version: 1.1.0.0
> > > [67C0:139C][2018-01-18T14:26:31]i338: Acquiring package:
> > > FailingPackage.msi, payload: FailingPackage.msi, copy from:
> > > C:\Temp\wix-tests\BundleCancel\Bootstrapper\bin\Debug\payload\fail
> > > in
> > > g\
> > > FailingPackage.msi
> > > [67C0:139C][2018-01-18T14:26:31]i000: Setting string variable 
> > > 'WixBundleLastUsedSource' to value 'C:\Temp\wix-tests\ 
> > > BundleCancel\Bootstrapper\bin\Debug\'
> > > [204C:2354][2018-01-18T14:26:31]i305: Verified acquired payload:
> > > FailingPackage.msi at path: C:\ProgramData\Package 
> > > Cache\.unverified\FailingPackage.msi,
> > > moving to: C:\ProgramData\Package Cache\{0C426D92-8203-44C1- 
> > > AFEC-B3F78B62346E}v1.1.0.0\payload\failing\FailingPackage.msi.
> > > [67C0:139C][2018-01-18T14:26:31]i338: Acquiring package:
> > > FailingPackage.msi, payload: cabAF8DAFFA35132BD6767F6D6CBE9566A2,
> > > copy
> > > from: C:\Temp\wix-tests\BundleCancel\Bootstrapper\bin\
> > > Debug\payload\failing\cab1.cab
> > > [204C:2354][2018-01-18T14:26:31]i305: Verified acquired payload:
> > > cabAF8DAFFA35132BD6767F6D6CBE9566A2 at path: 
> > > C:\ProgramData\Package Cache\.unverified\cabAF8DAFFA35132BD6767F6D6CBE9566A2, moving to:
> > > C:\ProgramData\Package Cache\{0C426D92-8203-44C1- 
> > > AFEC-B3F78B62346E}v1.1.0.0\payload\failing\cab1.cab.
> > > [67C0:139C][2018-01-18T14:26:31]i338: Acquiring package:
> > > SecondPackage.msi, payload: SecondPackage.msi, copy from:
> > > C:\Temp\wix-tests\
> > > BundleCancel\Bootstrapper\bin\Debug\payload\second\SecondPackage.m
> > > si
> > > [204C:2354][2018-01-18T14:26:31]i305: Verified acquired payload:
> > > SecondPackage.msi at path: C:\ProgramData\Package 
> > > Cache\.unverified\SecondPackage.msi,
> > > moving to: C:\ProgramData\Package Cache\{B50B0F85-1530-4119- 
> > > 8989-B9CE020C6EC5}v1.0.0.0\payload\second\SecondPackage.msi.
> > > [67C0:139C][2018-01-18T14:26:31]i338: Acquiring package:
> > > SecondPackage.msi, payload: cab1C906C19D88FC6AB052BB72B38FC7E56,
> > > copy
> > > from: C:\Temp\wix-tests\BundleCancel\Bootstrapper\bin\
> > > Debug\payload\second\cab1.cab
> > > [204C:2354][2018-01-18T14:26:31]i305: Verified acquired payload:
> > > cab1C906C19D88FC6AB052BB72B38FC7E56 at path: 
> > > C:\ProgramData\Package Cache\.unverified\cab1C906C19D88FC6AB052BB72B38FC7E56, moving to:
> > > C:\ProgramData\Package Cache\{B50B0F85-1530-4119- 
> > > 8989-B9CE020C6EC5}v1.0.0.0\payload\second\cab1.cab.
> > > [204C:4028][2018-01-18T14:26:31]i323: Registering package 
> > > dependency
> > > provider: {0C426D92-8203-44C1-AFEC-B3F78B62346E}, version: 
> > > 1.1.0.0,
> > > package: FailingPackage.msi
> > > [204C:4028][2018-01-18T14:26:31]i301: Applying execute package:
> > > FailingPackage.msi, action: Install, path: C:\ProgramData\Package 
> > > Cache\{0C426D92-8203-44C1-AFEC-B3F78B62346E}v1.1.0.0\payload\faili
> > > ng
> > > \F
> > > ailingPackage.msi,
> > > arguments: ' ARPSYSTEMCOMPONENT="1" MSIFASTINSTALL="7"'
> > > [204C:4028][2018-01-18T14:26:32]e000: Error 0x80070643: Failed to 
> > > install MSI package.
> > > [204C:4028][2018-01-18T14:26:32]e000: Error 0x80070643: Failed to 
> > > execute MSI package.
> > > [67C0:4088][2018-01-18T14:26:32]e000: Error 0x80070643: Failed to 
> > > configure per-machine MSI package.
> > > [67C0:4088][2018-01-18T14:26:32]i319: Applied execute package:
> > > FailingPackage.msi, result: 0x80070643, restart: None
> > > [67C0:4088][2018-01-18T14:26:32]e000: Error 0x80070643: Failed to 
> > > execute MSI package.
> > > [204C:4028][2018-01-18T14:26:32]i318: Skipped rollback of package:
> > > FailingPackage.msi, action: Uninstall, already: Absent
> > > [67C0:4088][2018-01-18T14:26:32]i319: Applied rollback package:
> > > FailingPackage.msi, result: 0x0, restart: None
> > > [204C:4028][2018-01-18T14:26:32]i329: Removed package dependency
> > > provider: {0C426D92-8203-44C1-AFEC-B3F78B62346E}, package:
> > > FailingPackage.msi
> > > [204C:4028][2018-01-18T14:26:32]i351: Removing cached package:
> > > FailingPackage.msi, from path: C:\ProgramData\Package 
> > > Cache\{0C426D92-8203-44C1-AFEC-B3F78B62346E}v1.1.0.0\
> > > [204C:4028][2018-01-18T14:26:32]i330: Removed bundle dependency
> > provider:
> > > {2a9a1134-c048-493f-828a-c46f06c1198e}
> > > [204C:4028][2018-01-18T14:26:32]i352: Removing cached bundle:
> > > {2a9a1134-c048-493f-828a-c46f06c1198e}, from path:
> > > C:\ProgramData\Package 
> > > Cache\{2a9a1134-c048-493f-828a-c46f06c1198e}\
> > > [67C0:4088][2018-01-18T14:26:33]i399: Apply complete, result:
> > > 0x80070643,
> > > restart: None, ba requested restart:  No
> > >
> > >
> > > -----Original Message-----
> > > From: wix-devs [mailto:wix-devs-bounces at lists.wixtoolset.org] On 
> > > Behalf Of Hoover, Jacob via wix-devs
> > > Sent: Thursday, January 18, 2018 12:48 PM
> > > To: WiX Toolset Developer Mailing List 
> > > <wix-devs at lists.wixtoolset.org>; Rob Mensching 
> > > <rob at firegiant.com>; Bob Arnson <bob at firegiant.com>; Sean Hall 
> > > (r.sean.hall at gmail.com) <r.sean.hall at gmail.com>
> > > Cc: Hoover, Jacob <Jacob.Hoover at greenheck.com>
> > > Subject: Re: [wix-devs] Burn bug: ARP entry
> > >
> > > And interesting bits of the log for it:
> > >
> > > [6E88:6A4C][2018-01-18T12:46:04]i370: Session begin, registration key:
> > > SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{
> > > 9e02acda-cd0c-4a27-9e0b-3b757acd9dc3}, options: 0x7, disable resume:
> > > No
> > > [6E88:6A4C][2018-01-18T12:46:05]i000: Caching bundle from:
> > > 'C:\Users\hoover\AppData\Local\Temp\{524DB29B-EFB9-
> > > 45F9-A4FF-16526F41A9FA}\.be\Bootstrapper.exe' to:
> > > 'C:\ProgramData\Package
> > > Cache\{9e02acda-cd0c-4a27-9e0b-3b757acd9dc3}\
> > Bootstrapper.exe'
> > > [6E88:6A4C][2018-01-18T12:46:05]i320: Registering bundle 
> > > dependency
> > > provider: {9e02acda-cd0c-4a27-9e0b-3b757acd9dc3}, version: 1.1.0.0
> > > [6E88:6A4C][2018-01-18T12:46:05]i371: Updating session, 
> > > registration
> > key:
> > > SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{
> > > 9e02acda-cd0c-4a27-9e0b-3b757acd9dc3}, resume: Active, restart
> > initiated:
> > > No, disable resume: No
> > > [3C28:39A0][2018-01-18T12:46:05]i338: Acquiring package:
> > > FailingPackage.msi, payload: FailingPackage.msi, copy from:
> > > C:\Temp\wix-tests\BundleCancel\Bootstrapper\bin\Debug\payload\fail
> > > in
> > > g\
> > > FailingPackage.msi
> > > [3C28:39A0][2018-01-18T12:46:05]i000: Setting string variable 
> > > 'WixBundleLastUsedSource' to value 'C:\Temp\wix-tests\ 
> > > BundleCancel\Bootstrapper\bin\Debug\'
> > > [6E88:6F50][2018-01-18T12:46:05]i305: Verified acquired payload:
> > > FailingPackage.msi at path: C:\ProgramData\Package 
> > > Cache\.unverified\FailingPackage.msi,
> > > moving to: C:\ProgramData\Package Cache\{0C426D92-8203-44C1- 
> > > AFEC-B3F78B62346E}v1.1.0.0\payload\failing\FailingPackage.msi.
> > > [3C28:39A0][2018-01-18T12:46:05]i338: Acquiring package:
> > > FailingPackage.msi, payload: cabAF8DAFFA35132BD6767F6D6CBE9566A2,
> > > copy
> > > from: C:\Temp\wix-tests\BundleCancel\Bootstrapper\bin\
> > > Debug\payload\failing\cab1.cab
> > > [6E88:6F50][2018-01-18T12:46:05]i305: Verified acquired payload:
> > > cabAF8DAFFA35132BD6767F6D6CBE9566A2 at path: 
> > > C:\ProgramData\Package Cache\.unverified\cabAF8DAFFA35132BD6767F6D6CBE9566A2, moving to:
> > > C:\ProgramData\Package Cache\{0C426D92-8203-44C1- 
> > > AFEC-B3F78B62346E}v1.1.0.0\payload\failing\cab1.cab.
> > > [3C28:39A0][2018-01-18T12:46:05]i338: Acquiring package:
> > > SecondPackage.msi, payload: SecondPackage.msi, copy from:
> > > C:\Temp\wix-tests\
> > > BundleCancel\Bootstrapper\bin\Debug\payload\second\SecondPackage.m
> > > si
> > > [6E88:6F50][2018-01-18T12:46:05]i305: Verified acquired payload:
> > > SecondPackage.msi at path: C:\ProgramData\Package 
> > > Cache\.unverified\SecondPackage.msi,
> > > moving to: C:\ProgramData\Package Cache\{B50B0F85-1530-4119- 
> > > 8989-B9CE020C6EC5}v1.0.0.0\payload\second\SecondPackage.msi.
> > > [3C28:39A0][2018-01-18T12:46:05]i338: Acquiring package:
> > > SecondPackage.msi, payload: cab1C906C19D88FC6AB052BB72B38FC7E56,
> > > copy
> > > from: C:\Temp\wix-tests\BundleCancel\Bootstrapper\bin\
> > > Debug\payload\second\cab1.cab
> > > [6E88:6F50][2018-01-18T12:46:05]i305: Verified acquired payload:
> > > cab1C906C19D88FC6AB052BB72B38FC7E56 at path: 
> > > C:\ProgramData\Package Cache\.unverified\cab1C906C19D88FC6AB052BB72B38FC7E56, moving to:
> > > C:\ProgramData\Package Cache\{B50B0F85-1530-4119- 
> > > 8989-B9CE020C6EC5}v1.0.0.0\payload\second\cab1.cab.
> > > [6E88:6A4C][2018-01-18T12:46:05]i323: Registering package 
> > > dependency
> > > provider: {0C426D92-8203-44C1-AFEC-B3F78B62346E}, version: 
> > > 1.1.0.0,
> > > package: FailingPackage.msi
> > > [6E88:6A4C][2018-01-18T12:46:05]i301: Applying execute package:
> > > FailingPackage.msi, action: Install, path: C:\ProgramData\Package 
> > > Cache\{0C426D92-8203-44C1-AFEC-B3F78B62346E}v1.1.0.0\payload\faili
> > > ng
> > > \F
> > > ailingPackage.msi,
> > > arguments: ' ARPSYSTEMCOMPONENT="1" MSIFASTINSTALL="7"'
> > > [6E88:6A4C][2018-01-18T12:46:06]e000: Error 0x80070643: Failed to 
> > > install MSI package.
> > > [6E88:6A4C][2018-01-18T12:46:06]e000: Error 0x80070643: Failed to 
> > > execute MSI package.
> > > [3C28:265C][2018-01-18T12:46:06]e000: Error 0x80070643: Failed to 
> > > configure per-machine MSI package.
> > > [3C28:265C][2018-01-18T12:46:06]i319: Applied execute package:
> > > FailingPackage.msi, result: 0x80070643, restart: None
> > > [3C28:265C][2018-01-18T12:46:06]e000: Error 0x80070643: Failed to 
> > > execute MSI package.
> > > [6E88:6A4C][2018-01-18T12:46:06]i318: Skipped rollback of package:
> > > FailingPackage.msi, action: Uninstall, already: Absent
> > > [3C28:265C][2018-01-18T12:46:06]i319: Applied rollback package:
> > > FailingPackage.msi, result: 0x0, restart: None
> > > [6E88:6A4C][2018-01-18T12:46:06]i329: Removed package dependency
> > > provider: {0C426D92-8203-44C1-AFEC-B3F78B62346E}, package:
> > > FailingPackage.msi
> > > [6E88:6A4C][2018-01-18T12:46:06]i351: Removing cached package:
> > > FailingPackage.msi, from path: C:\ProgramData\Package 
> > > Cache\{0C426D92-8203-44C1-AFEC-B3F78B62346E}v1.1.0.0\
> > > [6E88:6A4C][2018-01-18T12:46:06]i372: Session end, registration key:
> > > SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{
> > > 9e02acda-cd0c-4a27-9e0b-3b757acd9dc3}, resume: None, restart: 
> > > None, disable resume: No
> > > [6E88:6A4C][2018-01-18T12:46:06]i330: Removed bundle dependency
> > provider:
> > > {9e02acda-cd0c-4a27-9e0b-3b757acd9dc3}
> > > [6E88:6A4C][2018-01-18T12:46:06]i352: Removing cached bundle:
> > > {9e02acda-cd0c-4a27-9e0b-3b757acd9dc3}, from path:
> > > C:\ProgramData\Package 
> > > Cache\{9e02acda-cd0c-4a27-9e0b-3b757acd9dc3}\
> > > [6E88:6A4C][2018-01-18T12:46:06]i371: Updating session, 
> > > registration
> > key:
> > > SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{
> > > 9e02acda-cd0c-4a27-9e0b-3b757acd9dc3}, resume: None, restart
> initiated:
> > > No, disable resume: No
> > > [3C28:265C][2018-01-18T12:46:06]i399: Apply complete, result:
> > > 0x80070643,
> > > restart: None, ba requested restart:  No
> > >
> > > -----Original Message-----
> > > From: wix-devs [mailto:wix-devs-bounces at lists.wixtoolset.org] On 
> > > Behalf Of Hoover, Jacob via wix-devs
> > > Sent: Thursday, January 18, 2018 12:43 PM
> > > To: Rob Mensching <rob at firegiant.com>; Bob Arnson 
> > > <bob at firegiant.com>; Sean Hall (r.sean.hall at gmail.com) 
> > > <r.sean.hall at gmail.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
> > >
> > > Bringing this back into Wix-Dev's.
> > >
> > > Test case is here: https://github.com/jchoover/wix-tests
> > >
> > > Confirmed with v3.11.1.2318
> > >
> > > I noticed one thing, it's the other packages that aren't being cleaned.
> > > IE, one has to have 2+ packages in the bundle to see the issue.
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: Rob Mensching [mailto:rob at firegiant.com]
> > > Sent: Thursday, January 18, 2018 11:12 AM
> > > To: Hoover, Jacob <Jacob.Hoover at greenheck.com>; Bob Arnson < 
> > > bob at firegiant.com>; Sean Hall (r.sean.hall at gmail.com) < 
> > > r.sean.hall at gmail.com>
> > > Subject: RE: Burn bug: ARP entry
> > >
> > > Adding to the agenda right now. 😊
> > >
> > > Regards,
> > >
> > >   Rob Mensching
> > >   CEO
> > >   FireGiant
> > > _______________________________________________________________
> > >  FireGiant  |  Dedicated support for the WiX toolset  | 
> > > http://www.firegiant.com/
> > >
> > > -----Original Message-----
> > > From: Hoover, Jacob [mailto:Jacob.Hoover at greenheck.com]
> > > Sent: Thursday, January 18, 2018 9:12 AM
> > > To: Rob Mensching <rob at firegiant.com>; Bob Arnson 
> > > <bob at firegiant.com>; Sean Hall (r.sean.hall at gmail.com) 
> > > <r.sean.hall at gmail.com>
> > > Subject: RE: Burn bug: ARP entry
> > >
> > > Think we can carve out a bit of time to discuss this in todays meeting?
> > >
> > > -----Original Message-----
> > > From: Rob Mensching [mailto:rob at firegiant.com]
> > > Sent: Thursday, January 18, 2018 11:10 AM
> > > To: Hoover, Jacob <Jacob.Hoover at greenheck.com>; Bob Arnson < 
> > > bob at firegiant.com>; Sean Hall (r.sean.hall at gmail.com) < 
> > > r.sean.hall at gmail.com>
> > > Subject: RE: Burn bug: ARP entry
> > >
> > > This really should be on wix-devs
> > >
> > > Regards,
> > >
> > >   Rob Mensching
> > >   CEO
> > >   FireGiant
> > > _______________________________________________________________
> > >  FireGiant  |  Dedicated support for the WiX toolset  | 
> > > http://www.firegiant.com/
> > >
> > > -----Original Message-----
> > > From: Hoover, Jacob [mailto:Jacob.Hoover at greenheck.com]
> > > Sent: Thursday, January 18, 2018 8:22 AM
> > > To: Bob Arnson <bob at firegiant.com>; Rob Mensching 
> > > <rob at firegiant.com>; Sean Hall (r.sean.hall at gmail.com) 
> > > <r.sean.hall at gmail.com>
> > > Subject: RE: Burn bug: ARP entry
> > >
> > > So then we would consider this a rather large oversight? I am 
> > > assuming that the only valid means of doing the cleanup would be 
> > > to utilize the plans rollback cache actions to clean up the cache. 
> > > As such, that is only referenced in Apply.cpp inside of 
> > > DoRollbackCache. (There are references in plan, which is the 
> > > process of setting up the plan.)
> > >
> > > DoRollbackCache is currently only called at the end of ApplyCache, 
> > > if there was an error during the caching of the packages.
> > >
> > >
> > > My current thought is we need to add:
> > > Plan.cpp, inside PlanPackages, right after the loop of all the 
> > > packages and right before planning keep/remove registrations.
> > >
> > >     // Insert a trailing checkpoint to the end of the rollback 
> > > cache
> > plan.
> > >     if (!fBundleInstalled && (BOOTSTRAPPER_ACTION_INSTALL ==
> > > pPlan->action))
> > >     {
> > >         BURN_CACHE_ACTION* pCacheAction = NULL;
> > >         DWORD dwCheckpoint = GetNextCheckpointId();
> > >         hr = AppendRollbackCacheAction(pPlan, &pCacheAction);
> > >         ExitOnFailure(hr, "Failed to append rollback cache 
> > > action.");
> > >
> > >         pCacheAction->type = BURN_CACHE_ACTION_TYPE_CHECKPOINT;
> > >         pCacheAction->checkpoint.dwId = dwCheckpoint;
> > >     }
> > >
> > > Then in Apply.cpp, at the end of ApplyExecute:
> > >     if (FAILED(hr) && !pEngineState->registration.fInstalled && 
> > > (BOOTSTRAPPER_ACTION_INSTALL == pEngineState->plan.action))
> > >     {
> > >         // Scan to find the last checkpoint.
> > >         dwCheckpoint = 0;
> > >         for (DWORD i = pEngineState->plan.cRollbackCacheActions 
> > > -1; i
> > > > 0; --i)
> > >         {
> > >             BURN_CACHE_ACTION* pRollbackCacheAction =
> > &pEngineState->plan.
> > > rgRollbackCacheActions[i];
> > >
> > >             if (BURN_CACHE_ACTION_TYPE_CHECKPOINT ==
> > > pRollbackCacheAction->type)
> > >             {
> > >                 dwCheckpoint = i;
> > >                 break;
> > >             }
> > >         }
> > >
> > >         DoRollbackCache(&pEngineState->userExperience,
> > > &pEngineState->plan, pEngineState->companionConnection.hPipe,
> > > dwCheckpoint);
> > >     }
> > >
> > >
> > > Note, with Bob's comment I think I need to verify that if the 
> > > install has a rollback boundary and thus burn plans on keeping the 
> > > ARP entry, that we don't rollback the cache.
> > >
> > > -----Original Message-----
> > > From: Bob Arnson [mailto:bob at firegiant.com]
> > > Sent: Thursday, January 18, 2018 8:10 AM
> > > To: Hoover, Jacob <Jacob.Hoover at greenheck.com>; Rob Mensching < 
> > > rob at firegiant.com>; Sean Hall (r.sean.hall at gmail.com) < 
> > > r.sean.hall at gmail.com>
> > > Subject: RE: Burn bug: ARP entry
> > >
> > > Cache and ARP entry should end up in the same state so nothing's
> > orphaned.
> > >
> > > -----Original Message-----
> > > From: Hoover, Jacob [mailto:Jacob.Hoover at greenheck.com]
> > > Sent: Wednesday, 17 January, 2018 14:04
> > > To: Rob Mensching <rob at firegiant.com>; Bob Arnson 
> > > <bob at firegiant.com>; Sean Hall (r.sean.hall at gmail.com) 
> > > <r.sean.hall at gmail.com>
> > > Subject: RE: Burn bug: ARP entry
> > >
> > > Should I continue to go down the path of trying to roll back the 
> > > cache, or am I off base and burn is actually designed to leave 
> > > behind cached packages if a user hits cancel? This is a bit of an 
> > > edge case, because once we are in the apply execute stage it would 
> > > actually take more time to cancel than it would to just allow the 
> > > install to complete.  (I would be fine with disabling cancel 
> > > inside of WixStdBA once we hit apply execute...)
> > >
> > > -----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 4:42 PM
> > > To: Rob Mensching <rob at firegiant.com>; 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 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
> > >
> > > __________________________________________________________________
> > > __ WiX Toolset Developer Mailing List provided by FireGiant 
> > > http://www.firegiant.com/ ______________________________ 
> > > ______________________________________
> > > WiX Toolset Developer Mailing List provided by FireGiant 
> > > http://www.firegiant.com/ ______________________________ 
> > > ______________________________________
> > > WiX Toolset Developer Mailing List provided by FireGiant 
> > > http://www.firegiant.com/ ______________________________ 
> > > ______________________________________
> > > WiX Toolset Developer Mailing List provided by FireGiant 
> > > http://www.firegiant.com/
> > >
> > ____________________________________________________________________
> > WiX Toolset Developer Mailing List provided by FireGiant 
> > http://www.firegiant.com/
> >
> ____________________________________________________________________
> WiX Toolset Developer Mailing List provided by FireGiant 
> http://www.firegiant.com/
>
____________________________________________________________________
WiX Toolset Developer Mailing List provided by FireGiant http://www.firegiant.com/


More information about the wix-devs mailing list