[wix-devs] Burn bug: ARP entry
Sean Hall
r.sean.hall at gmail.com
Fri Jan 19 09:01:15 PST 2018
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\failin
> > > 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.msi
> > > [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\failing
> > > \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\failin
> > > 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.msi
> > > [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\failing
> > > \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/
>
More information about the wix-devs
mailing list