[Update: New workaround] Google Chrome partially breaks w/ Windows 10’s May update

Ben Schoon | Oct 12 2020 - 10:36 am PT

In May 2020, Microsoft released its latest significant update for Windows 10. As an unfortunate side effect of the May 2020 Windows 10 update, some users have reported notable issues with the Google Chrome browser.

Following an update to Windows 10’s May 2020 version, some users across Reddit and Google’s Help Forums have noted that the browser has stopped syncing and reverts to a signed-out state upon a reboot. This doesn’t affect bookmarks but it would affect the data you back up to your Google account for the sake of syncing to smartphones or other computers.

Further, and perhaps most annoyingly, this issue is also deleting cookies off of the machine. With that, websites treat that Chrome browser as a fresh install, asking users to sign in every time they reboot their machine.

As pointed out by TechDows, Google has actually been aware of these issues with Chrome since before the Windows 10 May update was released. A Chromium bug report from April details Google’s knowledge of the problem, and a full two months later the company is still investigating the problem.

Update 10/12: Nearly four months after we first reported on this problem, it’s still happening. Some users are still encountering issues on the latest versions of Windows while using Chrome and it seems that Google and Microsoft have no clear solution in sight.

Luckily, a new workaround has appeared that seems to fix the problem as well as revealing its potential source. Unearthed by TechDows, a user commented on a Chromium thread to point out that an “S4U” task in the Windows Task Scheduler seems to cause Chrome to dump passwords and other data. Microsoft explains what an “S4U” task is in more detail here, but the long story short is that it allows the computer to run tasks as a local system account. The user explains:

This is because the RPC that UBPM uses to create the S4U token can sometimes delete your saved credentials in lsass. Amongst other things, your saved credentials (or rather, the hash of them) are used to generate your DPAPI user encryption key, and when they’re deleted lsass just uses the hash of the empty string (!!).

Frankly, that’s way over my head, but other users on the thread report back that disabling these S4U tasks fixes the problem. Notably, at least one Microsoft engineer responded to the comment to say that they are looking into this solution. To try it out for yourself, open a PowerShell window as an administrator and paste the command below. Then, delete any tasks it lists from the Task Scheduler.

Get-ScheduledTask | foreach { If (([xml](Export-ScheduledTask -TaskName $_.TaskName -TaskPath $_.TaskPath)).GetElementsByTagName(“LogonType”).’#text’ -eq “S4U”) { $_.TaskName } }

If you’re being affected by this frustrating issue, give it a shot!

The original article follows.

If you’re a Chrome user on Windows 10, it’s probably best to avoid the May update — version 2004 — until things get patched up. You can do so by going to Settings > Update & Security > Pause Updates. There, you can pause any Windows 10 updates for up to 35 days. In my case, I really hope that means Google has this patched up before July 2nd.

Notably, there is one potential workaround that Google security researcher Tavis Ormandy figured out. He explains:

If you look in Event Viewer, under Windows Logs > Applications and Services > Microsoft > Windows > Crypto-DPAPI > Operational, do you see any errors? If the answer is yes, try this:

Close all Chrome Windows

Lock (Press Win+L) your Workstation

Unlock, then start Chrome, does it work then?

If you’re affected, drop a comment below and let us know if this workaround patches things up (temporarily, at least) for you. There’s a good chance, too, that other Chromium-based browsers could be affected by this as well. As Windows Latest points out, other apps affected by this bug include Microsoft’s own Mail and OneDrive apps.