Issue metadata
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 descriptionUserAgent: 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.
,
Dec 25 2017
,
Dec 28 2017
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!
,
Jan 3 2018
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.
,
Jan 3 2018
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.
,
Jan 3 2018
> 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.
,
Jan 3 2018
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!
,
Jan 3 2018
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.
,
Jan 4 2018
Could any dev from the cc'ed list please have a look into the issue. Thanks...!!
,
Jan 4 2018
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
,
Jan 4 2018
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.
,
Jan 4 2018
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.
,
Jan 5 2018
> 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/.
,
Jan 5 2018
> 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.
,
Jan 5 2018
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.
,
Jan 6 2018
> 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.
,
Jan 9 2018
,
Jan 9 2018
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.
,
Jan 10 2018
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
,
Jan 10 2018
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.
,
Jan 10 2018
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.
,
Jan 10 2018
|
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by brian@briansmith.org
, Dec 23 2017