Issue metadata
Sign in to add a comment
|
Open handle on chrome.exe in kernel blocks updates until reboot
Reported by
stefan.p...@gmail.com,
Jan 23 2018
|
||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132 Safari/537.36 Steps to reproduce the problem: Use Chrome Canary on latest Windows 10. Restart Chrome in order for an auto-update to be applied. (Sorry, there is just no way for me to narrow it down right now.) What is the expected behavior? After restart, the new version of Chrome will be used. What went wrong? Using an elevated procexp64.exe, I found one, and only one, handle on anything with "Chrome SxS" in the path. It’s in the kernel, and of course I don’t know where it came from. There does not seem to be a way to get rid of the handle short of rebooting the system. Then, the update will go through once. (It updated to 65.0.3324.0, which then has the same problem.) Did this work before? Yes Chrome version: 65.0.3317.0 Channel: stable OS Version: 10.0 Flash Version:
,
Jan 24 2018
,
Jan 25 2018
Thanks for filing the issue! As the issue seems to be out of scope for ET team to triage this, Hence requesting some one from Internals>Installer team to have a look into it and help in further triaging.
,
Feb 1 2018
I’m requesting that this issue be closed. The root cause turned out to be an orphaned icon-less tile for Chrome Canary stuck on the Windows taskbar that doesn’t go away unless the user logs out. This has appeared repeatedly in the past, but I am not able to reproduce it now.
,
Feb 2 2018
Thanks for the update. Feel free to re-open if you're able to reliably reproduce the issue. |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by stefan.p...@gmail.com
, Jan 23 2018