The .msi log indicates that Chrome's installer failed while trying to uncompress the install archive. Unfortunately, the .pml file does not contain the events that would show what is happening. Is it possible to capture another ProcMon log, ensuring that it contains the *_chrome_installer.exe and setup.exe processes? Thanks.

Hi Greg:

Before I go back to our customer; I noticed that in the successful run, chrome_installer.exe is started from the on-disk location `C:\Program Files\Google\Update\Install\UUID\chrome_installer.exe`

In the failing case, chrome_installer.exe is written to `C:\Program Files\Google\Update\Offline\UUID\51.0.2704.106_chrome_installer.exe`, but never to 'Update\Install'. There's no event captured for GoogleUpdate.exe trying to start the chrome_installer.exe process in the failing case.

Do you think it's more plausible that the installer never gets to the point where it even tries to start *_chrome_installer.exe?

Ah, as it happens the failure shown in "googlechrome_MSI_and_StandaloneInstaller (1).log" does not correspond with the one in the ProcMon log. The msi log shows:

ERROR	4164	4856	13:36:40-052		0	[09/15/16 13:36:40.061][GoogleUpdate:goopdate][4164:4856][Installer failed][C:\Program Files\Google\Update\Install\{B5BF1876-7C30-48D6-B7F1-09E4D65DA028}\chrome_installer.exe][--do-not-launch-chrome --multi-install --chrome --system-level /installerdata="C:\Users\ADMINI~1.SPO\AppData\Local\Temp\gui7F89.tmp"][12]
INFORMATION	4164	4856	13:36:40-052		0	[09/15/16 13:36:40.061][GoogleUpdate:goopdate][4164:4856][InstallApp returned][0x80040902][{8A69D345-D564-463C-AFF1-A69D9E530F96}][type:4][code: 12][The installer failed to uncompress archive. Please download Google Chrome again.][]

Where "12" means UNCOMPRESSION_FAILED.

In the ProcMon log, however, I see that the GoogleUpdate /handoff command exited with 0x80004002 (E_NOINTERFACE). The failing log shows GU running as NT AUTHORITY\SYSTEM, whereas the safe mode install has it running as <MACHINE>\Administrator. I wonder if that's relevant.

Sorin: I see that HANDOFF_ERROR (10) is stuffed into the install ping. Could someone from your team look at the procmon log w/ GU symbols to see where the install went off the rails? Since it seems that the failure happens before Chrome's installer is run, I'm assigning this to you for further triage/analysis. Don't hesitate to send it back my way if Chrome does seem implicated. Thanks.

I do not have access to the logs, but some preliminary thoughts:

When installing Chrome, the GoogleUpdate Client first tries to CoCreate the GoogleUpdate Service. If that fails, then the Client will attempt the Chrome install itself. The latter case is what we are seeing, and explains why the Chrome Installer is run as Admin and not System.

Greg, since the Chrome Installer is running, Google Update is likely functioning as expected. The E_NOINTERFACE returned may be a bug. With multiple failures, there is code that takes the first failure sometimes. 

Logs access has been granted.

I looked at the logs and it is not clear what is causing the E_NOINTERFACE error. Would be nice to get a sawbuck log for a dbg build of GoogleUpdate in the error case. We currently do not upload the dbg binaries, so I will work with +waffles@ to get that uploaded and then we can get that log.

Could the user please run this dbg version and get the sawbuck log?
https://dl.google.com/tag/s/appguid%3D%7B8A69D345-D564-463C-AFF1-A69D9E530F96%7D%26iid%3D%7B0196E548-F3FC-57C9-2B18-4C237EB3C5B4%7D%26lang%3Den%26browser%3D4%26usagestats%3D0%26appname%3DGoogle%2520Chrome%26needsadmin%3Dprefers%26ap%3Dx64-stable-statsdef_1%26installdataindex%3Ddefaultbrowser/update2/installers/dbg/googleupdatesetup.exe

Working on reaching out to the customer now.

Received sawbuck log from user (available internally via Drive):

https://drive.google.com/a/google.com/file/d/0By9xEkAUmm_cM1JsSHJiVEsxMEU/view?usp=sharing

The sawbuck log indicates that the install fails with [0x80040809][No update is available.] for Chrome. I presume the customer has set the policy to not allow for installs/updates?

Case history indicates the agent went over policy and registry settings with the customer. The customer was not using any group policy objects, and the relevant local registry settings were checked, and did not include any settings to block installs/updates.