[wix-devs] Burn bug: ARP entry
Rob Mensching
rob at firegiant.com
Thu Jan 18 15:43:06 PST 2018
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 PlanExecuteCacheSyncAndRollback.
>
> 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\failing\
> 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\failing\
> 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/
More information about the wix-devs
mailing list