I've built a WiX bundle with a custom Managed Bootstrapper Application to play around with it and didn't realize that I had to implement logic for uninstall.
Now I have a version of the bundle installed which cannot be uninstalled.
Is there a clean way to remove this bundle? I've tried to locate the cached bundle .exe in the C:\ProgramData\Package Cache folder and replace it with a fixed version but unfortunately that still doesn't actually uninstall and it doesn't remove the entry from the installed programs view in Control Panel.
When I examine the MSI log file for the updated bundle, during unistallation, I see some lines that ream something like this:
[1014:1B44][2016-08-08T01:13:02]i300: Apply begin
[1014:1B44][2016-08-08T01:13:02]i010: Launching elevated engine process.
[1014:1B44][2016-08-08T01:13:06]i011: Launched elevated engine process.
[1014:1B44][2016-08-08T01:13:06]i012: Connected to elevated engine.
[10F8:1AD4][2016-08-08T01:13:06]i358: Pausing automatic updates.
[10F8:1AD4][2016-08-08T01:13:12]w308: Automatic updates could not be paused due to error: 0x80070422. Continuing...
[10F8:1AD4][2016-08-08T01:13:12]i360: Creating a system restore point.
[10F8:1AD4][2016-08-08T01:13:16]i361: Created a system restore point.
[10F8:1AD4][2016-08-08T01:13:16]i370: Session begin, registration key: SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{598ba570-f8c8-43c5-8aa9-b7d26f3e6124}, options: 0x0, disable resume: No
[10F8:1AD4][2016-08-08T01:13:16]i371: Updating session, registration key: SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{598ba570-f8c8-43c5-8aa9-b7d26f3e6124}, resume: Active, restart initiated: No, disable resume: No
[10F8:1AD4][2016-08-08T01:13:16]i329: Removed package dependency provider: {27C17010-A6C4-4087-8EB7-8DCB45DC7D7E}, package: MyPackage1
[10F8:1AD4][2016-08-08T01:13:16]i326: Removed dependency: {598ba570-f8c8-43c5-8aa9-b7d26f3e6124} on package provider: {C12FA53F-22FA-4979-8C63-0B6850F59A16}, package MyPackage2
[10F8:1AD4][2016-08-08T01:13:16]i372: Session end, registration key: SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{598ba570-f8c8-43c5-8aa9-b7d26f3e6124}, resume: None, restart: None, disable resume: No
[10F8:1AD4][2016-08-08T01:13:16]i352: Removing cached bundle: {598ba570-f8c8-43c5-8aa9-b7d26f3e6124}, from path: C:\ProgramData\Package Cache\{598ba570-f8c8-43c5-8aa9-b7d26f3e6124}\
[10F8:1AD4][2016-08-08T01:13:16]w354: Unable to remove cached bundle: {598ba570-f8c8-43c5-8aa9-b7d26f3e6124}, from path: C:\ProgramData\Package Cache\{598ba570-f8c8-43c5-8aa9-b7d26f3e6124}\, reason: 0x80070003. Continuing...
[10F8:1AD4][2016-08-08T01:13:16]i371: Updating session, registration key: SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{598ba570-f8c8-43c5-8aa9-b7d26f3e6124}, resume: None, restart initiated: No, disable resume: No
[1014:1B44][2016-08-08T01:13:16]i399: Apply complete, result: 0x0, restart: None, ba requested restart: No
Revo Uninstaller Pro was able to uninstall all of my bugged bundles yet (it has 30-day trial).
Related
Users of our managed bootstrapper installer should be able to downgrade the bundle in case a new version causes problems:
<MajorUpgrade Schedule="afterInstallValidate" AllowDowngrades="yes" AllowSameVersionUpgrades="no" />
When upgrading, the existing bundle is properly uninstalled. Only the new version remains in the list of installed programs in Programs and Features. The log confirms the chosen action:
OnDetectRelatedBundle(): Operation MajorUpgrade
OnDetectRelatedBundle(): RelationType Upgrade
Planned package: APP_MSI_PACKAGE, state: Absent, default requested: Present, ba requested: Present, execute: Install, …
Planned related bundle: { }, type: Upgrade, … execute: Uninstall, rollback: Install, dependency: None
When downgrading, the existing bundle remains in Programs and Features. According to the log, the type downgrade is recognized, but no Uninstall is planned:
OnDetectRelatedBundle(): Operation Downgrade
OnDetectRelatedBundle(): RelationType Upgrade
Planned package: APP_MSI_PACKAGE, state: Obsolete, default requested: None, ba requested: None, execute: None, …
Planned related bundle: {}, type: Upgrade … execute: None, rollback: None, dependency: None
There shouldn't be two entries for the same application in Programs and Features. After the downgrade I can uninstall the obsolete version manually, but the user should not have to do that.
I find it confusing that MajorUpgrade is part of <Product>, but then in Programs and Features the version is tracked for the entire bundle. I read somewhere that the same UpgradeCode should be used in Product and Bundle. Is that recommended? I tried the same UpgradeCode and separate UpgradeCodes. There seems to be no difference.
I’ve researched a bit and supposedly the uninstallation is not supported when downgrading. Is that true?
If it is not supported, how can I trigger the uninstallation of the related bundle manually from the managed bootstrapper code?
Truly, the problem boils down to the double entry in Programs and Features. If I cannot uninstall it, can I remove (or maybe hide, which I would consider a terrible hack) the obsolete version of the bundle via code some other way?
I had to determine if the setup installs a downgrade by using the event DetectRelatedBundle. Then in the event handler for PlanRelatedBundle I had to specify that the related bundle should be absent:
private void OnPlanRelatedBundle(object sender, PlanRelatedBundleEventArgs e)
{
if (BundleUpgrade || BundleDowngrade)
e.State = RequestState.Absent;
}
For good measure I set the absent state when an upgrade was detected as well even though that case already worked. Now the related bundle is removed in both cases.
I create my instalator Wix with msi and bootstrapper.
I am do test for update my program. And trying install new version. I want always use bootstrapper. I don't know if this was always the case, but I did some tweaks and added a progress bar to the bootstrapper for MSI installations. And it turns out that when updating, this bar stops at 60/70% and after closing MSI a new bootstrapper window appears. Closing the window a few times causes the progress bar in the first window jump to 100% and I can close the window.
I dont have idea why it happen.
I check logs and in both cases last line looks like:
Applying execute package: Installer, action: Install, path: C:\ProgramData\Package Cache{9428A5CF-824D-42D0-ABF7-BC69D4B8FEE7}v1.0.26.40\EkInstaller.Elements.msi, arguments: ' MSIFASTINSTALL="7" CONFIGFILELOCATION="C:\svn\122\dotNet\products\3_ek-graf-pre-v2\trunk\src\Ek.Installer\Ek.Installer.Bootstrapper\bin\Debug"'
And besides this lines I dont show differents in logs:
[4EDC:2970][2020-07-23T08:54:34]i102: Detected related bundle:
{2e954545-621e-4062-a306-99197563c483}, type: Upgrade, scope:
PerMachine, version: 1.0.24.39, operation: MajorUpgrade
[4EDC:2970][2020-07-23T08:54:34]i102: Detected related bundle:
{770a1869-f4b5-4307-b05f-1f8be006757b}, type: Upgrade, scope:
PerMachine, version: 1.0.23.39, operation: MajorUpgrade
[4EDC:2970][2020-07-23T08:54:34]i102: Detected related bundle:
{ff8d8a34-989d-4fb9-9aa7-2ab0440f514d}, type: Upgrade, scope:
PerMachine, version: 1.0.25.39, operation: MajorUpgrade
[4EDC:2970][2020-07-23T08:54:34]i103: Detected related package:
{D512899C-F7CC-412C-9110-54CDE5BB2741}, scope: PerMachine, version:
1.0.25.40, language: 0 operation: MajorUpgrade
Probably first three are for NetFramework, Sql and SSMS which install bootstrapper and last is for my MSI.
I was trying change InstallerVersion in Package and Schedule in MajorUpgrade.
The installer is very complex, I can't make all the code available. Maybe someone knows the reasons for this behavior and can direct me to why it is.
Noticed when MSI progress bar status = "Delete Files" in then progress bar bootstrapper stop.
Edit:
It spawn additional window bootstrapper for event previous version bootstrapper.
If i dont change version bootstrapper it dont spawn dialog and it goes to 100% normally when updating msi.
Seems to be a wix bug. For each subsequent bootstrapper version installed, new bootstrapper windows appear when the MSI window is closed. You can fix it by following through change UpgradeCode for each new version Bundle. If you additionally set DisableModify = "yes" DisableRemove = "yes" then there will be no additional bootstrapper instances in add / remove program.
I've recently included a bootstrapper into my solution, and I've noticed that after testing a variety of free Anti-Virus programs, both Avast and AVG seem to now cause my installation to fail, has anyone else experienced this?
My current thought is that the cause of the install failing is the CyberCapture feature in both of these products, which causes a delay in the install due to
the Anti-Virus performing a 'quick'(15 or so seconds) scan of the files in the .exe multiple times - when first starting up, and then when clicking install. Could this possibly be something to do with the v3.10.2 security release to resolve the potential DLL hijacking issue?
My installer is signed properly (using insignia and signtool), but a few of the .exes and .dlls that are in the project aren't, could this also be causing it? It seems to be related to a routine scan rather than a potential threat being blocked.
Any insight into why this is happening and/or how this can be resolved would be much appreciated! I'm using WiX v3.11, and the burn chain is comprised of an exe package and an msi package. Thanks.
Attached is the install log for any additional info.
[1DF0:1DFC][2017-06-06T11:03:22]i001: Burn v3.11.0.1528, Windows v10.0 (Build 10240: Service Pack 0), path: C:\Users\NC01\AppData\Local\Temp\{53A054CB-02F6-47A4-85AF-50ABF1DDFDAF}\.cr\proj.exe
[1DF0:1DFC][2017-06-06T11:03:22]i000: Initializing numeric variable 'ACCEPTEULA' to value '0'
[1DF0:1DFC][2017-06-06T11:03:22]i009: Command Line: '-burn.clean.room=C:\Users\NC01\Desktop\proj.exe -burn.filehandle.attached=392 -burn.filehandle.self=404 -log C:\Users\NC01\Desktop\installLog.log'
[1DF0:1DFC][2017-06-06T11:03:22]i000: Setting string variable 'WixBundleOriginalSource' to value 'C:\Users\NC01\Desktop\proj.exe'
[1DF0:1DFC][2017-06-06T11:03:22]i000: Setting string variable 'WixBundleOriginalSourceFolder' to value 'C:\Users\NC01\Desktop\'
[1DF0:1DFC][2017-06-06T11:03:22]i000: Setting string variable 'WixBundleLog' to value 'C:\Users\NC01\Desktop\installLog.log'
[1DF0:1884][2017-06-06T11:03:22]e000: Error 0x80070057: Failed to load splash screen bitmap.
[1DF0:1884][2017-06-06T11:03:22]e000: Error 0x80070057: Failed to load splash screen.
[1DF0:1DFC][2017-06-06T11:03:22]i000: Setting string variable 'WixBundleName' to value 'ProjectName'
[1DF0:1DFC][2017-06-06T11:03:22]i000: Setting string variable 'WixBundleManufacturer' to value 'CompanyName'
[1DF0:0764][2017-06-06T11:03:22]i000: Setting numeric variable 'WixStdBALanguageId' to value 1033
[1DF0:0764][2017-06-06T11:03:22]i000: Setting version variable 'WixBundleFileVersion' to value '4.0.0.632'
[1DF0:1DFC][2017-06-06T11:03:22]i100: Detect begin, 2 packages
[1DF0:1DFC][2017-06-06T11:03:22]i101: Detected package: CleanupToolExe, state: Absent, cached: None
[1DF0:1DFC][2017-06-06T11:03:22]i101: Detected package: projMsi, state: Absent, cached: None
[1DF0:1DFC][2017-06-06T11:03:22]i199: Detect complete, result: 0x0
[1DF0:0764][2017-06-06T11:03:24]i000: Setting numeric variable 'EulaAcceptCheckbox' to value 0
[1DF0:1DFC][2017-06-06T11:03:24]i200: Plan begin, 2 packages, action: Install
[1DF0:1DFC][2017-06-06T11:03:24]w321: Skipping dependency registration on package with no dependency providers: CleanupToolExe
[1DF0:1DFC][2017-06-06T11:03:24]i000: Setting string variable 'WixBundleLog_CleanupToolExe' to value 'C:\Users\NC01\Desktop\installLog_000_CleanupToolExe.log'
[1DF0:1DFC][2017-06-06T11:03:24]i000: Setting string variable 'WixBundleRollbackLog_CleanupToolExe' to value 'C:\Users\NC01\Desktop\installLog_000_CleanupToolExe_rollback.log'
[1DF0:1DFC][2017-06-06T11:03:24]i000: Setting string variable 'WixBundleRollbackLog_projMsi' to value 'C:\Users\NC01\Desktop\installLog_001_projMsi_rollback.log'
[1DF0:1DFC][2017-06-06T11:03:24]i000: Setting string variable 'WixBundleLog_projMsi' to value 'C:\Users\NC01\Desktop\installLog_001_projMsi.log'
[1DF0:1DFC][2017-06-06T11:03:24]i201: Planned package: CleanupToolExe, state: Absent, default requested: Present, ba requested: Present, execute: Install, rollback: Uninstall, cache: Yes, uncache: No, dependency: None
[1DF0:1DFC][2017-06-06T11:03:24]i201: Planned package: projMsi, state: Absent, default requested: Present, ba requested: Present, execute: Install, rollback: Uninstall, cache: Yes, uncache: No, dependency: Register
[1DF0:1DFC][2017-06-06T11:03:24]i299: Plan complete, result: 0x0
[1DF0:1DFC][2017-06-06T11:03:24]i300: Apply begin
[1DF0:1DFC][2017-06-06T11:03:24]i010: Launching elevated engine process.
[1DF0:1DFC][2017-06-06T11:03:53]i011: Launched elevated engine process.
[1DF0:1DFC][2017-06-06T11:03:53]e000: Error 0x800700e8: Failed to wait for child to connect to pipe.
[1DF0:1DFC][2017-06-06T11:03:53]e000: Error 0x800700e8: Failed to connect to elevated child process.
[1DF0:1DFC][2017-06-06T11:03:53]e000: Error 0x800700e8: Failed to actually elevate.
[1DF0:1DFC][2017-06-06T11:03:53]e000: Error 0x800700e8: Failed to elevate.
[1DF0:1DFC][2017-06-06T11:03:53]i399: Apply complete, result: 0x800700e8, restart: None, ba requested restart: No
[1DF0:1DFC][2017-06-06T11:27:14]i500: Shutting down, exit code: 0xe8
Update: Unfortunately the only solution here seems to be submitting a fully signed (including insignia) build to be added to the Avast! and AVG whitelist, and then waiting until it has been added in an update.
I have the same issue here, Avast CyberSecurity and Deepscan both block our burn executable. I signed the exe, the engine, used insignia with an official code signing cert. The MSI is signed and the application executable is signed.
Without burn the MSI runs fine tho. It is the most simple burn template, perhaps a custom BA will work different. Else I just might write an own executable around the MSI :)
We recently switched over to a custom bootstrapper for our installer. This allows the user to select from a list of possible modules to install (each as separate msi's). We are now making our first upgrade and have run into an issue. Burn properly upgrades the msi's but it's not properly dealing with the bootstrapper which is listed in the ARP. It attempts to uninstall the bootstrapper last but then fails because a higher version of the bootstrapper has already been installed.
According to this article https://support.firegiant.com/entries/24024208-Bundle-chain-execution-order- the execution order for an upgrade should have the related bundle uninstalled first:
"When planning an uninstall, the Burn engine plans all related bundles first. Thus related bundles are always removed before the chained packages are removed.
However, that's not the behavior we're seeing. The related bundle is uninstalled last:
[11C4:0868][2015-02-26T10:09:26]i102: Detected related bundle: {9e3abad2-c78b-48ec-a523-c5c4de4fe3f1}, type: Upgrade, scope: PerMachine, version: 7.5.0.0, operation: MajorUpgrade
...
[11C4:0868][2015-02-26T10:09:38]i207: Planned related bundle: {9e3abad2-c78b-48ec-a523-c5c4de4fe3f1}, type: Upgrade, default requested: Absent, ba requested: Absent, execute: Uninstall, rollback: Install, dependency: None
[11C4:0868][2015-02-26T10:09:38]i299: Plan complete, result: 0x0
...
[1224:0E20][2015-02-26T10:23:26]i301: Applying execute package: {9e3abad2-c78b-48ec-a523-c5c4de4fe3f1}, action: Uninstall, path: C:\ProgramData\Package Cache\{9e3abad2-c78b-48ec-a523-c5c4de4fe3f1}\FlexSimInstaller.exe, arguments: '"C:\ProgramData\Package Cache\{9e3abad2-c78b-48ec-a523-c5c4de4fe3f1}\FlexSimInstaller.exe" -uninstall -quiet -burn.related.upgrade -burn.ancestors={36ff969e-da98-4c27-9dde-20e090c0812f}'
[11C4:0868][2015-02-26T10:23:35]i319: Applied execute package: {9e3abad2-c78b-48ec-a523-c5c4de4fe3f1}, result: 0x0, restart: None
[11C4:0868][2015-02-26T10:23:35]i399: Apply complete, result: 0x0, restart: None, ba requested restart: No
[11C4:0868][2015-02-26T10:23:38]i500: Shutting down, exit code: 0x0
We know there is no way to change the order, so how do we get the upgrade to work?
When you're installing an upgraded bundle, you're installing it, not uninstalling it. So the order is as the FireGiant article specifies for an install: The upgraded bundle is installed (usually upgrading the packages it contains) and the related bundle (the old bundle) is uninstalled. When the old bundle is uninstalled, it knows that its packages have been upgraded so it leaves them alone and just removes its own registration.
If your BA tries to prevent downgrades, it needs to also consider the action. For example, WixStdBA lets the uninstall happen like this:
if (m_fDowngrading && BOOTSTRAPPER_ACTION_UNINSTALL < action)
When running a Wix bootstrapper, it writes a log file containing lines such as this one:
[16B8:2324][2014-12-08T11:44:21]i201: Planned package: PackageNameABC, state: Present, default requested: Absent, ba requested: Absent, execute: Uninstall, rollback: None, cache: No, uncache: No, dependency: Unregister
I think I know what these two values mean:
state: Whether or not the package is installed on the system
execute: The action that will be taken concerning this package
But can you explain what these ones mean?
default requested
ba requested
rollback
cache
uncache
dependency
default requested
The state that the Burn engine thinks the package should go to, based on things like the overall action being performed and the package's InstallCondition.
ba requested
The state returned by the BootstrapperApplication from OnPlanPackageBegin.
rollback
The action that will be taken concerning this package if an error occurred after applying this package.
cache
Whether or not to acquire the package and keep it in the package cache.
uncache
Whether or not to remove the package from the package cache.
dependency
This relates to Burn's system of reference counting packages so that if multiple Bundles install the same package, it's not removed until the last Bundle is uninstalled.