New issue
Advanced search Search tips

Issue 818068 link

Starred by 2 users
Status: Duplicate
Merged: issue 770201
Owner: ----
Closed: Mar 2018
Cc:
csharrison@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug


Participants' hotlists:
Hotlist-1


Sign in to add a comment

Chrome is unresponsive after waking from sleep

Reported by m...@deliberto.net, Mar 2 2018 
UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.167 Safari/537.36

Example URL:
ANy

Steps to reproduce the problem:
1. Use chrome
2. Put computer to sleep
3. Wake computer up and chrome is unresponsive for 2-3 minutes. 

What is the expected behavior?
Upon waking the computer from sleep mode chrome starts working.

What went wrong?
When I use chrome after waking my PC from sleep the network component appears to not be working. Clicking links on existing pages are unresponsive. Opening a new tab and attempting to search or resolve URL just stalls for a period of time then fails.

During this when chrome is "waking up" I can ping resources without issue. NSlookup resolves hostnames.

I have tried enabling\disabling the adapters (no effect on chrome waking).

Closing and opening the browser resolves the issue.

Did this work before? N/A 

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

I am going to capture the do the network detail capture as requested after submitting this bug. During this I will time how long it takes for chrome to "wake". I will also see if I can get anything interesting out of procmon. This has been an annoyance for me for some time (multiple versions of chrome). Please let me know how I can help figure out what is going on.

Comment 1 by m...@deliberto.net, Mar 2 2018 

Issue definitely happened again after waking from sleep mode. From login to chrome working it was approximately 2 minutes 5 seconds. First thing I did after waking the machine was press the start collecting button on a net export tab I had open. The tab became somewhat unresponsive after doing that. The logs are attached.

I already had a proc mon window open, filtering for chrome.exe, cleared prior to sleep. Nothing too unusual. There was a burst of TCP activity, then pretty normal stuff. I can provide those logs if needed.

My computer is running Windows 10 enterprise, not joined to a domain. No GPOs or anything too non-standard. I am willing to help dig into this, let me know how I can help.
chrome-net-export-log.json
552 KB View Download

Comment 2 by susan.boorgula@chromium.org, Mar 2 2018

Labels: Needs-Triage-M64

Comment 3 by csharrison@chromium.org, Mar 6 2018

Labels: Needs-Feedback
Hey Mike, this looks very similar to  issue 770201 . I wonder if you can try the mitigation steps listed there [1]. If any of those work, we can probably dupe the issue.

 (a) Disable proxy auto-detect (recommended)
 (b) Instead of proxy auto-detect, configure your settings to the explicit PAC script "http://wpad". This accomplishes the same thing as proxy auto detect in most environments (it only differs if the environment only supports DHCP-based WPAD)
 (c) Run chrome with the command line flag --proxy-resolver-winhttp

[1]: https://bugs.chromium.org/p/chromium/issues/detail?id=770201#c61

Comment 4 by mmenke@chromium.org, Mar 14 2018 

Mike:  Could you please respond to comment #3?  If not, we can't make forward progress, and will have to close the issue.

Comment 5 by m...@deliberto.net, Mar 15 2018 

As someone that works in IT I feel like a complete idiot for not thinking to check my proxy settings.

Unchecking the Automatically detect settings checkbox in the Internet Options | Connections | LAN Settings resolved this issue for me.

Thank you for the direction, it was a big help!

Best,
Mike D
Project Member

Comment 6 by sheriffbot@chromium.org, Mar 15 2018

Cc: csharrison@chromium.org
Labels: -Needs-Feedback
Thank you for providing more feedback. Adding the requester to the cc list.

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

Comment 7 by csharrison@chromium.org, Mar 15 2018

Mergedinto: 770201
Status: Duplicate (was: Unconfirmed)
Thanks Mike,
Let's dupe this into 770201, since it seems like it's probably the same root cause.
►

Sign in to add a comment