Unable to reproduce the issue on windows 7, Mac 10.12.6 using chrome version 60.0.3112.78 and canary 62.0.3171.0.
Able to use chrome after waking a PC from sleep without any issues.

Can you please try the issue on new profile without any extensions/flags and update the thread if the issue still persists.
try use of for complete cleanup
https://www.google.com/chrome/cleanup-tool/index.html

Thanks, 

I've not tested win 7. I'm using Win10.

Thank you for providing more feedback. Adding requester "kavvaru@chromium.org" to the cc list and removing "Needs-Feedback" label.

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

I've run the cleanup tool. Issue is still there.

Thanks for the report. Can you follow the instructions at http://dev.chromium.org/for-testers/providing-network-details to provide a net-internals log and the output of "ipconfig /all" ?

Done

Deleted: chrome-net-export-log.json 406 KB

chrome-net-export-log.json 406 KB View Download

Deleted: ipconfig-all.txt 4.1 KB

ipconfig-all.txt 4.1 KB View Download

Thank you for providing more feedback. Adding requester "xunjieli@chromium.org" to the cc list and removing "Needs-Feedback" label.

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

Thanks johnkors@. It seems that the net-export log was taken when Chrome was able to make network requests -- I don't see any hung/failing requests in the log.

Could you try enabling chrome://net-export before your PC goes to sleep and stopping it after waking it up your PC and when Chrome is able to work again (and that's ~1min later according to your original description)? 

Sure, here it is.

Deleted: chrome-net-export-log.json 3.2 MB

chrome-net-export-log.json 3.2 MB View Download

Thank you for providing more feedback. Adding requester "xunjieli@chromium.org" to the cc list and removing "Needs-Feedback" label.

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

@xunjieli-- Could you please check comment #12 and respond to it.

Thanks!

I didn't have time to dig deeper during my triage rotation. Leaving this open for network stack triagers.

johnkors@gmail.com : Is this something that you continue to see consistently in the latest release as well? If yes, do you see explicit errors when trying to load a page? Which error code does it show? Applying needs-feedback label for this.

From the net log, I see there are a lot of events starting from 105412 (network change to ethernet at 16:36:42.694) and 105593 (at 16:36:49.187) which I think is the first network based URL_REQUEST to be successful. This is still well under a minute though.

Keeping in the triager's queue if they find something else in the netlog that may be helpful.

I am seeing the same issue on Windows 7.
Chrome: Version 60.0.3112.90 (Official Build) (64-bit)

I have attached a log. The sequence of actions is:
- Initially, twitter is open in a tab, everything working fine.
- Start logging
- Put PC into Sleep
- Wake PC up
- Open a new window
- In the new window, navigate to Duolingo site using its thumbnail (at this point, the cached page appears and Chrome's loading indicator is spinning)
- Dismiss 3 (I think) "page unresponsive" prompts, selecting "Wait"
- Page eventually loads and unfreezes after a couple of minutes
- Stop logging.

Note also that if I attempt to close all the windows while it is in the unresponsive condition, Chrome fails to shut down properly (I get the message next time I start it up).

This problem happens for me very reliably. As with the original report, other browsers are not affected, and the problem only started happening a month or so ago.

I hope this is useful.

Deleted: chrome-net-export-log.json 3.1 MB

chrome-net-export-log.json 3.1 MB View Download

chris.white@: That netlog looks very different from the original bug reporter's, and I suspect it's a different bug. In your case, it looks like your navigations aren't making it to the net stack at all for about a minute, if I'm correctly understanding how the log maps to what you did. Can you file a new bug with the information you posted here?

In the netlog from #12, events 105659 (a URL_REQUEST) and 105663 (its associated HTTP_STREAM_JOB) are interesting. It looks like that request is the first navigation attempted, and it hangs for about two minutes on after PROXY_SERVICE_WAITING_FOR_INIT_PAC. The PROXY_SCRIPT_DECIDERs 105687, 105688, and 105689, and I can't see why they're taking so long. Note that these start slightly before the last of the NETWORK_CHANGED events.

Sending this to the proxy component.

(Duping based on data in comment #12)

I think I've narrowed this down to be caused by the GlobalProtect VPN client. Killing those in Task Manager, and Chrome responds immediately.