Last screenshot pointed me to Issue 768253.

Btw. Why all my comments get deleted immediately when posted?

Attaching again, as I don't know whether you see the files or not.

Deleted: trace_record1.json.gz.00 10.0 MB

trace_record1.json.gz.00 10.0 MB Download

Deleted: trace_record1.json.gz.01 10.0 MB

trace_record1.json.gz.01 10.0 MB Download

Deleted: trace_record1.json.gz.02 4.9 MB

trace_record1.json.gz.02 4.9 MB Download

Re-assemble steps: https://unix.stackexchange.com/a/1589/21471

Thank you for reporting, kenorb@gmail.com. This looks like a network stack issue to me.  Over to Network folks to confirm/triage.

This seems to be network issue requesting someone from the N/W team for help in further investigation and debugging of the logs attached

kenorb@gmail.com, Thanks for the report. 
I see "loading did not finished" in the attached screenshot of chrome://tracing.
To assist us in debugging, can you follow instructions at https://sites.google.com/a/chromium.org/dev/for-testers/providing-network-details to provide us a net-export log?

Thank you.

Hi there, I'm the affected user. I won't be able to run chrome://tracing as the problem appears right after starting Windows, when I start the Chrome. It freezes for some period of time and won't load any address (including chrome://net-export/). For some reason I was able to run chrome://tracing/ though.

I've managed to run chrome://net-export while typical chrome freeze after system start. Although I'm not sure if that recorded anything, but I've stopped recording after it unfreezed. Can anybody check it?

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

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

Things that struck me in the log:
1) Event 181, right at the beginning, has what looks like a sane HTTP2 session with Chrome sync, starting at t=5232 and proceeding normally. Some of the other stuff looks normal at first glance.

2) Sorting by duration (credit to Miriam for the idea), this looks a bit strange --- event 2027:

t=    0 [st=    0] +REQUEST_ALIVE  [dt=99155]
                    --> delegate_blocked_by = "MojoAsyncResourceHandler"
                    --> has_upload = false
                    --> is_pending = true
                    --> load_flags = 33024 (MAYBE_USER_GESTURE | VERIFY_EV_CERT)
                    --> load_state = 4 (WAITING_FOR_DELEGATE)
                    --> method = "GET"
                    --> status = "SUCCESS"
                    --> url = "http://www.google-analytics.com/analytics.js"
t=99151 [st=99151]   -DELEGATE_INFO
t=99151 [st=99151]   -URL_REQUEST_DELEGATE
t=99151 [st=99151]    URL_REQUEST_REDIRECTED
                      --> location = "https://www.google-analytics.com/analytics.js"

"Processing request" means we're stuck on something outside of the network stack, actually.  In this case, it's the renderer.

From the attached trace:

 1. V8.Execute blocks a renderer for more than 50 seconds (while not CPU busy).
 2. TaskQueueManager::RunTask blocks several renderers for more than 50 seconds (CPU busy).

V8 folks, can you take a look at the first case?

Any clue whats going on? I suppose 2. simply blocks us?

OK, here's what fixed it for me:

Control panel > Internet options > Connections tab > LAN settings > untick both options "automatically detect settings" and "use automatic configuration script".

That helped with chrome freezing on the start. I still have problem with facebook on chrome though, getting very laggy for some reason, but I guess this issue wouldn't be related to the initial one. Any ideas here would be much appreciated as well. I've tried standard things like unlogging all sessions, clearing cache, screening for any malware etc. but no success so far. It works fine on other browsers.

I am having the same issue if anyone wants to troubleshoot further.. Only solution I've found is to wipe the browser.. It will work for a few weeks (even with extensions enabled) and then start again. Unfortunately wiping the browser every few weeks is a lousy solution.

Looking at the uploaded traces I see that the very long v8.Execute slices are mostly descheduled, for example Facebook:

Wall Duration: 90625.269 ms
CPU Duration	  22.129 ms
Self Time      90548.149 ms
CPU Self Time	  20.423 ms

This hints towards V8 not being the culprit here as it doesn't consume any CPU cycles :)


However, there are other very large slices in the same range that are not descheduled, aka. *do* consume all the CPU:

Title:	        TaskQueueManager::RunTask
Category	renderer.scheduler
User Friendly Category:	other
Start:	        9,070.822 ms
Wall Duration:	93,915.119 ms
Self Time:	93,915.119 ms
Args:           queue ="default_tq"
Contexts:      Context = {type: "FrameBlameContext", snapshot: TopLevel }

Up to 32s there is also TileManager activity going on in the chrome.exe process (weirdly enough it seizes action completely after that)

Name					Wall Time	CPU Time	Self Time	CPU Self Time	#
MessageLoop::RunTask			1587.074 ms	1510.358 ms	593.298 ms	553.431 ms	26215
LayerTreeHostInProcess::UpdateLayers
  ::BuildPropertyTrees			 106.197 ms	 105.343 ms	106.197 ms	105.343 ms	 1059
PictureLayer::Update			 140.288 ms	 127.199 ms	 93.259 ms	 95.591 ms	 6359
TileManager::AssignGpuMemoryToTiles	  99.699 ms	  99.889 ms	 89.895 ms	 91.491 ms	 1889
LayerTreeHostImpl::CalculateRenderPasses  41.985 ms	  41.650 ms	 41.985 ms	 41.650 ms	 1058
PictureLayer::PushPropertiesTo		  37.067 ms	  35.989 ms	 37.067 ms	 35.988 ms	 4351