New issue
Advanced search Search tips
Starred by 10 users
Status: WontFix
Owner: ----
Closed: Apr 2016
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug

Sign in to add a comment
Canary 64-bit incorrectly updates to 32-bit
Reported by, Apr 9 2016 Back to list
UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:48.0) Gecko/20100101 Firefox/48.0

Steps to reproduce the problem:
1. Install Canary 64-bit
2. Successfully install a couple nightly updates (over a few days) 
3. On about the 3rd or 4th nightly update, the relaunch will take forever and then the Canary will finally show up, but as "Not Responding"
4. Task Manage will show Canary as a 32-bit process 

What is the expected behavior?
64-bit Canary should successfully update to 64-bit Canary

What went wrong?
64-bit Canary updated to 32-bit Canary. Screenshot of Task Manager is attached.

Did this work before? Yes Last week

Chrome version: 51.0.2703.1  Channel: canary
OS Version: 10.0
Flash Version: Shockwave Flash 21.0 r0
48.1 KB View Download
I should add that the only resolution I've been able to find is to reinstall Canary 64-bit from
Comment 2 by, Apr 10 2016
Status: WontFix
On occasion, we send a 32-bit build to 64-bit installs. The most frequent case is an ASAN build to help us find memory-related bugs in Chrome. It's most likely that you received one of these build (chrome://version will tell you), and that you'd be back to 64-bit canary the next day.
1. "Occasionally?" I've had this happen on multiple machines in one week.
2. I'm all for testing, but is it supposed to KO the user's Chrome installation in the manner it currently does? As shown in the screenshot Chrome's CPU usage soars (while still not showing up as a window), and then the window is "Not Responding" when it does show up.

Is there a better way of doing this that doesn't make the browser totally inoperable?
Some background: We've recently started shipping ASAN instrumented builds of Chrome to canary users. These builds contain instrumentation that track down heap memory errors, and provide extremely useful bug reports to Chrome developers. As grt@ mentions, if you're on one of these builds you'll see a 'SyzyASan' label if you navigate to chrome://version.

- To limit user pain we filter for machines with sufficient memory, as there is a significant memory overhead to the instrumentation.

- To further limit user pain we randomly select 1 in every 20 users every day. That is, for any day's update you have a 1 in 20 chance of receiving an ASAN instrumented build. The next days update still has the same 1 in 20 chance, so most often you should end up back on a non-instrumented build.

- Unfortunately, the technology is 32-bit only right now. In order to increase the audience of potential users we also ship to 64-bit users, intentionally downgrading them to 32-bit builds for a day.

We are working on making the instrumentation work natively in 64-bit mode, but that is at least 6 months away.

Finally, if the instrumentation is rendering your browser completely unusable we do have an opt-out mechanism in place.
Thanks for the background and information! Makes better sense now. At least the crash can be fixed by doing an in-place reinstallation. 
BTW, what's the opt-out mechanism?
Open the following folder in regedit: HKCU\Software\Google\Update\ClientState\{4EA16AC7-FD5A-47C3-875B-DBF4A2008C20}\cohort

Then look for or create a string key named hint, and set the value to asan-optout

You can also just open a command prompt and run:

reg add HKCU\Software\Google\Update\ClientState\{4EA16AC7-FD5A-47C3-875B-DBF4A2008C20}\cohort /v hint /d asan-optout /f
Can you guys put an end to this insane, unreasonable, and discriminatory (against Windows users) practice? It absolutely ruins UX. Just now my Chrome instance froze up and my CPU usage hit 99%. Checking Task Manager revealed Chrome 32-bit was responsible. There's no way anyone could consider this sensible behavior by any application, even one in alpha mode. C'mon guys, cut it out already.
BTW, running the Chrome 64-bit installer no longer fixes the problem, so now users are left with a completely unusable Chrome installation. ***How is this a good idea on any level???*** It's the equivalent of knowingly pushing malware to users' PCs. And don't tell me it's OK because it's Canary. The point of Canary is to test unstable new features, not *deliberately* bork end user functionality.
It gets worse: trying to uninstall Chrome fires up the 32-bit (are you kidding me?) uninstaller, which of course promptly crashes and makes uninstallation take forever. Please, please, please stop this madness.
The opt-out mechanism listed in comment #8 should prevent this from occurring to you in the future. If you are still suffering from this problem, there is likely something else at fault.

Can you confirm the full version string reported at the top of the page when you visit chrome://version ?
I did the opt-out command and I'm still receiving broken 32-bit builds. I can't tell you anything about version string because Chrome crashes/freezes up/takes 99% of CPU when I launch it.

Please stop this practice overall. I'm sure there are plenty of VMs in the cloud you can test on.
WTF: I downloaded the Chrome 64-bit installer and got a 32-bit build! Oh COME ON. Is this for real? How does this help the end user or testing in any way?
@chrisha: My point is this shouldn't be happening in the 1st place. It's totally unreasonable to push broken builds to users like that. It's also deceptive to install a 32-bit build on a 64-bit user's machine. Deploy those builds to VMs if you want to test.
It happened again. What are you guys doing, seriously? Is anyone trying to fix this problem?
Comment 17 by, Dec 20 2016
Could you confirm that the "hint" value in this registry key is set to "asan-optout"?

reg query HKCU\Software\Google\Update\ClientState\{4EA16AC7-FD5A-47C3-875B-DBF4A2008C20}\cohort
I ran that command and got the attached result, which I don't really know the meaning of. 

