Are you running any network (anti-virus, firewall, parental controls, etc.) software that does something different for the non-admin user vs. the admin user? Chrome should fail over to HTTP(S) over TCP if QUIC (which runs over UDP) doesn't work. It's possible there's a bug in the failover code.

Its a corporate machine and has antivirus and stuff. Hard to tell if they did something to the effect that you mention. But this issue only happens for google sites. I don't think they are doing anything special for google sites. Non google sites with https load just fine.

Can you collect a net-internals trace?

https://dev.chromium.org/for-testers/providing-network-details

The QUIC protocol is only supported by Google (and a few other servers) so if there are any network devices which interfere with QUIC (UDP traffic) that would end up mostly affecting Google.

I had to restart my box a bunch of times due to Windows Update installing all those updates. After that, I haven't been able to reproduce this issue. 

I'll keep an eye out. Maybe it happens after a while? Will provide the net-internals trace when it happens. If not, maybe we can close this issue in a day or two.

It did happen after a while. So here's the trace.

Deleted: net-internals-log.json 304 KB

net-internals-log.json 304 KB View Download

Found something this morning

 - if I have Chrome stable open and I try google sites, I run into this issue
 - if I close Chrome stable, wait for all chrome processes to exit (via task manager) and then open a new Canary instance and try, google sites load fine.
 - I've pinned gmail tabs (work gmail) on Chrome stable. So if I open Chrome stable and shut it down quickly, even before the gmail tab gets a chance to load fully - and then open Canary and try google sites, it fails.

So tl;dr - Ensure gmail tab is loaded fully (in Chrome stable). Then clean exit Chrome stable. And then open Canary and google sites work.

I've looked at your net-internals trace, and it looks like something in your network is blocking QUIC traffic after the handshake completes. In each of the QUIC_SESSION events, within 100ms of the connection being established no more packets are received by the server. Do you know what firewall or NAT box you are going through? Who is your ISP?

Also, can you send a net-internals from Canary? I *suspect* it's merely a coincidence that it's working, but I'd love to confirm.

The trace was from Canary. 

Also, if something was blocking QUIC, then it'd block it always, wouldn't it?

Like I said in my earlier comment, if Chrome stable is not running in parallel, this issue doesn't happen. 

> Also, if something was blocking QUIC, then it'd block it always, wouldn't it?

You'd be surprised at the variety of bizarre behavior we see from network devices. In particular, the mode of dropping UDP after less than a second has been observed elsewhere.

Fascinating that the blocking does not happen to Canary if Chrome stable is not running at the same time.

Upgraded to Canary 55 today and could not connect to google sites with the above workaround (shutting down Chrome stable workaround). Finally, running as Admin worked.

I'm going to check Virus scanner logs to see if there is any mention of QUIC (I doubt it though). But is it possible that running as admin bypasses the blocks? 

Also, isn't Chrome stable using QUIC? Any blockages would apply to the Stable version as well, no?

OK I give up - there is no method to this madness :). Sometimes one way works, sometimes the other. Luckily Chrome stable works so far (maybe I shouldn't jinx it ;) ).

The idea it may be a virus scanner sounds reasonable.  Is it possible for you to disable any virus scanning software from blocking network traffic for a period of time?

Also, would you mind sharing what virus scanners you're currently running, in case we spot a trend?

> Also, isn't Chrome stable using QUIC? Any blockages would apply to the Stable version as well, no?

Yes, chrome stable typically uses QUIC too and so I would expect it to be subject to the same blocking. I'd love to see a net-internals from stable where things work just after a net-internals from canary when they didn't. Perhaps the virus scanner has some mechanism to not block "Google Chrome" which does not apply to "Google Chrome Canary".

Here's the net internals trace from stable.

As for virus scanner, I'm using McAffee and its details are:

-----------------------------------------------------------
System Information  
Computer Name: <redacted> 
   
McAfee Agent  
Version number: 4.8.0.1500 
Managed  
Last security update check: 8/29/2016 1:00:10 PM 
Last agent-to-server communication: 8/29/2016 1:10:53 PM 
Agent to Server Communication Interval (every): 1 hours 40 minutes 0 seconds 
Policy Enforcement Interval (every): 5 minutes 
Agent ID: <redacted> 
ePO Server/Agent Handler  
DNS Name: <redacted>
IP Address: <redacted>
Port Number: 443 
   
   
McAfee VirusScan Enterprise + AntiSpyware Enterprise  
Version number: 8.8.0 (8.8.0.1247) 
Build date: 1/16/2014 
   
Anti-virus License Type: licensed 
   
Scan engine version (32-bit): 5800.7501 
   
Scan engine version (64-bit): 5800.7501 
   
DAT version: 8271.0000 
DAT Created on: 8/28/2016 
   
Number of Signatures in extra.dat: 0 
Name of threats that extra.dat can detect: None  
Buffer Overflow and Access Protection DAT version: 659 
   
Installed Patches: 4 
   
Installed Modules:  
   
  
Copyright © 1995-2013 McAfee, Inc.  
All Rights Reserved.  
www.mcafee.com  
    
--------------------------------------

Deleted: net-internals-log (2).json 2.4 MB

net-internals-log (2).json 2.4 MB View Download

Wow. That is perplexing. The stable trace shows perfectly reasonable connectivity whereas the canary trace shows basically 100% loss after less than 1 second. I suspect Ian might be on the right track with the virus scanner.

A virus scanner definitely seems like a good thesis. Can you check if there is a policy whitelist for the scanner that includes "Google Chrome"?

https://community.mcafee.com/thread/50328?tstart=0 is a bit dated but suggests that you may be able to add Apps to the firewall whitelist policy. Can you add Chrome Canary to this list, and see if that fixes it?

I checked the logs and I don't see any mentions of QUIC or Chrome (of any sorts) in there. I also don't see a firewall neither do I see any rules that block any browsers/processes (let alone canary).

I don't see us using Security Center (as shown in the community thread) so that seems moot.

Anything else I should look for?

Just tried running with Virus scan disabled and no dice. Right now, the run as admin hack is working.

Thank you for providing more feedback. Adding requester "rch@chromium.org" for another review and adding "Needs-Review" label for tracking.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot