ERROR:browser_process_sub_thread.cc(221)] Waited 57 ms for network service with Selenium ChromeDriver and Chrome on Windows

Question

So we use Selenium in C# to control Chrome. The following problem has occurred both in Chrome v74 with the v74 chromedriver and in Chrome v75 (the beta) with the v75 chromedriver.

After about 12 interactions with the website we get an error, for example

[10084:5660:0601/111205.119:ERROR:browser_process_sub_thread.cc(221)] Waited 57 ms for network service

We're not in a position to edit browser_process_sub_thread.cc and recompile.

I have searched for help on this issue and it is being discussed elsewhere. However, nothing much seems to be happening as the v75 beta breaks with the same issue.

How do we get around this problem? It only appears on this set of tests and not on others.

LATER

Now I'm getting this kind of message, viz

ERROR:browser_process_sub_thread.cc(217)] Waited 285 ms for network service

immediately rather than after some interactions! What's happening?

Answer 1

This error message...

ERROR:browser_process_sub_thread.cc(217)] Waited 771 ms for network service

...is coming from the IOThreadCleanUp() method within the browser_process_sub_thread.cc file which is implemented as:

// Record time spent for the method call.
base::TimeDelta network_wait_time = base::TimeTicks::Now() - start_time;
UMA_HISTOGRAM_TIMES("NetworkService.ShutdownTime", network_wait_time);
LOG(ERROR) << "Waited " << network_wait_time.InMilliseconds()
           << " ms for network service";

---

As per the discussion in Chromium Servicification - Need better handling for when a core service process fails to start/initialize following the new Network Process (NP) [--enable-features=NetworkService] if a child process is spawned but the service startup fails, in those cases:

• google-chrome browser UI remains visible and open.
• As the service is restartable, it appears an infinite loop of attempted child respawns is happening under the hood, which consumes more system resources.
• The visible browser does not appropriately shutdown due to critical failure and just sits there with no networking under the hood.

So a strategy was necessary for all the core services those needed by Chrome to have running, possibly a failure path for the Network Processes (NP).

---

Following the above mentioned requirement, as per the discussion Sandbox the network service on Windows Chrome introduced the new sandbox (SANDBOX_NETWORK_TYPE) for the new Network Process (NP).

Windows is the first platform to roll out of both the new features and you are one of the luckiest user to have the first hand user experience of:

• Feature to enable for network service: NetworkService

  --enable-features=NetworkService
  

• Feature to enable for the windows sandbox on the network service: NetworkServiceWindowsSandbox

  --enable-features=NetworkServiceWindowsSandbox
  

This revision and this commit with in sandbox_win.cc from @WillHarris when lands up will address this issue.