+Joshua

We ship 32-bit ASAN even to the 64-bit canary channel. (There is no 64-bit ASAN, IIUC.)

The workaround, for you, is to opt-out of ASAN. You will also have to reinstall because the ASAN version number is higher than the non-ASAN version number.
(1) Uninstall Chrome Canary.
(2) Run regedit → HKEY_CURRENT_USER\Software\Google\Update\ClientState\{4EA16AC7-FD5A-47C3-875B-DBF4A2008C20}\cohort → create or modify the key "hint" to be "asan-optout".
(3) Reinstall Chrome Canary.

This is extremely confusing behavior and I think it merits reevaluation. If Chrome is moving toward 64-bit on all platforms then it shouldn't be opting users back into an experiment during explicit reinstallation of a 64-bit canary.

Further: ASAN works on Linux in 64-bit mode, so why should it not work on Windows in 64-bit mode? https://www.chromium.org/developers/testing/addresssanitizer

+chrisha, laforge to comment on 64-bit ASAN for Windows.

Otherwise, the technical issue is that Omaha could clear the cohort information when Chrome is uninstalled. I believe it will do this eventually, if you wait long enough between the uninstall/reinstall: Omaha has to wake up and notice that Chrome has been removed. The user will still have an X% chance to be reassigned to the experiment on the new installation, but I believe that's consistent with how we handle Finch experiments.

ASAN Windows 64-bit doesn't yet exist for two reasons:

- ASAN on Windows is actually delivered via a SyzyASAN clone of the original address sanitizer. It is 32-bit only, and won't be ported to 64-bit.
- Moving forwards, we will be moving to use the regular ASAN (once Clang on Windows, ie Lexan, is sufficiently far along). But even in that world there will initially be no 64-bit Windows support, as the runtime library component hasn't been ported to 64-bit Windows. We'll be attacking that over the next 2 quarters.

I agree that the behaviour is slightly confusing, but this will eventually be going away. In the meantime, the ASAN builds are finding many high quality bugs.

OK, thanks for the information.

As described in #4, yes, uninstallation of Canary should clear this cohort information so the state of experiments are reset. Thanks in advance for fixing this.

+grt, sorin: How complex is it to hook the Chrome uninstallation event to do as described above?

IIUC this is hard to do from Omaha because Omaha is likely not running at the time Chrome is uninstalled.

I suggest we try to repro this issue and understand why the cohort information is not cleared or what else is going on. Inspecting the code for Omaha indicates that the ClientState and its associated values should be deleted.

It might certainly have been the case that I was opted in to the experiment again upon subsequent installation. If I should try to either reproduce again or gather logs please tell me.

Chrome's uninstaller runs Omaha on its way out the door in the hopes that Omaha will promptly process Chrome's removal. Sawbuck logs should be informative. If needed, Chrome could remove certain values from ClientState to ensure that stale cohort data isn't used for subsequent installs.

FWIW, I think that Chrome's execution of Omaha at uninstall is causing problems for .MSI installs, so I've been wondering if there's something better to be done. Maybe Chrome needs to use breakaway-from-job since its uninstaller is run via Windows Installer machinery in this case.