New issue
Advanced search Search tips

Issue 602530 link

Starred by 2 users

Issue metadata

Status: Archived
Owner:
Closed: Jul 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug



Sign in to add a comment

Upgrading Chrome with MSI via Group Policy fails

Reported by pombo...@gmail.com, Apr 12 2016

Issue description

UserAgent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.109 Safari/537.36

Steps to reproduce the problem:
On a clean Windows 10 (v1511) computer with no third party software installed:

1. Deploy Chrome 48.0.2564.109 using the Google provided msi by assigning the application in a GPO Computer Configuration.
2. Turn on a targeted computer, and Chrome is installed.  Logon to see that Chrome installed perfectly.
3. Edit the GPO and add Chrome 49.0.2623.112 as an assigned application, set to REPLACE (uninstall) the Chrome 48 application created in step 1.
4. Reboot the targeted computer.
5. You'll see "Removing Chrome...", followed by "Installing Chrome..." -- as expected.
6. Logon to the computer.
7. Chrome is no longer installed.  This is in error.

What is the expected behavior?
Chrome should be installed.

What went wrong?
According to the logs, the uninstalls of v48 and google updater are successful, but the installation of v49 fails with error 1603.  This is because the DoInstall action fails with error -1606219999.

To uninstall Chrome, the msi launches an executable to perform the actual uninstallation.  That executable, in turn, launches the un/installer for google_updater.  I believe that the executable doesn't wait for the google_updater process to end and quits early.  This allows the Chrome installer to run out-of-order with the google_updater installer.

Since Google Update is in the process of being uninstalled, I think the Chrome installer detects this "bad state" and aborts the installation.

Did this work before? N/A 

Chrome version: 48.0.2564.109  Channel: stable
OS Version: 10.0.10586
Flash Version: Shockwave Flash 20.0 r0

I've tested this on several combinations of Chrome from v40-v49, and it fails consistently.

When it fails, the chrome_installer.log only lists uninstall events.  (The DoInstall action fails before writing any events?)

Workarounds (none are acceptable in our environment):
- Manually uninstalling Chrome using "Programs and Features" prior to the reboot prevents the problem.

- Rebooting the computer a second time results in Chrome being installed successfully (sometimes, but other times it fails to uninstall v48 even though Chrome is no longer installed).

- When creating the Chrome 49.0.2623.112 assigned application in GPO, set to UPGRADE the Chrome 48 application.

- Install another application the uses Google Update (such as Google Earth).  This prevents Google Update from being uninstalled.

- Modify the msi to add an artificial 30 second delay somewhere before DoAction.  This allows the google_updater process to exit before beginning the installation.  However, this causes the google_updater msi to fail with "Failed to grab execution mutex. System error 258."  This is probably OK since we are about to reinstall it, but who knows?

This issue is similar to  issue #381425 
 
chrome_installer.log
448 bytes View Download
GoogleUpdate.log
39.0 KB View Download
msi_chrome_install.LOG
120 KB View Download
msi_chrome_remove.LOG
95.0 KB View Download
msi_updater_removal.LOG
85.4 KB View Download

Comment 1 by wfh@chromium.org, Apr 12 2016

Cc: sorin@chromium.org gan...@chromium.org

Comment 2 by b...@chromium.org, Apr 12 2016

Components: Internals>Installer

Comment 3 by grt@chromium.org, Apr 12 2016

Can you change step 3 so that the old version of Chrome isn't uninstalled first? Chrome's .msi will take care of updating the old version without first removing it.

Comment 4 by pombo...@gmail.com, Apr 12 2016

Yes, I can change step 3 so that the old version of Chrome isn't uninstalled first.  I documented this as one of the workarounds in the original post.

Unfortunately, our policy implementation is much more complex than the simple, reproducible scenario I posted here.  This workaround cannot be used in all situations.

Comment 5 by grt@chromium.org, Apr 14 2016

Does step 3 equate to msiexec /x of the old .msi followed immediately by msiexec /I of the new?

Comment 6 by pombo...@gmail.com, Apr 14 2016

"Does step 3 equate to msiexec /x of the old .msi followed immediately by msiexec /I of the new?"

Yes, I believe so.  If so, that might be an easier way to reproduce the problem than using GPO.  I'll test this when I get a chance.
Owner: grt@chromium.org
Assigning to Greg to remove off Triage queue.

Comment 8 by grt@chromium.org, Jul 13 2016

Labels: Needs-Feedback
Project Member

Comment 9 by sheriffbot@chromium.org, Jul 13 2017

Status: Archived (was: Unconfirmed)
Issue has not been modified or commented on in the last 365 days, please re-open or file a new bug if this is still an issue.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Sign in to add a comment