The plot thickens. Below is the log from the v1.0.1 bundle when trying to
upgrade from v1.0.0, but here are two highlights that don't make sense, and may
or may not be related to the problem. First:
[0ACC:11A0][2013-06-29T15:23:29]i102: Detected related bundle: {GUID5}, type:
Upgrade, scope: PerMachine, version: 1.0.0.0, operation: MajorUpgrade
...
[0ACC:11A0][2013-06-29T15:23:29]i103: Detected related package: {GUID3}, scope:
PerUser, version: 1.0.0.0, language: 0 operation: MajorUpgrade
This is the 1.0.1 bundle detecting the presence of the 1.0.0 bundle and 1.0.0
package, so good. What is awry is the 1.0.0 package's scope is "PerUser". This
is wrong. In the Package element, I have set InstallScope='perMachine' and I
even tried adding InstallPrivileges='elevated' to the Package and
ForcePerMachine="yes" to the MsiPackage element in the Bundle's Chain, but
somehow it still seems to think the package was installed per user, when it
definitely should not be. I don't know if this is a known bug, or doesn't
matter, but if it's neither of those, then any advice on how to make it
PerMachine would be much appreciated.
The second thing that pops out at me is this:
[0AC8:12E8][2013-06-29T15:23:29]i323: Registering package dependency provider:
{GUID6}, version: 1.0.1, package: pkgMyClient
[0AC8:12E8][2013-06-29T15:23:29]i301: Applying execute package: pkgMyClient,
action: Install, path: C:\ProgramData\Package
Cache\{GUID6}v1.0.1\MyClientPackage_v1.0.1.msi, arguments: ' ALLUSERS="1"
ARPSYSTEMCOMPONENT="1"'
[0ACC:11A0][2013-06-29T15:23:38]i319: Applied execute package: pkgMyClient,
result: 0x0, restart: Required
[0AC8:12E8][2013-06-29T15:23:38]i325: Registering dependency: {GUID4} on
package provider: {GUID6}, package: pkgMyClient
[0AC8:12E8][2013-06-29T15:23:38]i301: Applying execute package: {GUID5},
action: Uninstall, path: C:\ProgramData\Package
Cache\{GUID5}\MyBundleInstaller_v1.0.0.exe, arguments: '"C:\ProgramData\Package
Cache\{GUID5}\MyBundleInstaller_v1.0.0.exe" -uninstall -quiet
-burn.related.upgrade'
[0ACC:11A0][2013-06-29T15:23:39]i319: Applied execute package: {GUID5}, result:
0x0, restart: None
[0AC8:12E8][2013-06-29T15:23:38]i325: Registering dependency: {GUID4} on
package provider: {GUID6}, package: pkgMyClient
[0AC8:12E8][2013-06-29T15:23:38]i301: Applying execute package: {GUID5},
action: Uninstall, path: C:\ProgramData\Package
Cache\{GUID5}\MyBundleInstaller_v1.0.0.exe, arguments: '"C:\ProgramData\Package
Cache\{GUID5}\MyBundleInstaller_v1.0.0.exe" -uninstall -quiet
-burn.related.upgrade'
[0ACC:11A0][2013-06-29T15:23:39]i319: Applied execute package: {GUID5}, result:
0x0, restart: None
[0AC8:12E8][2013-06-29T15:23:39]i351: Removing cached package: pkgMyClient,
from path: C:\ProgramData\Package Cache\{GUID6}v1.0.1\
[0ACC:11A0][2013-06-29T15:23:39]i399: Apply complete, result: 0x0, restart:
Required, ba requested restart: No
This suggests that the bundle is trying to install the 1.0.1 package BEFORE
uninstalling the 1.0.0 package and then bundle. Since I'm doing a MajorUpgrade,
isn't it trying to execute these in the somewhat opposite order than how it
should? I would expect it to try to uninstall the 1.0.0 bundle, which would
uninstall the 1.0.0 package, and once that's done, install the 1.0.1 package &
bundle.
So here's what I currently think is happening:
1) Bundle 1.0.1 sees the related Package 1.0.0 and does something that "locks"
it (i.e. puts it in use), because it plans to uninstall it.
2) Bundle 1.0.1 then tries to install Package 1.0.1.
3) Package 1.0.1, detecting Package 1.0.0 on the system, starts a MajorUpgrade,
which causes Package 1.0.1 to attempt to uninstall Package 1.0.0...but it
can't, because Bundle 1.0.1 has it "in use" because Bundle 1.0.1 is prepared to
uninstall it itself (see step 1).
4) The Restart Manager declares the need for a restart because Bundle 1.0.1 has
put in use some files that need to be upgraded.
5) Package 1.0.1 goes ahead with the MajorUpgrade and does what it can, and
returns to Bundle 1.0.1.
6) Bundle 1.0.1 then uninstalls Package 1.0.0, which succeeds, because that's
what it was waiting to do anyway.
7) Bundle 1.0.1 then uninstalls Bundle 1.0.0, which also succeeds.
8) Bundle 1.0.1 reports the installation a success, and mentions the need to
reboot, but because it was a silent, no reboot install, no one was listening
and nothing can be done about it.
I have no idea if this is right at all, and even if it is, I don't know what
can be done to fix it. Can anyone with a better understanding of burn, bundles,
or Windows Installer shed some light?
Alain
P.S. Here's the Bundle 1.0.1 upgrading log:
[0ACC:11A0][2013-06-29T15:23:29]i001: Burn v3.7.1224.0, Windows v6.1 (Build
7601: Service Pack 1), path: C:\Windows\TEMP\MyBundleInstaller_v1.0.1.exe,
cmdline: '-quiet -norestart -l*v
C:\Windows\TEMP\MyBundleInstaller_v1.0.1.exe.log -burn.unelevated
BurnPipe.{GUID1} {GUID2} 2760'
[0ACC:11A0][2013-06-29T15:23:29]i000: Setting string variable 'WixBundleLog' to
value 'C:\Windows\TEMP\My_Bundle_v1.0.1_Installer_20130629152329.log'
[0ACC:11A0][2013-06-29T15:23:29]i000: Setting string variable
'WixBundleOriginalSource' to value
'C:\Windows\TEMP\MyBundleInstaller_v1.0.1.exe'
[0ACC:11A0][2013-06-29T15:23:29]i000: Setting string variable 'WixBundleName'
to value 'My Bundle v1.0.1 Installer'
[0ACC:11A0][2013-06-29T15:23:29]i100: Detect begin, 2 packages
[0ACC:11A0][2013-06-29T15:23:29]i000: Setting string variable
'Java7FamilyVersion' to value '1.7.0_25'
[0ACC:11A0][2013-06-29T15:23:29]i052: Condition 'Java7FamilyVersion' evaluates
to true.
[0ACC:11A0][2013-06-29T15:23:29]i000: Setting string variable
'JavaProductVersion' to value '7.0.250'
[0ACC:11A0][2013-06-29T15:23:29]i102: Detected related bundle: {GUID5}, type:
Upgrade, scope: PerMachine, version: 1.0.0.0, operation: MajorUpgrade
[0ACC:11A0][2013-06-29T15:23:29]i052: Condition 'Java7FamilyVersion AND
(JavaProductVersion >= v7.0.210)' evaluates to true.
[0ACC:11A0][2013-06-29T15:23:29]i103: Detected related package: {GUID3}, scope:
PerUser, version: 1.0.0.0, language: 0 operation: MajorUpgrade
[0ACC:11A0][2013-06-29T15:23:29]i101: Detected package: pkgJRE7, state:
Present, cached: None
[0ACC:11A0][2013-06-29T15:23:29]i101: Detected package: pkgMyClient, state:
Absent, cached: None
[0ACC:11A0][2013-06-29T15:23:29]i052: Condition 'Privileged' evaluates to true.
[0ACC:11A0][2013-06-29T15:23:29]i052: Condition 'VersionNT >= v6.1 AND v7.0 >
VersionNT' evaluates to true.
[0ACC:11A0][2013-06-29T15:23:29]i199: Detect complete, result: 0x0
[0ACC:11A0][2013-06-29T15:23:29]i200: Plan begin, 2 packages, action: Install
[0ACC:11A0][2013-06-29T15:23:29]w321: Skipping dependency registration on
package with no dependency providers: pkgJRE7
[0ACC:11A0][2013-06-29T15:23:29]i000: Setting string variable
'WixBundleRollbackLog_pkgMyClient' to value
'C:\Windows\TEMP\My_Bundle_v1.0.1_Installer_20130629152329_0_pkgMyClient_rollback.log'
[0ACC:11A0][2013-06-29T15:23:29]i000: Setting string variable
'WixBundleLog_pkgMyClient' to value
'C:\Windows\TEMP\My_Bundle_v1.0.1_Installer_20130629152329_0_pkgMyClient.log'
[0ACC:11A0][2013-06-29T15:23:29]i201: Planned package: pkgJRE7, state: Present,
default requested: Present, ba requested: Present, execute: None, rollback:
None, cache: No, uncache: No, dependency: None
[0ACC:11A0][2013-06-29T15:23:29]i201: Planned package: pkgMyClient, state:
Absent, default requested: Present, ba requested: Present, execute: Install,
rollback: Uninstall, cache: Yes, uncache: Yes, dependency: Register
[0ACC:11A0][2013-06-29T15:23:29]i207: Planned related bundle: {GUID5}, type:
Upgrade, default requested: Absent, ba requested: Absent, execute: Uninstall,
rollback: Install, dependency: None
[0ACC:11A0][2013-06-29T15:23:29]i299: Plan complete, result: 0x0
[0ACC:11A0][2013-06-29T15:23:29]i300: Apply begin
[0AC8:12E8][2013-06-29T15:23:29]i000: Caching bundle from:
'C:\Windows\TEMP\{GUID4}\.be\MyBundleInstaller_v1.0.1.exe' to:
'C:\ProgramData\Package Cache\{GUID4}\MyBundleInstaller_v1.0.1.exe'
[0AC8:12E8][2013-06-29T15:23:29]i320: Registering bundle dependency provider:
{GUID4}, version: 1.0.1.0
[0AC8:10C0][2013-06-29T15:23:29]i305: Verified acquired payload: pkgMyClient at
path: C:\ProgramData\Package Cache\.unverified\pkgMyClient, moving to:
C:\ProgramData\Package Cache\{GUID6}v1.0.1\MyClientPackage_v1.0.1.msi.
[0AC8:12E8][2013-06-29T15:23:29]i323: Registering package dependency provider:
{GUID6}, version: 1.0.1, package: pkgMyClient
[0AC8:12E8][2013-06-29T15:23:29]i301: Applying execute package: pkgMyClient,
action: Install, path: C:\ProgramData\Package
Cache\{GUID6}v1.0.1\MyClientPackage_v1.0.1.msi, arguments: ' ALLUSERS="1"
ARPSYSTEMCOMPONENT="1"'
[0ACC:11A0][2013-06-29T15:23:38]i319: Applied execute package: pkgMyClient,
result: 0x0, restart: Required
[0AC8:12E8][2013-06-29T15:23:38]i325: Registering dependency: {GUID4} on
package provider: {GUID6}, package: pkgMyClient
[0AC8:12E8][2013-06-29T15:23:38]i301: Applying execute package: {GUID5},
action: Uninstall, path: C:\ProgramData\Package
Cache\{GUID5}\MyBundleInstaller_v1.0.0.exe, arguments: '"C:\ProgramData\Package
Cache\{GUID5}\MyBundleInstaller_v1.0.0.exe" -uninstall -quiet
-burn.related.upgrade'
[0ACC:11A0][2013-06-29T15:23:39]i319: Applied execute package: {GUID5}, result:
0x0, restart: None
[0AC8:12E8][2013-06-29T15:23:39]i351: Removing cached package: pkgMyClient,
from path: C:\ProgramData\Package Cache\{GUID6}v1.0.1\
[0ACC:11A0][2013-06-29T15:23:39]i399: Apply complete, result: 0x0, restart:
Required, ba requested restart: No
[0ACC:11A0][2013-06-29T15:23:39]i500: Shutting down, exit code: 0xbc2
[0ACC:11A0][2013-06-29T15:23:39]i410: Variable: Java7FamilyVersion = 1.7.0_25
[0ACC:11A0][2013-06-29T15:23:39]i410: Variable: JavaProductVersion = 7.0.250
[0ACC:11A0][2013-06-29T15:23:39]i410: Variable: Privileged = 1
[0ACC:11A0][2013-06-29T15:23:39]i410: Variable: VersionNT = 6.1.0.0
[0ACC:11A0][2013-06-29T15:23:39]i410: Variable: WixBundleAction = 4
[0ACC:11A0][2013-06-29T15:23:39]i410: Variable: WixBundleElevated = 1
[0ACC:11A0][2013-06-29T15:23:39]i410: Variable: WixBundleInstalled = 0
[0ACC:11A0][2013-06-29T15:23:39]i410: Variable: WixBundleLog =
C:\Windows\TEMP\My_Bundle_v1.0.1_Installer_20130629152329.log
[0ACC:11A0][2013-06-29T15:23:39]i410: Variable: WixBundleLog_pkgMyClient =
C:\Windows\TEMP\My_Bundle_v1.0.1_Installer_20130629152329_0_pkgMyClient.log
[0ACC:11A0][2013-06-29T15:23:39]i410: Variable: WixBundleManufacturer = Us
[0ACC:11A0][2013-06-29T15:23:39]i410: Variable: WixBundleName = My Bundle
v1.0.1 Installer
[0ACC:11A0][2013-06-29T15:23:39]i410: Variable: WixBundleOriginalSource =
C:\Windows\TEMP\MyBundleInstaller_v1.0.1.exe
[0ACC:11A0][2013-06-29T15:23:39]i410: Variable: WixBundleProviderKey = {GUID4}
[0ACC:11A0][2013-06-29T15:23:39]i410: Variable:
WixBundleRollbackLog_pkgMyClient =
C:\Windows\TEMP\My_Bundle_v1.0.1_Installer_20130629152329_0_pkgMyClient_rollback.log
[0ACC:11A0][2013-06-29T15:23:39]i410: Variable: WixBundleTag =
[0ACC:11A0][2013-06-29T15:23:39]i410: Variable: WixBundleVersion = 1.0.1.0
[0ACC:11A0][2013-06-29T15:23:39]i007: Exit code: 0xbc2, restarting: No
-----Original Message-----
From: Alain Forget [mailto:[email protected]]
Sent: June 29, 2013 11:58
To: 'Phil Wilson'; 'General discussion for Windows Installer XML toolset.'
Subject: RE: [WiX-users] Upgrade uninstall restart issue
Hi again everyone (all too soon),
Despite having isolated why the RestartManager in our MSI was requesting a
restart and having found a sufficient workaround (see this thread:
http://www.mail-archive.com/[email protected]/msg57554.html ),
when our MSI is bundled, it appears that we're *still* having the same problem
as before (see this thread:
http://www.mail-archive.com/[email protected]/msg57327.html ).
To recap, MyBundle_v1.0.0.exe installs without problem. However, when doing a
silent MajorUpgrade with MyBundle_v1.0.1.exe, the log from the bundled MSI
package shows this:
MSI (s) (80:F4) [10:34:37:564]: RESTART MANAGER: Will attempt to shut down and
restart applications in no UI modes.
MSI (s) (80:F4) [10:34:37:564]: RESTART MANAGER: Detected that the service
MyClientService will be stopped due to a service control action authored in the
package before the files are updated. So, we will not attempt to stop this
service using Restart Manager MSI (c) (A8:60) [10:34:37:580]: RESTART MANAGER:
Session opened.
MSI (s) (80:F4) [10:34:37:611]: RESTART MANAGER: Failed to shut down all
applications in the service's session. Error: 351
MSI (c) (A8:60) [10:34:37:611]: Disallowing shutdown. Shutdown counter: 0
MSI (s) (80:F4) [10:34:37:611]: Note: 1: 2727 2:
MSI (c) (A8:60) [10:34:37:611]: RESTART MANAGER: Successfully shut down all
applications that held files in use.
MSI (s) (80:F4) [10:34:37:611]: Doing action: InstallInitialize Action ended
10:34:37: InstallValidate. Return value 1.
Although the Restart Manager claims in the end that all applications have been
successfully shut down, it still did request the restart, and this means that
it thinks that the old version isn't entirely cleaned up until a restart
happens, which buggers up any future silent upgrades we attempt to do (because
we're assuming users rarely restart their computers, and so the old version
won't be completely washed away, so subsequent upgrades make Bad Things(TM)
happen).
Clearly, it knows that our services is holding files in use and agrees to wait
until the StopServices action before asking for a restart. So why does it then
immediately request a restart anyway?
This answer may be in the Event Viewer, where I found this entry at the time
when the Restart Manager requested the restart:
<RmRestartEvent
xmlns:auto-ns2="http://schemas.microsoft.com/win/2004/08/events";
xmlns="http://www.microsoft.com/2005/08/Windows/Reliability/RestartManager/";>
<RmSessionId>0</RmSessionId>
<nApplications>1</nApplications>
<Applications>
<Application>My Client Bundle Installer v1.0.1</Application>
</Applications>
<RebootReasons>16</RebootReasons>
</RmRestartEvent>
If I'm interpreting this correctly (
http://msdn.microsoft.com/en-us/library/windows/desktop/aa373675%28v=vs.85%29.aspx
: RmRebootReasonDetectedSelf = 0x10, "A system restart is needed because the
current process must be shut down."), the restart is being requested because my
own bundle installer that is running (v1.0.1) is somehow holding the existing
version (v1.0.0) of MyClient's files in use!
I can't imagine how this can be or how this could even make any sense, because
at the InstallValidate action, it shouldn't be mucking around with the files it
will want to uninstall yet, right? Here's my bundle's WiX source, in case any
of you see something I've missed, but it's nothing complex:
<?xml version='1.0' encoding='windows-1252'?> <Wix
xmlns='http://schemas.microsoft.com/wix/2006/wi'
xmlns:bal="http://schemas.microsoft.com/wix/BalExtension";
xmlns:util="http://schemas.microsoft.com/wix/UtilExtension";
>
<?ifndef PRODUCTVERSION?>
<?error PRODUCTVERSION must be defined ?> <?endif ?>
<Bundle
Name=" My Client Bundle Installer v$(var.PRODUCTVERSION)"
UpgradeCode="MYUPGRADEGUID"
Version="$(var.PRODUCTVERSION)"
Copyright="Copyright © Us"
IconSourceFile="lib/Icon.ico"
Manufacturer="Us"
DisableModify="yes"
>
<BootstrapperApplicationRef
Id="WixStandardBootstrapperApplication.RtfLicense" >
<bal:WixStandardBootstrapperApplication
LicenseFile="License.rtf"
LogoFile="lib\logo.png"
SuppressOptionsUI="yes"
ThemeFile="RtfTheme-MyTheme.xml"
/>
</BootstrapperApplicationRef>
<!-- Abort installation if not running with administrator privileges -->
<bal:Condition Message="This installer requires administrator
privileges to run.">
Privileged <!--OR AdminUser-->
</bal:Condition>
<!-- Abort installation if not running on Windows 7 or 8 -->
<bal:Condition Message='Sorry, but this software only supports Windows
7 or Windows 8.'>
VersionNT >= v6.1 AND v7.0 > VersionNT
</bal:Condition>
<Chain DisableSystemRestore="yes">
<PackageGroupRef Id="pkgJRE7" />
<MsiPackage
Id="pkgMyClient"
DisplayName="My Client"
Cache="no"
Compressed="yes"
Permanent="no"
SourceFile="MyClientPackage_v$(var.PRODUCTVERSION).msi"
Visible="no"
Vital="yes"
></MsiPackage>
</Chain>
</Bundle>
</Wix>
Again, this problem does not occur when I just use unbundled MSIs, but it does
happen when the MSI is bundled with burn. Does anyone have any ideas why this
is happening, why our own bundle installer (v1.0.1) is somehow holding/using
the existing installed version (v1.0.0) of MyClient's files in use?
Alain
-----Original Message-----
From: Alain Forget [mailto:[email protected]]
Sent: June 4, 2013 17:02
To: 'Phil Wilson'; 'General discussion for Windows Installer XML toolset.'
Subject: RE: [WiX-users] Upgrade uninstall restart issue
I think it is verbose, but I'm not sure. However, your example showed me what
to look for, and I think you're quite right; somehow, when bundled, the 1.0.1
and 1.0.2 MSIs don't seem to be detecting the old version:
MSI (s) (70:30) [14:35:19:652]: Doing action: FindRelatedProducts Action start
14:35:19: FindRelatedProducts.
MSI (s) (70:30) [14:35:19:652]: PROPERTY CHANGE: Adding WIX_UPGRADE_DETECTED
property. Its value is '{GUID1}'.
MSI (s) (70:30) [14:35:19:652]: PROPERTY CHANGE: Adding MIGRATE property. Its
value is '{GUID1}'.
MSI (s) (70:30) [14:35:19:653]: Skipping action: cmdAlreadyInstalled (condition
is false) MSI (s) (70:30) [14:35:19:653]: Doing action: SetFirstInstall Action
ended 14:35:19: FindRelatedProducts. Return value 1.
MSI (s) (70:30) [14:35:19:653]: PROPERTY CHANGE: Adding FirstInstall property.
Its value is 'true'.
Action start 14:35:19: SetFirstInstall.
MSI (s) (70:30) [14:35:19:653]: Skipping action: SetUpgrading (condition is
false) MSI (s) (70:30) [14:35:19:653]: Skipping action: SetUninstalling
(condition is false) MSI (s) (70:30) [14:35:19:653]: Skipping action:
SetMaintenance (condition is false) MSI (s) (70:30) [14:35:19:653]: Doing
action: LaunchConditions Action ended 14:35:19: SetFirstInstall. Return value 1.
The giveaway is the FirstInstall property that is set to 'true', which is
obviously incorrect. The above log lines occur both when installing/upgrading
MSIs or bundled EXEs. However, in the case of MSIs, there are never multiple
entries for our software; there is only ever one, the version number increments
correctly, and our software also reports the correct version number. In the
case of the bundled EXEs, the two entries *only* appear when upgrading from
1.0.1 to 1.0.2, but not from 1.0.0 to 1.0.1 (although I can't uninstall 1.0.1
without a reboot, which is what prompted this thread in the first place).
Still, I'm guessing there's something wrong with the MSI, and the bundling just
somehow exacerbates the problem and makes it more obvious.
Either way, I don't understand why this is happening. The UpgradeCode of the
MSI Product does NOT change, and ALLUSERS = 1 in all cases. Anyone have any
ideas on what the problem may be?
Alain
-----Original Message-----
From: Phil Wilson [mailto:[email protected]]
Sent: June 4, 2013 14:12
To: [email protected]; 'General discussion for Windows Installer XML toolset.'
Subject: RE: [WiX-users] Upgrade uninstall restart issue
Your log may not be verbose. What you're looking for is something like this for
a proper upgrade detection:
Action start 8:15:57: FindRelatedProducts.
Action 8:15:57: FindRelatedProducts. Searching for related applications
FindRelatedProducts: Found application:
{3B9EA0E2-E0D3-4BA0-A373-7181CFFEF81A}
Action ended 8:15:57: FindRelatedProducts. Return value 1.
The fact that FindRelatedProducts gets set to 1 is not relevant - it just means
that the action completed, not that it found a product. What you need to see
is something that says an older ProductCode was detected, as above.
Phil
-----Original Message-----
From: Alain Forget [mailto:[email protected]]
Sent: Tuesday, June 04, 2013 10:35 AM
To: 'Phil Wilson'; 'General discussion for Windows Installer XML toolset.'
Subject: RE: [WiX-users] Upgrade uninstall restart issue
I must not be understanding what you mean. As I mentioned in the previous
e-mail, the log indicated that FindRelatedProducts was set to 1, meaning that
it did find the related product, no?
Furthermore, the upgrade codes are identical throughout, so I can't imagine how
it could not find the related product.
Alain
-----Original Message-----
From: Phil Wilson [mailto:[email protected]]
Sent: June 4, 2013 12:39
To: [email protected]; 'General discussion for Windows Installer XML toolset.'
Subject: RE: [WiX-users] Upgrade uninstall restart issue
Upgrades don't work like that, and neither do transacted installs.
Look for FindRelatedProducts in the verbose log and see if it's finding the
older product to upgrade. Bottom line: if you have two entries in Add/Remove
Programs then your upgrade is not an upgrade, it's side-by-side, and nothing
about in-use files or restarts or services will cause that.
Phil
-----Original Message-----
From: Alain Forget [mailto:[email protected]]
Sent: Tuesday, June 04, 2013 8:06 AM
To: 'Phil Wilson'; 'General discussion for Windows Installer XML toolset.'
Subject: RE: [WiX-users] Upgrade uninstall restart issue
For both the 1.0.1 and 1.0.2 upgrades, FindRelatedProducts = 1, ALLUSERS = 1
(which is correct), and the UpgradeCodes are definitely static and the same.
You right that all bets are off, but I think the Upgrade is "failing"
because 1.0.2 can't uninstall 1.0.1 because it thinks that some files were in
use when 1.0.1 first upgraded 1.0.0, and so is requesting a restart before it's
willing to budge.
Alain
-----Original Message-----
From: Phil Wilson [mailto:[email protected]]
Sent: June 3, 2013 19:45
To: 'General discussion for Windows Installer XML toolset.'; [email protected]
Subject: RE: [WiX-users] Upgrade uninstall restart issue
Also:
Two entries in Add/Remove means the upgrade failed to upgrade. You have side by
side (or on top of each other) products running, so since the upgrade did not
in fact happen I'd say that then all bets are off regarding proper behavior of
in-use files. Check the log for FindRelatedProducts to see what happened, make
sure ALLUSERS is the same in both and that your upgradecodes are the same. I'd
fix that before wondering about files-in-use behavior.
Phil
-----Original Message-----
From: Hoover, Jacob [mailto:[email protected]]
Sent: Monday, June 03, 2013 11:27 AM
To: [email protected]; General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Upgrade uninstall restart issue
>From
>http://msdn.microsoft.com/en-us/library/windows/desktop/aa373667(v=vs.8>5).
aspx
351 = ERROR_FAIL_SHUTDOWN
Some applications could not be shut down. The AppStatus of the RM_PROCESS_INFO
structures returned by the RmGetList function contain updated status
information.
I'd suggest looking at your ServiceControl elements. Are the services
interdependent (IE does stopping one stop another)? Do you have Wait=no on any
of them?
-----Original Message-----
From: Alain Forget [mailto:[email protected]]
Sent: Monday, June 03, 2013 12:52 PM
To: [email protected]
Subject: [WiX-users] Upgrade uninstall restart issue
We've encountered a curious problem when our bundle auto upgrades. When our
client software dials home and detects that it is outdated, it downloads the
newest version (1.0.1), and runs it with the following command:
cmd /c start MyUpToDateBundle.exe -quiet -norestart -log MyUpToDateBundle.log
This works fine and upgrades the software. However, if I then immediately try
to uninstall the (upgraded, 1.0.1) software, it fails with a message saying
that a restart is needed. Furthermore, if a second upgrade (1.0.2) occurs
before a restart, the software is successfully upgraded, but there are two
entries in the Programs and Features or Add/Remove Programs (ARP), the previous
version (1.0.1), and the current version (1.0.2).
This shouldn't happen. There should be only the most recent/currently installed
version (1.0.2) in the ARP. Furthermore, we don't know what part of our
software would request a restart, because it clearly updates and runs just fine
immediately without a restart. We also do not recall having this problem when
we were using an MSI, but curiously, the logs suggest that it's the packaged
MSI that's requesting the restart:
...
MSI (s) (B8:B0) [12:04:15:942]: RESTART MANAGER: Will attempt to shut down and
restart applications in no UI modes.
MSI (s) (B8:B0) [12:04:15:942]: RESTART MANAGER: Detected that the service
MyService1 will be stopped due to a service control action authored in the
package before the files are updated. So, we will not attempt to stop this
service using Restart Manager MSI (s) (B8:B0) [12:04:15:942]: RESTART
MANAGER: Detected that the service MyService2 will be stopped due to a service
control action authored in the package before the files are updated.
So, we will not attempt to stop this service using Restart Manager MSI (s)
(B8:B0) [12:04:15:942]: RESTART MANAGER: Detected that the service
MyService3 will be stopped due to a service control action authored in the
package before the files are updated. So, we will not attempt to stop this
service using Restart Manager MSI (s) (B8:B0) [12:04:15:942]: RESTART
MANAGER: Detected that the service MyService4 will be stopped due to a service
control action authored in the package before the files are updated.
So, we will not attempt to stop this service using Restart Manager MSI (c)
(60:48) [12:04:15:980]: RESTART MANAGER: Session opened.
MSI (s) (B8:B0) [12:04:16:041]: RESTART MANAGER: Failed to shut down all
applications in the service's session. Error: 351 MSI (c) (60:48)
[12:04:16:041]: Disallowing shutdown. Shutdown counter: 0 MSI (c) (60:48)
[12:04:16:041]: RESTART MANAGER: Successfully shut down all applications that
held files in use.
...
MSI (s) (B8:B0) [12:04:20:760]: Propagated Reboot to the client/parent install.
MSI (s) (B8:B0) [12:04:20:760]: Value of RebootAction property is MSI (s)
(B8:B0) [12:04:20:760]: Windows Installer requires a system restart. Product
Name: MyProduct. Product Version: 1.0.0. Product Language: 1033.
Manufacturer: Us. Type of System Restart: 1. Reason for Restart: 1.
Property(N): ReplacedInUseFiles = 1
CustomAction returned actual error code -1 (note this may not be 100% accurate
if translation happened inside sandbox) MSI (s) (B8:4C)
[12:04:20:762]: Skipping action: SetRemovingForUpgrade (condition is false) ...
MSI (s) (B8:4C) [12:04:28:584]: Product: MyProduct -- Installation completed
successfully.
MSI (s) (B8:4C) [12:04:28:585]: Windows Installer installed the product.
Product Name: MyProduct. Product Version: 1.0.1. Product Language: 1033.
Manufacturer: Us. Installation success or error status: 0.
MSI (s) (B8:4C) [12:04:28:585]: Value of RebootAction property is MSI (s)
(B8:4C) [12:04:28:585]: Windows Installer requires a system restart. Product
Name: MyProduct. Product Version: 1.0.1. Product Language: 1033.
Manufacturer: Us. Type of System Restart: 2. Reason for Restart: 0.
MSI (s) (B8:4C) [12:04:28:585]: Product: MyProduct. Restart required. The
installation or update for the product required a restart for all changes to
take effect. The restart was deferred to a later time.
MSI (s) (B8:4C) [12:04:28:586]: Deferring clean up of packages/files, if any
exist MSI (s) (B8:4C) [12:04:28:586]: MainEngineThread is returning 3010 MSI
(s) (B8:B4) [12:04:28:588]: RESTART MANAGER: Session closed.
MSI (s) (B8:B4) [12:04:28:591]: RESTART MANAGER: Previously shut down
applications have been restarted.
MSI (s) (B8:B4) [12:04:28:592]: RESTART MANAGER: Session closed.
I found two things curious about these logs. First, it claims that it failed to
shut down all applications, but also thinks they all shut down (which I'm
pretty certain they did):
MSI (s) (B8:B0) [12:04:16:041]: RESTART MANAGER: Failed to shut down all
applications in the service's session. Error: 351 MSI (c) (60:48)
[12:04:16:041]: Disallowing shutdown. Shutdown counter: 0 MSI (c) (60:48)
[12:04:16:041]: RESTART MANAGER: Successfully shut down all applications that
held files in use.
Second, the Type of System Restart and Reason for Restart seems to change:
MSI (s) (B8:B0) [12:04:20:760]: Windows Installer requires a system restart.
Product Name: MyProduct. Product Version: 1.0.0. Product Language: 1033.
Manufacturer: Us. Type of System Restart: 1. Reason for Restart: 1.
...
MSI (s) (B8:4C) [12:04:28:585]: Windows Installer requires a system restart.
Product Name: MyProduct. Product Version: 1.0.1. Product Language: 1033.
Manufacturer: Us. Type of System Restart: 2. Reason for Restart: 0.
Unfortunately, I haven't been able to figure out what those type and reason
codes represent. In any case, it seems to think that the restart is needed
because some files in use were replaced:
Property(N): ReplacedInUseFiles = 1
But I don't see how that can be, because our services do get shutdown
correctly. Maybe it's not waiting long enough (even though it really doesn't
take long at all)?
Any ideas why this might be happening and how we could prevent recently
upgraded versions of our software from being restart-locked in this way?
Alain
***************************************
Alain Forget, Ph.D.
Postdoctoral Researcher
CyLab, Carnegie Mellon University
[email protected]
http://cups.cs.cmu.edu/~aforget/
***************************************
----------------------------------------------------------------------------
--
Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free
troubleshooting tool designed for production Get down to code-level detail for
bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2
_______________________________________________
WiX-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wix-users
----------------------------------------------------------------------------
--
How ServiceNow helps IT people transform IT departments:
1. A cloud service to automate IT design, transition and operations 2.
Dashboards that offer high-level views of enterprise services 3. A single
system of record for all IT processes http://p.sf.net/sfu/servicenow-d2d-j
_______________________________________________
WiX-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wix-users
------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
WiX-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wix-users
