ChromeDriver showing Lost UI Shared Context

Question

I have a Windows 10 laptop running a Windows 7 Virtual Machine. Inside the Virtual Machine, when i start the WebDriver, it gives the error gpu_process_transport_factory.cc<1009> Lost UI shared context when it is started:

IWebDriver driver = new ChromeDriver() //This causes the 1009 Error

Also then varies for Failed to query stereo recording and Failed to send GpuChannelMsg_CreateCommandBuffer and command_buffer_proxy_impll.cc<115> Shared memory handle is not valid.

This has been working for months and no changes were made (this WebDriver is the sole purpose of the Virtual Machine), the laptop running it is running fine (ie. no GPU problems). The WebDriver still navigates through pages, but giving further errors and 10x slower.

EDIT: Updated to ChromeDriver to 2.35 and still the same behavior.

Answer 1

This appears to be an issue with the latest version of Chrome (65.0.3325.146). By rolling back to an earlier version of Chrome (64.0.3282.186) the issue disappeared for me.

Will investigate further and update here if I find any more info but as a temporary workaround you can uninstall chrome and install version 64.0.3282.186.

Answer 2

Headless Chrome was shipped in Chrome 59 by Google Team which introduced a way to run the Chrome Browser in a Headless Environment.

A note was added as :

Headless mode has been available on Mac and Linux since Chrome 59. Windows support came in Chrome 60.

The article Getting Started with Headless Chrome mentioned that :

--disable-gpu \                # Temporarily needed if running on Windows.

A note was added as :

Right now, you'll also want to include the --disable-gpu flag if you're running on Windows.

As per the discussion Headless: make --disable-gpu flag unnecessary it was clear that :

The --disable-gpu flag is no longer necessary on Linux or Mac OSX. It will also become unnecessary on Windows as soon as the bug SwiftShader fails an assert on Windows in headless mode is fixed.

What happened under the hood?

As per the discussion headless: Switch from osmesa to SwiftShader as Google/Chromium team decided to ship SwiftShader with Chrome, the team thought to start using it to render GL content in Headless Mode. This required a couple of changes as follows :

• Skip GPU data collection in Headless Mode since SwiftShader isn't considered a software implementation by that code which lead to a failure when we tried to retrieve information from the Window System.
• Only skip GL initialization in InitializeStaticEGLInternal if we intend to use osmesa. SwiftShader requires initialization like the other non-software implementations.
• SwiftShader is currently not supported on Mac OSX, so the team decided to continue to use the physical GPU in Headless Mode on that platform (unlike on other platforms where everything is software rendered).
• So, to disable WebGL support in Headless Mode they decided to use --disable-gpu and --disable-software-rasterizer

The idea to Support WebGL in headless is still under discussion but SwiftShader fails an assert on Windows in headless mode with an error as :

[0117/125830.649194:ERROR:gpu_process_transport_factory.cc(1043)] Lost UI shared context.
DevTools listening on ws://127.0.0.1:37429/devtools/browser/1f0b2bf7-dfdd-44ac-9da7-f2659d352f0d

Conclusion

This error doesn't impact your @Test and you can ignore the error for the time being.