P.S. So even log from internals is stuck when downloading. When quitting Chrome, it asks whether I should stop all the downloads. I assume these are logs from net-internals.

Attaching another log file from net internals.

Deleted: E6F5.tmp 306 KB

E6F5.tmp 306 KB Download

Don't think this is a network issue - network issues don't result in unresponsive pages / UI.  They just result in spinning with blank pages, or slow loading but responsive pages.  Or pages that fail to load.

Most network requests aren't insanely slow in that log, though some are:  There are some requests which may well be deliberately hanging gets for chat channels ("hipchat", "client-s.gateway.messenger.live.com").  Also two requests for your PAC, an extensions request really stand out as being slow, which indicate some sort of disk access issue.

I assume about:tracing is too unresponsive to get a capture?

Do you have any extensions loaded? Any idea why you are reporting this against 52? 53 has been stable for a few weeks now.

I've Google Apps and similar Google related. Also Websense Endpoint which potentially may cause some issues, since it's installed by admin for monitoring purposes. The Extensions page is just 'Loading...', so I cannot even check which extensions are loaded. What I know the network is using own certificate chains via Blue Coat, so every non-encrypted requests are automatically encrypted on top of it by transparent proxies. But the same is happening with https. Even after restart, the pages are loading (page is visible), but loading is never finished.

I'm reporting this against 53.0.2785.116 m (64-bit). The updates may be controlled by sys-admins as well.

Deleted: chrome-650575.png 13.6 KB

	chrome-650575.png 13.6 KB View Download

The about:tracing page doesn't load as well, it's showing just spinning animation on the blank page, then page becomes unresponsive (killing and refresh doesn't help). This was working few days back. The chrome://settings/ works without problem.

If you think it's not a bug, and this could be related to some restrictive techniques by admins, I could contact my IT support to solve this issue. Which won't really explain why most of the sites are stuck. But this could be due to some weird extensions, or I may not use the right VPN or something.

The status bar sometimes shows Waiting for cache..., it's sometimes saying 'Establishing secure connection...' even the page seems to be loaded, but it's still spinning for the long time. This seems to work in Firefox and Brave browser. 

If you open an incognito window (ctrl-shift-n), does it display the same issues?  What if you launch with a new profile directory (--user-data-dir="<path>".  Be sure to delete the folder when you're done with it)

The disk access could be related that my HOME var is on external network drive (which is usually mounted correctly), so I had to override for the terminal to my real HOME (C:\Users\username). But even I had this drive connected, it didn't solve the issue.

Incognito doesn't show extension buttons and the same is happening. This is what is on the screenshot, and nothing is changed for the next >5mins and so. 

Deleted: Chrome-650575-incognito.png 14.8 KB

	Chrome-650575-incognito.png 14.8 KB View Download

Was your configuration working before?  When did things break?

The external network drive thing makes me think something weird may be happening there, could be some change that's virtually transparent on a more common configuration is running into some issue there.

Running it in different user-data-dir seems to solve the issue, all is loaded fine, e.g.

"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --user-data-dir=C:\Temp

and I can see all the extensions now (none of them are allowed in incognito). Some of them (apart of Google related): Chrome Connectivity Diagnostics, Cisco WebEx Extension, Legacy Browser Support, Websense Endpoint.

The one which wasn't working, the command was: "C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --profile-directory="Profile 1"

You could try temporarily moving everything out of the default profile path (Which chrome isn't running), and see if things work when you restart Chrome.  That would tell us if the issue is the directory location, or profile data + the location.  If it's the latter, you could copy everything from the default profile path to C:\Temp, and see if using that as a data directory works fine, which would tell us if it's just bad profile data that's the issue.

Did test with new profile with fresh and old files, e.g.

"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --user-data-dir=/C/Users/username/Documents/Chrome --profile-directory="Profile 1"

It worked fine. Sometimes Chrome didn't want to finish its process (even after closing), so I had to kill it using Procexp (the whole trees).

This is because when I was copying files, I had to make sure all chrome instances are killed, otherwise some files weren't accessible (like Current Session files). Then retested my old Profile 1 and it magically worked as well, which could suggest maybe some other chrome processes were blocking something (which won't explain that it also happened after restart). My 'Profile 1' had 0.5G cache files. All the profile data weren't on any network drive (C:\Users\username\AppData\Local\Google\Chrome\User Data\Profile 1).

Currently I cannot reproduce either way, so I'll keep update if this will happen again.

Thanks for your help.

Hrm...Very weird.  I'll close the issue for now, but if it reappears in the next month or so, please comment here again, and I'll reopen it.  If it reappears after that, you're best off filing a new issue, to make sure someone sees it.