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:phil.wil...@mvps.org] 
Sent: June 4, 2013 12:39
To: afor...@cmu.edu; '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:afor...@cmu.edu]
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:phil.wil...@mvps.org]
Sent: June 3, 2013 19:45
To: 'General discussion for Windows Installer XML toolset.'; afor...@cmu.edu
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:jacob.hoo...@greenheck.com]
Sent: Monday, June 03, 2013 11:27 AM
To: afor...@cmu.edu; 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:afor...@cmu.edu]
Sent: Monday, June 03, 2013 12:52 PM
To: wix-users@lists.sourceforge.net
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
afor...@cmu.edu
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
WiX-users@lists.sourceforge.net
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
WiX-users@lists.sourceforge.net
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
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Reply via email to