Again, my request is that this practice be stopped. There's no logical reason why a user who deliberately selected a 64-bit build should be pushed a broken 32-bit one.
9.9 KB View Download
Comment 19 by, Dec 20 2016
We totally understand that you find the ASAN builds frustrating. As Chris pointed out in comment 4, the ASAN builds on the canary channel help us find stability and security bugs in Chrome before they reach the stable channel.

Run the command Seb provided in comment #8:

reg add HKCU\Software\Google\Update\ClientState\{4EA16AC7-FD5A-47C3-875B-DBF4A2008C20}\cohort /v hint /d asan-optout /f

and a day or so later your machine will be back to the 64-bit builds and will no longer receive the 32-bit ASAN builds. Note that if you uninstall canary and re-install it, you will need to run this command again.

We would love for you to continue to use canary Chrome and file useful feedback so we can make the browser as awesome as possible.

That command doesn't work. I ran *again* after my previous post and once again today I got a busted 32-bit build pushed to me. 

Again, why do you need to do this to users? Why not use VMs?
*Ran it again
Comment 22 by, Jan 3 2017
Very odd. What do you see for the "hint" value when you run the following from a CMD prompt:

reg query HKCU\Software\Google\Update\ClientState\{4EA16AC7-FD5A-47C3-875B-DBF4A2008C20}\cohort
I get "REG_SZ," but this is after I reapplied 
reg add HKCU\Software\Google\Update\ClientState\{4EA16AC7-FD5A-47C3-875B-DBF4A2008C20}\cohort /v hint /d asan-optout /f so I'm not sure if it's useful.
Comment 24 by, Jan 4 2017
If you see
    hint    REG_SZ    asan-optout
then you're golden. This is what you should expect if you run the "query" command immediately following the "add" command.

If, on the other hand, you see:
    hint    REG_SZ
then you have a random chance of being in the "help make Chrome more stable by running an ASAN build" group on each update. If that's not what you want, please run the "add" command again. If doing so does not result in they query command showing
    hint    REG_SZ    asan-optout
then there is something else on your computer that is interfering with ordinary registry operations performed by reg.exe.
If I run 

reg query HKCU\Software\Google\Update\ClientState\{4EA16AC7-FD5A-47C3-875B-DBF4A2008C20}\cohort

right after running

reg add HKCU\Software\Google\Update\ClientState\{4EA16AC7-FD5A-47C3-875B-DBF4A2008C20}\cohort /v hint /d asan-optout /f

I get 

hint    REG_SZ    asan-optout

but if I apply an in-place update between running both commands I just get

hint    REG_SZ   

Ergo, it isn't a problem with my OS, PC, or reg.exe. Google Chrome is literally overwriting the opt-out setting every time it's updated. Can anyone fix this?
Comment 26 by, Jan 6 2017
Could you explain what you mean by "in-place update"? Are you re-running the installer from the download page, visiting chrome://help, or something else?
Visiting chrome://help
Comment 28 by, Jan 9 2017
I don't have an explanation for this. I currently have asan-optout set, and it has not been cleared by the last week's worth of canary updates. Would you please re-run the "reg add" command, wait a few days to collect a few canary updates, then run the "reg query" command to see if the value has disappeared? Note that uninstalling Chrome Canary and re-installing from the download page (or a previously downloaded installer) is expected to clear the hint value.
OK I'll try that. 
Comment 30 by, Jan 19 2017
 Issue 681068  has been merged into this issue.
Comment 31 by, Apr 14 2017
Is there a reg edit to always get asan builds instead of the 1/20 chance?
Yep, just run:
reg add HKCU\Software\Google\Update\ClientState\{4EA16AC7-FD5A-47C3-875B-DBF4A2008C20}\cohort /v hint /d asan-optin /f

Comment 33 Deleted
Comment 34 by, May 25 2017
 Issue 726174  has been merged into this issue.
So my work PC just got pushed a 32-bit build, and the 64-bit installer download keeps failing. Thanks a lot for continuing to abuse your users, guys. This is such an incredibly *ed up policy. And no, registry opt-outs aren't the answer, users should NOT be pushed builds of a type they didn't install in the 1st place. 

I'm beginning to think this sis the result of some kind of bias against Windows users, since somehow we're the only ones cursed with this issue. Why not other OSes? Why are we singled out for this continued nonsense?
Re: Comment 35 by judahric:

For a good insight into why users are randomly selected to run 32 bit builds see this article:

To me this is just a part of being on a "bleeding edge" developer channel and making a contribution. The 32 bit install is only for a limited time - as soon as the next higher level update to the 64 bit update is available it will be installed and you will be back on 64 bit. 

I run Canary on three (3) different Win 7 64 bit Pro & Enterprise instances. I have set the registry key to prevent the 32 bit selection on my somewhat under configured Corporate laptop - it really has bad performance issues with the 32 bit Canary. 

On the other instances if they are selected - I will can live with it till the next update to the 64 bit. I can tell by the sound of my fan right away if I have been selected - my home desktop has at least 4 Canary windows with 50 - 100 total tabs open. Excellent stress test till all the tabs finish loading.

This is all just part of being on a developer channel and trying to make a contribution. In no way do I consider it abuse. There is always the Beta & Stable channels available ...
Yet another instance of a previously opted out 64-bit PC being pushed a broken 32-bit build smfh
 Issue 763715  has been merged into this issue.
 Issue 764639  has been merged into this issue.
I am part of a game developers collaboration testing team, and I can tell you right now that chrome 32 bits on a 64 bits machine doesn't render. I fail to understand why you would claim to need to employ a mismatching update in search for bugs. OBVIOUSLY it will not work. It doesn't communicate well with my hardware and OS. I just uninstalled canary for the 5th time because of this bug. Gonna try the opt-out now - hoping it sticks.
Sign in to add a comment