[wix-devs] Burn bug: ARP entry
Hoover, Jacob
Jacob.Hoover at greenheck.com
Thu Jan 18 12:28:10 PST 2018
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\FailingPackage.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\FailingPackage.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/
More information about the wix-devs
mailing list