Maybe addressed by too many tabs?

Has TE tried reproducing this? I'm curious to know what extensions are running or if the same behavior happens with 1-10 tabs instead of 100. We haven't seen any significant loading or memory regressions, so it's odd that this would have changed in M61. IIUC, session restore with 100 tabs has always been a bad time.

On the contrary I have always had a solid experience restoring sessions with many tabs in Chrome as long as RAM is sufficient.

To me this looks like a resource deadlock or similar. I have disabled all extensions by ticking off all boxes in the Chrome "Extensions" page. When starting Chrome initially CPU and/or network will be saturated, but after a while they will both back off but pages are still not showing content. This state can endure overnight if I do nothing.

Also, the fact that internal pages like Settings or Help>About will also not load, even though the computer is not saturated in any respect, points to some kind of deadlock.

By fiddling with "Pages Unresponsive" dialogs I can get Chrome to suddenly wake up and finish loading pages.
Interestingly, I just discovered that opening the Chrome Task Manager will wake up the active page (and often all other pages) every time.

I might look into making a screen recording but need to find and install some software first.

I've made a screen recording where you can see what the problem looks like:
https://youtu.be/dpCKuN14czQ

Comments at selected points of time in the video:

0:05 
The screen recorder software causes 50% cpu load which hides the real cpu usage a bit. Assume that total cpu usage of 50-80% means idle/background usage and 99% means saturation.

0:20
Cpu saturated, network a bit up and down

2:40
Cpu load has come down a bit (screen recorder disturbs the real figure) and network is fairly silent. Note that the two visible tabs have finished loading but show no content.

2:50
Note that Settings will not load and no other tabs load either.

3:35
Popping the Chrome Task Manager will wake up the "bugs" tab once the Task Manager finsihed loading.

4:35
After the "wake up" Chrome works with higher cpu for a while, sometimes this means more tabs are waking up.

5:13
I try popping Chrome Task manager on Settings page before cpu has come down, doesn't give an effect the first time.

6:19
The second time I pop Chrome Task Manager all the tabs wake up, including Settings.

7:00
As can be seen, all Extensions are disabled.

We are making some small changes to session restore to make loading stagger more smoothly. Specifically, we are changing the definition of "page has finished loading" so that pages get more time to load.

Similarly, we are adding a notion of "visibility" so only tabs that are actually currently visible on the screen will be given priority to load initially. Right now the foreground tab of any window will be given priority, as we don't currently have occlusion detection.

The changes we are making are in progress, and not yet enabled so shouldn't be causing any problems. If this behaviour has suddenly changed, I'd suspect something else.

From your video it looks like you have *many* Chrome windows each containing a single tab. Session restore is known to be quite resource hungry and janky in that particular use case with the existing logic, but should get better soon.

It's 30 windows with a total of 120 tabs. I'm not making the point whether this is a use case you should support or not, but merely pointing out that support for this use case went through a dramatic regression in an update in mid-October. Before the update the session restored quickly and without hickups, and after the update the exact same set of tabs was almost impossible to get to a loaded state. 

I didn't watch what version I was coming from before the update so I'm just guessing it was Chrome 61 as it happened in mid-October and I am on the stable channel.

I'm a developer myself so if you have some things I could try out or monitor that might help you, please let me know. Do you f ex have any procedure for going back to an earlier version of Chrome so I can verify the difference with the existing profile?

Unfortunately, profiles can't be ported backwards between versions.

Typically the easiest way to find a regression is to use the bisect-builds tool and custom builds of the software with a local checkout.  I'll look for a local repro.

I've tried out 
python bisect-builds.py -a win64 -g 474897 -b 499098 --verify-range --use-local-cache -p c:\dev\chromebug\userdata -- --no-first-run
but have mixed progress.
(according to omahaproxy and testing from Chrome 60)
I notice that it is not the exact good version tried first but rather 474901. I guess that may be normal though.

I let the profile be created, set "restore tabs" behaviour, and then I add my "big" Session/Tabs files to the Default directory, and run again.

Chromium starts and pops all windows/tabs but there is zero network activity in all the versions I've tried so far. Tabs spinning, 25% cpu and 0% network.
Am I missing something in the setup?

Also, when exiting Chromium the py script says "Unexpected result at a range boundary! Your range is not correct.".

There is a warning about missing Google API keys but I guess that may also be expected?

I can also mention another "new" behaviour that may be related since the update; when coming out of standby Chrome will hang on 100% cpu for an extended time (several minutes) before becoming responsive. During this time it will consume a lot of memory and with my 100+ tabs its RAM usage will go from 6 GB to 14 GB. Once Chrome becomes responsive again cpu and memory usage will drop to normal.

Is this still occuring?

One of the updates not long after my last comment in November 2017 seemed to address the problem described in the first post. Chrome now goes at full CPU or full network until the session is loaded and I no longer see abandoned blank/not-loaded pages or Unresponsive dialogs.

An observation is that it looks like the behaviour how Chrome distributes CPU and network load has changed somewhat (network traffic is more chopped up and CPU is usually at full throttle during the whole restore) but that is of course no problem and could also have other explanations.