Windows - Data Collection & Auditing - Enable Google Chrome Update Log

What the Chrome update log activator does

This Automox Worklet™ activates Google's built-in update diagnostic logging on Windows endpoints so the next Chrome auto-update attempt writes a verbose trace to disk. The Worklet creates the C:\GoogleUpdate.ini configuration file with all five logging channels (LC_UTIL, LC_SERVICE, LC_CORE, LC_NET, LC_OPT) pinned to logging level 6, and sets the IsEnabledLogToFile DWORD to 1 under both the 32-bit (HKLM:\Software\Google\UpdateDev) and 64-bit (HKLM:\Software\WOW6432Node\Google\UpdateDev) registry paths. The configuration follows Google's documented logging contract for Google Update (GoogleUpdate.exe / goopdate.dll).

Once activated, Chrome's update agent writes timestamped entries to C:\ProgramData\Google\Update\Log\GoogleUpdate.log on the next scheduled task run, the next manual chrome://settings/help check, and on every subsequent update cycle. AppendToFile=1 keeps history intact across reboots, ShowTime=1 adds wall-clock timestamps to every line, and LogToStdOut=1 plus LogToOutputDebug=1 mirror the same stream to DebugView and stdout for live capture during a remote support session.

Evaluation is non-destructive. The Worklet only remediates when both the configuration file and both registry paths are missing the IsEnabledLogToFile=1 value, so any custom logging configuration already in place on the endpoint is preserved. If a previous run, a GPO under HKLM:\SOFTWARE\Policies\Google\Update, or a manual Google support session already activated logging, the Worklet reports compliant and exits without writing anything.

Why activate Chrome update diagnostic logs

Chrome's update agent fails quietly by default. When GoogleUpdate.exe cannot reach tools.google.com, when a proxy strips the update request, when the BITS service is disabled, or when a previous Chrome install left a corrupted Omaha state, the user sees a stale About Chrome page and no error. The help desk sees an endpoint reporting Chrome 119 long after the rest of the fleet rolled to 121. By the time the version drift becomes visible, the endpoint has missed weeks of critical security fixes, and the root cause is no longer in any log because Chrome's update agent never wrote one.

Update diagnostics belong to the platform, not to each individual support ticket. This Worklet treats Chrome update logging as a baseline configuration: every endpoint under Automox management writes a GoogleUpdate.log, so the day a Chrome zero-day patch fails to land on a subset of the fleet, the evidence already exists on disk. The catalog defines the desired state once; the Worklet holds that state on every workstation and server under Automox management, including endpoints that haven't filed a ticket yet.

Once the log file exists, the support workflow shifts from guessing to reading. GoogleUpdate.log records each network call to update.googleapis.com, each Omaha protocol response, each component update attempt, and each elevation failure with a specific exit code. You can grep for HRESULT values, correlate timestamps with proxy logs, and answer the question every help desk hits: is the endpoint never asking for an update, asking and getting refused, or asking and failing to install?

How Chrome update logging activation works

1. Evaluation phase: The Worklet runs Test-Path against C:\GoogleUpdate.ini and runs Get-ItemProperty against HKLM:\Software\Google\UpdateDev and HKLM:\Software\WOW6432Node\Google\UpdateDev for the IsEnabledLogToFile value. If the config file is present, or if either registry path reports IsEnabledLogToFile=1, the endpoint exits 0 as compliant. Only endpoints with no configuration file and no value in either registry path are flagged for remediation with exit code 2.

2. Remediation phase: The Worklet writes C:\GoogleUpdate.ini with a [LoggingLevel] section setting LC_UTIL, LC_SERVICE, LC_CORE, LC_NET, and LC_OPT to 6 (verbose), and a [LoggingSettings] section with EnableLogging=1, ShowTime=1, AppendToFile=1, LogToStdOut=1, and LogToOutputDebug=1. It then creates the UpdateDev registry keys under both the 32-bit and 64-bit paths if they are missing, sets IsEnabledLogToFile as a DWORD with value 1, and exits 0. The next Google Update Service scheduled task run produces the first log entry; a reboot is recommended but not required.

Chrome update logging requirements

• Windows workstation or server with Google Chrome installed and Google Update (GoogleUpdate.exe / GoogleUpdateService) present

• SYSTEM or administrator context to write C:\GoogleUpdate.ini and to create keys under HKLM:\Software\Google\UpdateDev (the default Automox agent context satisfies this)

• Write access to C:\ProgramData\Google\Update\Log\, where GoogleUpdate.log is created on the next update cycle

• No conflicting policy under HKLM:\SOFTWARE\Policies\Google\Update that disables update logging; group policy takes precedence over the UpdateDev key

• Recommended (not required): reboot or restart the Google Update Service after remediation so the next scheduled task picks up the new logging configuration immediately

Expected diagnostic log output after activation

Within one scheduled-task cycle of remediation (Google Update Service fires roughly hourly), C:\ProgramData\Google\Update\Log\GoogleUpdate.log starts receiving entries. Each line is timestamped and tagged with the source component, so a stalled auto-update produces a traceable sequence: an LC_NET line for the call to update.googleapis.com, an LC_CORE line for the Omaha protocol response, and an LC_SERVICE line for the elevation or install attempt. A successful update closes with an exit-zero LC_CORE entry; a failed update closes with an HRESULT code you can search against Google's published Omaha error list.

Verify the activation by running Test-Path C:\GoogleUpdate.ini and Get-ItemProperty 'HKLM:\Software\Google\UpdateDev' -Name IsEnabledLogToFile on a pilot endpoint; both should return positive results. To force the first log entry without waiting for the scheduled task, open Chrome and navigate to chrome://settings/help, which triggers an on-demand update check and writes an immediate LC_CORE entry to GoogleUpdate.log. Capture the log alongside the Automox activity log when escalating a stuck-version endpoint to Google support – the verbose trace is exactly the artifact their team will request first.