Usually you can fix it by running the web installer which will forcefully update your Canary installation:
https://www.google.com/chrome/browser/canary.html

I ran the web installer, problem persists: https://i.imgur.com/5mSz2Ad.png

Unable to reproduce the issue on Win-10 using latest canary #68.0.3429.0.

Attached a screen cast for reference.

Following are the steps followed to reproduce the issue.
------------
1. Ran chrome canary 68.0.3429.0
2. HELP>ABOUT
3. Nearly up to date! Relaunch Google Chrome to finish updating.
4. Clicked Relaunch
5. Chrome Canary got updated to 68.0.3430.0
Note: Unable to test the issue with 68.0.3425.0 as canary has reached to 68.0.3429.0.

Removing the Needs-Bisect label and requesting someone from Internals>Installer team to please help us in further debugging of the issue.

Thanks...!!

Hi. Could you share the output of the following three commands from a cmd prompt:

dir "%localappdata%\Google\Chrome SxS\Application"

reg query HKCU\Software\Google\Update\Clients\{4ea16ac7-fd5a-47c3-875b-dbf4a2008c20} /s /reg:32

reg query HKCU\Software\Google\Update\ClientState\{4ea16ac7-fd5a-47c3-875b-dbf4a2008c20} /s /reg:32

and attach the file %TEMP%\chrome_installer.log? This might be enough info for us to see what's going wrong for your install. Thanks.

cmd output 1: https://i.imgur.com/8R5LDvD.png
cmd output 2: https://i.imgur.com/eHLGcGL.png
log: https://pastebin.com/LGFrchpp

Thanks. It appears that the new version is being installed properly and is waiting to be swapped into place. The call to MoveFileEx to rename chrome.exe to old_chrome.exe is failing with ERROR_SHARING_VIOLATION:

[0514/091219.393:ERROR:move_tree_work_item.cc(95)] failed move C:\Users\user\AppData\Local\Google\Chrome SxS\Application\chrome.exe to C:\Users\user\AppData\Local\Google\Chrome SxS\Application\old_chrome.exe: The process cannot access the file because it is being used by another process. (0x20)

The directory listing of %localappdata%\Google\Chrome SxS\Application doesn't show that there is an old_chrome.exe, so it's likely the case that another program running on your machine has an open handle on "%localappdata%\Google\Chrome SxS\Application\chrome.exe" and is preventing it from being renamed.

Both Process Explorer (https://docs.microsoft.com/en-us/sysinternals/downloads/process-explorer) and Process Hacker (https://processhacker.sourceforge.io/) have a "Find Handles or DLLs" feature (Ctrl-F). You can use this to see what processes have an open handle to chrome.exe.

Let us know if you figure out what it is.

thanks grt. to use Process Explorer Chrome would need to be running. AFAIK we want to know what is locking the file when it is not running. So I simply closed Chrome and tried to delete/rename the file. It told me that System (PID 4) has a lock on it: https://i.imgur.com/41mjZ3y.png

When system has a lock on something it is my understanding that the only way to release it is to bring it offline.

I've restarted the machine since this started happening but I will try to rename it again after restarting before running chrome and report back.

turns out a restart was not needed to unlock the file.

`C:\Windows\System32\taskkill.exe /IM dwm.exe /F`

restarting the Desktop Window Manager did it.

Note that the lock was from PID 4 (always System), not dwm. How does this part of Windows works is beyond me.

"the only way to release it is to bring it offline."

as in bring the disk offline via Disk Management.

I think the update page chrome://settings/help could display an actually helpful diagnostic message in this case since Chrome or its updater utility knows the underlying reason e.g. "Can't remove the old chrome executable. Try restarting your session or OS. See ... for more info".

I can't say I have a clue as to why killing dwm (desktop window manager) released a handle on chrome.exe, but I'm glad to hear you figured it out.

Better messaging in chrome://help for this case is a fantastic idea. I'm tuning this issue into a feature request for exactly that.

Problem is still happening on the new version same issue. This time killing DWM did not release the lock.

Also tried excluding the folder from the indexing service, and stopping it. Still no go.

So I used SysInternal's Handle with flags -a -p <PID of main Chrome process>, which gave me this https://pastebin.com/06e7fLds

I think it's the other way around: you need to list the processes that lock Chrome's files:
handle "Chrome SxS\Application"

To list processes that lock old_chrome.exe:
handle old_chrome.exe

i used the PID for the BROWSER's PID as indicated in the Chrome Canary process explorer. Isn't that the main process?

Also, I don't have old_chrome. I have trouble deleting/renaming chrome.exe. The only other file in the folder is new_chrome.

Chrome Canary process explorer = chrome's task manager

What do you see if you run the following command?

  handle "Chrome SxS\Application"

It should list all processes that lock files in your Chrome Canary directory.
Don't forget to exit Chrome before running this command.

i ran handle64
https://pastebin.com/Ue8KpM09

In addition to System PID 4, which is weird, there are lots of chrome.exe, which means you either didn't exit Chrome before running the command or these are zombie processes which you need to terminate in OS task manager. Zombie processes may be caused by bad extensions so try chrome://settings/cleanup

I didn't exit it. here's the report after exiting: 

Nthandle v4.11 - Handle viewer
Copyright (C) 1997-2017 Mark Russinovich
Sysinternals - www.sysinternals.com

System             pid: 4      type: File          1970: C:\Users\user\AppData\Local\Google\Chrome SxS\Application\chrome.exe
System             pid: 4      type: File          81DC: C:\Users\user\AppData\Local\Google\Chrome SxS\Application\chrome.exe
System             pid: 4      type: File          8560: C:\Users\user\AppData\Local\Google\Chrome SxS\Application\chrome.exe
System             pid: 4      type: File          D14C: C:\Users\user\AppData\Local\Google\Chrome SxS\Application\chrome.exe
System             pid: 4      type: File          E9DC: C:\Users\user\AppData\Local\Google\Chrome SxS\Application\chrome.exe

the lock is on the file alone.

Note that I installed chrome canary when I used to have UAC off. Now UAC is set to default. I turned it off and tried to update, it didn't help.

I don't know if this would make a diff.

>I installed chrome canary when I used to have UAC off. Now UAC is set to default. 

This is a known recipe for all kinds of elusive bugs, quite possibly the one you observe too.
Try completely uninstalling Chrome, deleting all of its application directories, then reinstall it.

it seems for now that closing other programs released the handle. next update I will try to narrow down which program it was.

i would like to try this before reinstalling.

thanks!

I suspect you either have some anti-virus software or a virus camping out in the kernel and holding files open inappropriately. That would explain why pid 4 has open handles after you quit Chrome.

I found the culprit. The 4 persistent handles are from Whatsapp Desktop v0.2.9230. It had to be via trial and error (close one app at a time and see if the handles go away), as AFAIK you can't know which handles belong to which processes.

I confirmed this by replicating the issue: handles are only present when Whatsapp Desktop is running.

I installed v0.2.9229 and the handles so far have not persisted. If I find them again I will report back.

note that I had v0.2.9230 installed and it didn't tell me I needed an update. I downloaded the latest version from their site and it came 1 version lower, v0.2.9229.

I can re-confirm that WhatsApp, now back on version 0.2.9230, keeps the handles on chrome.exe via the systemprocess, making it impossible to update chrome.