New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 797502 link

Starred by 2 users

Issue metadata

Status: Duplicate
Merged: issue 770201
Owner: ----
Closed: Jan 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug



Sign in to add a comment

Chrome networking takes a long time to start working when Hyper-V is enabled while Edge networking works right away

Reported by brian@briansmith.org, Dec 23 2017

Issue description

UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.84 Safari/537.36

Example URL:
Any web page

Steps to reproduce the problem:
1. Enable all Hyper-V features, e.g. `Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V -All` in an administrator Powershell prompt. (It isn't sufficient to enable only the Hyper-V hypervisor.)
2. Restart the computer.
3. Log in.
4. Start Chrome, and try to navigate to a web page. The page load will be stuck and may eventually fail. Chrome may ask you if you want to kill the tab(s) you started page loads in.
4. Start MS Edge. Notice that the Edge home page loads right away and all browsing in Edge works.
5. Go back to Chrome and observe that networking isn't working yet.
6. Wait a while, perhaps 30 seconds or so.
7. Try to navigate to a page in Chrome and notice it works just fine.
8. Reboot and verify the same behaviors occur.
7. Put the computer to sleep and wake it up and observe the same behaviors.
8. Disable all Hyper-V features, reboot, and verify that Chrome networking is working like normal.
9. Re-enable all Hyper-V features and reboot. Obvserve the bad behavior again.

What is the expected behavior?
networking works fine

What went wrong?
See above.

Did this work before? N/A 

Chrome version: 63.0.3239.84  Channel: stable
OS Version: 10.0
Flash Version: 

I have noticed this on a ThinkPad T440p and a ThinkPad T470p using Intel Wifi adapters. My current adapter in the T470p is an Intel Dual-Band Wireless-AC 8265. This is Windows 10 Professional build 1709 (Fall Creator's Update).

I noticed that if I enable only the Hyper-V hypervisor, but not other Hyper-V components, then things work fine. It's only when I enable some of the other Hyper-V components that I run into trouble. I suspect the problem is a bad interaction between Chrome the Hyper-V networking components, perhaps the one that implements the NAT. In Windows 10 Professional 1709 there's a default, cannot-be-disabled NAT device called "Default Switch." (After typing this, I had the idea to search for "Docker" in this issue tracker, since Docker for Windows has a "DockerNAT" device that it installs. See  issue 770201 .

Again, I want to emphasize that Chrome seems to think the tab process has hung and sometimes offers to kill it.

I have been using Hyper-V for a long time and I think that this is a regression. That is, I think that this used to work at the beginning of 2017 or so, and sometime this year this problem started. I have been working around this for a long time. My workaround is mostly to just wait a while until Chrome's networking starts working. I found that doing some browsing in Edge seems to speed up Chrome's fixing of itself.

Doing some more searching, I found this: https://productforums.google.com/d/msg/chrome/RkBRkxGtPQg/X3E8ZRZBBAAJ, which seems to match my experience. I do think it's possible that I only noticed this on my T440p when I upgraded to the Anniversary Update.
 
According a comment I left on Twitter in July, this was broken As of July 12th of this year. I remember at the time I left that comment I had been experiencing it for weeks, at least.
Labels: Needs-Triage-M63
Cc: mef@chromium.org vamshi.k...@techmahindra.com mmenke@chromium.org horo@chromium.org
Labels: Triaged-ET
As this issue seems to be related to  Issue 770201 , CC'ing mef@chromium.org, mmenke@chromium.org and horo@chromium.org and requesting to help in further triaging it.

Thanks!
I experience the same or similar problem. I have had "auto detect proxy settings" disabled for a while; I even have it disabled "completely" through the registry. I am not using McAfee ScriptScan. (Both of these interactions were mentioned in  issue 770201 .)

This is not specific to Wifi. Further I think I'm experiencing this issue frequently during web browsing and not just when waking from sleep or switching networks.
Also, if there's something I can actively due to help debug this, I'm happy to do so. It reproduces all the time on two different machines.
> Further I think I'm experiencing this issue frequently during web browsing and not just when waking from sleep or switching networks.

To expand on this, I feel like recently the problem has gotten even worse. Before I only noticed it when I would start browsing, but now I'm regularly experiencing the browser freezing in the middle of browsing.
I noticed something else: It seems like networking *does* work for a small amount of time when I wake up the laptop, and then stops working. For example, I just woke up my laptop and it happened to be on twitter.com. I saw a tweet that was just posted ~30 seconds prior. That means the networking must have worked in order for Chrome to fetch that tweet. But then no networking worked and even the twitter.com locked up and Chrome asked me to "exit page" (was "kill"!). And now a minute or two later, everything is working fine again!
Also, everything I described in the previous comment is regarding Chrome. In particular, when I said "no networking worked," I mean Chrome's networking. I was able to start MS Edge and it loaded its home page and I was able to browse in it just fine the whole time that Chrome's networking wasn't working.
Could any dev from the cc'ed list please have a look into the issue.

Thanks...!!
In the other thread, eroman asked for this:

> wmic nic get AdapterType, Name, Installed, Speed, PowerManagementSupported

AdapterType     Installed  Name                                      PowerManagementSupported  Speed
                TRUE       Microsoft Kernel Debug Network Adapter    FALSE
Ethernet 802.3  TRUE       Intel(R) Ethernet Connection (5) I219-V   FALSE                     9223372036854775807
Ethernet 802.3  TRUE       Intel(R) Dual Band Wireless-AC 8265       FALSE                     216000000
Ethernet 802.3  TRUE       Microsoft Wi-Fi Direct Virtual Adapter    FALSE                     9223372036854775807
                TRUE       Bluetooth Device (RFCOMM Protocol TDI)    FALSE
Ethernet 802.3  TRUE       Bluetooth Device (Personal Area Network)  FALSE                     3000000
                TRUE       Microsoft Teredo Tunneling Adapter        FALSE
                TRUE       WAN Miniport (SSTP)                       FALSE
                TRUE       WAN Miniport (IKEv2)                      FALSE
                TRUE       WAN Miniport (L2TP)                       FALSE
                TRUE       WAN Miniport (PPTP)                       FALSE
                TRUE       WAN Miniport (PPPOE)                      FALSE
Ethernet 802.3  TRUE       WAN Miniport (IP)                         FALSE
Ethernet 802.3  TRUE       WAN Miniport (IPv6)                       FALSE
Ethernet 802.3  TRUE       WAN Miniport (Network Monitor)            FALSE
                TRUE       Microsoft Wi-Fi Direct Virtual Adapter    FALSE
Ethernet 802.3  TRUE       Hyper-V Virtual Switch Extension Adapter  FALSE
Ethernet 802.3  TRUE       Hyper-V Virtual Ethernet Adapter          FALSE                     10000000000
                TRUE       Hyper-V Virtual Switch Extension Adapter  FALSE
Also, I have anti-virus real-time protection disabled. I've never installed any anti-virus on this computer, so Windows Defender is the only anti-virus that's ever been on this system.
Are you sure that auto-detect is disabled in Chrome? What does chrome://net-internals/#proxy show?

Since your symptoms are very similar to  issue 770201 , which sounds like an issue where our DHCP-based WPAD stalls either when enumerating or querying one of the virtual network adapters.

Some things to try:

* Does it reproduce if you disable docker's adapter, or any of the other virtual ones?

* Launch Chrome with some different configurations and see if it reproduces:

# Using a fresh profile and no proxy
chrome.exe --no-proxy-server --user-data-dir=C:\tmp-chrome-profile

# Using WPAD, but not DHCP-based WPAD
chrome.exe --proxy-pac-url="http://www.wpad.dat" --user-data-dir=C:\tmp-chrome-profile

# Using both DHCP and DNS based WPAD
chrome.exe --proxy-auto-detect --user-data-dir=C:\tmp-chrome-profile


You said this problem was a recent regression for you - does there seem to be a correlation to any Windows updates?

Is there a minimal set of instructions to get this reproducing on a fresh computer? I have some leads to try regarding Docker device, but simple instructions would be helpful for repro too.

Does this reproduce for you only on suspend/resume, or can you accomplish the same thing by switching networks, disabling then enabling adapters? How about in Edge if you change network and then immediately try loading a URL with a previously unseen hostname?

More debugging feedback would be to run chrome://tracing/ and capture a trace around the abnormality. If you can reproduce without suspending the machine that is best, since power events skew the times in traces.

Lastly, can you provide a log from chrome://net-export/. Specifically, please try loading a distinct URL"X" prior to the abnormality, and then "Y" afterwards (to make it easier to interpret the resulting long).

Cheers and thanks for the info.
> Are you sure that auto-detect is disabled in Chrome? What does chrome://net-internals/#proxy show?

No, now I am not sure. Do I need to change anything in Chrome, or is disabling auto-detect in Windows sufficient?

Here is what chrome://net-internals/#proxy shows:

Effective proxy settings
Use DIRECT connections.
Source: SYSTEM
Original proxy settings
Auto-detect
Source: SYSTEM

I have attached images of my Windows settings. I disabled the proxy auto config in Windows by manually setting the Start key to 4 under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WinHttpAutoProxySvc as recommended by https://googleprojectzero.blogspot.com/2017/12/.
chrome-proxy-detection-1.png
23.5 KB View Download
chrome-proxy-detection-2.png
71.7 KB View Download
>  You said this problem was a recent regression for you - does there seem to be a correlation to any Windows updates?

I explained this in Comment 1.

> Is there a minimal set of instructions to get this reproducing on a fresh computer?

I have the instructions in comment 1. 

> I have some leads to try regarding Docker device, but simple instructions would be helpful for repro too.

I suspect my instructions in comment 1 will be simpler since they don't require any third-party software.

> Does this reproduce for you only on suspend/resume, or can you accomplish the same thing by switching networks

I notice this mostly on suspend/resume. I cannot remember if it happens when switching networks. I rarely switch networks; more likely I suspend the laptop, move it to a new location that has a different network, and then resume. However the issue also happens if I just suspend/resume in the same location with the same network.

> , disabling then enabling adapters?

I've not tried that yet.

> How about in Edge if you change network and then immediately try loading a URL with a previously unseen hostname?

I haven't tried changing network adapters. As I mentioned in comment 1, I've always been able to browse around in Edge without issue while Chrome's networking is hung.
According to comment #13, Chrome is using auto-detect so this is a dupe of  issue 770201 . I will keep the bug open for now to simplify our discussion.

I am guessing that Edge is also using auto-detect, but you didn't realize it. Proxy settings on Windows are complicated. There is the possibility of per user settings, per machine settings (GPO), per-connection settings, overrides for security zone, 32-bit vs 64-bit registry variants, and winhttp vs wininet stores. And also winhttp's indirection to getting wininet settings.

The per-user settings dialogs you showed correspond with per-user wininet settings. If GPO overrode them, then they are ineffective, and don't display the effective proxy settings.

Chrome uses WinHttpGetIEProxyConfigForCurrentUser() to retrieve the proxy settings, which should generally match HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings. But it has given us problems in the past, so this could also be an instance where it diverges from the expected proxy settings.

You could try running dump_proxy.exe from https://bugs.chromium.org/p/chromium/issues/detail?id=12189#c54 if you want to contrast the proxy settings returned directly by wininet, vs winhttp's view of wininet settings. Otherwise the best way to tell whether Edge is actually doing proxy auto-detect is to remap the FQDN for wpad to a server on localhost and point it at your own PAC and see if that gets used.
> I am guessing that Edge is also using auto-detect, but you didn't realize it. 

I think it isn't using auto-detect because it uses the WinHttpAutoProxySvc service. The registry setting that the Project Zero blog post mentioned disables the WinHttpAutoProxySvc service so there's no proxy auto-configuration for Edge. However...

> The per-user settings dialogs you showed correspond with per-user wininet settings. If GPO overrode them, then they are ineffective, and don't display the effective proxy settings.

I think what's happening is that the Windows proxy settings UI is showing that the proxy auto-detect is disabled because it noticed that the service is disabled. This is consistent with MS Edge's behavior and with the thinking behind the Project Zero blog post.

> Chrome uses WinHttpGetIEProxyConfigForCurrentUser() to retrieve the proxy settings, which should generally match HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings. But it has given us problems in the past, so this could also be an instance where it diverges from the expected proxy settings.

My hypothesis is that WinHttpGetIEProxyConfigForCurrentUser() looks only at HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings and that it doesn't consider whether the WinHttpAutoProxySvc service is disabled.

I reverted the change to the service configuration for WinHttpAutoProxySvc that I made based on the Project Zero blog post and rebooted my machine. The Windows UI for proxy settings then showed that proxy auto-detect was enabled. Then I noticed that when I start Chrome the networking hang I experience does correspond to a "Downloading Proxy Settings" message at the bottom of the Chrome Window.

Then I used the Windows UI to disable the proxy auto-detect settings. Now Chrome's networking isn't hanging (at least, after a few iterations of leaving and joining my current Wifi network) and chrome://net-internals/#proxy now says:

Effective proxy settings
Use DIRECT connections.
Source: SYSTEM

Thus, I believe the Project Zero blog post needs to be clarified that, before one changes disables the WinHttpAutoProxySvc service using the registry key, one must also disable the proxy auto-detect in the Windows settings UI and that the Windows UI doesn't reflect what Chrome will do when WinHttpAutoProxySvc is disabled, since Chrome doesn't use the WinHttpAutoProxySvc service.
Components: -Internals>Network Internals>Network>Proxy
Over the last few days I've been running in the configuration I mentioned above: I disabled proxy auto-connect in Windows using Windows's UI for it, and then I disabled WinHttpAutoProxySvc as described in the Project Zero blog post I mentioned. Since then I've not experienced this problem. Thanks for your help!

One thing I want to mention: When this problem occurs, the renderer processes (at least) sometimes become unresponsive. That indicates to me that there might be an additional problem; I wouldn't expect well-engineered applications like GMail to be using synchronous XHR or anything else that would force Chrome to have the renderer block synchronously, so this might be worth looking into separately.
I haven't been able to reproduce using the instructions in comment #1.

Simply enabling Hyper-V did not create any adapters.

I don't know how to use Hyper-V, but I tried adding a virtual network switch using the hyper-v manager. This had the effect of adding two new adapters: "Hyper-V Virtual Switch Extension Adapter" and "Hyper-V Virtual Ethernet Adapter", however that also did not get me able to repro.

Do you have specific instructions on getting a setup for repro? (preferably for a machine with wired ethernet).

Can you provide a chrome://net-export/ and chrome://tracing/ dump of the problem? (see comment #12)

Thanks
I found before that disabling all Hyper-V features and then rebooting didn't erase every trace of Hyper-V adapters on my system. Thus, even though I tested the instructions in comment #1 myself after starting with Hyper-V features all disabled, I wasn't starting from a clean slate.

Assuming that you're using Windows 10 build 1709 (Fall Creator's Update), I suggest that you create a virtual machine in Hyper-V. Configure it to use the "Default Switch" adapter. Then start the virtual machine. (I've used Ubuntu 16.04 server, Windows 10 Professional, and minikube VMs recently, if you need something to actually run in a VM.)

As far as the chrome://net-export/ and chrome://tracing/ logs, I would like to share some, but it is too much effort to reboot 2, 3, or 4 times to get everything into the broken state and then back into the fixed state. Sorry.
FWIW, I regularly use wired and wifi Ethernet for this computer and IIRC it reproduced on both kinds of network. My IP4 and IPv6 is set up to always be DHCP and there's no WPAD anywhere on my networks.
Mergedinto: 770201
Status: Duplicate (was: Unconfirmed)

Sign in to add a comment