ChromeDriver显示丢失的UI共享上下文
我有一台运行Windows 7虚拟机的Windows 10笔记本电脑。 在虚拟机内部，当我启动WebDriver时，它在启动时给出错误gpu_process_transport_factory.cc 丢失的UI共享上下文 ：
IWebDriver driver = new ChromeDriver() //This causes the 1009 Error 
然后因查询立体声录音 失败而无法发送GpuChannelMsg_CreateCommandBuffer 和 command_buffer_proxy_impll.cc 共享内存句柄无效 。
这已经工作了几个月并且没有进行任何更改 （此WebDriver是虚拟机的唯一目的），运行它的笔记本电脑运行正常（即没有GPU问题）。 WebDriver仍会浏览页面，但会产生更多错误并且速度会慢10倍。
编辑 ：更新到ChromeDriver到2.35仍然是相同的行为。
无头Chrome由谷歌团队在Chrome 59中发布，它引入了一种在无头环境中运行Chrome浏览器的方法。
添加了一条注释：
Headless mode has been available on Mac and Linux since Chrome 59. Windows support came in Chrome 60.
“ Getting Started with Headless Chrome ”一文提到：
--disable-gpu \ # Temporarily needed if running on Windows.
添加了一条注释：
现在，如果你在Windows上运行，你还需要包含
--disable-gpu标志。
根据讨论Headless: make --disable-gpu flag unnecessary ，很明显：
Linux或Mac OSX上不再需要
--disable-gpu标志。 一旦错误SwiftShader fails an assert on Windows in headless mode被修复，它也将在Windows上变得不必要。
引擎盖下发生了什么？
根据讨论的headless: Switch from osmesa to SwiftShader当谷歌/ Chromium团队决定与Chrome headless: Switch from osmesa to SwiftShader ， headless: Switch from osmesa to SwiftShader ，团队认为开始使用它来在无头模式下渲染GL内容 。 这需要进行以下几项更改：
- 在无头模式下跳过GPU数据收集，因为SwiftShader不被该代码视为软件实现，当我们尝试从Window系统检索信息时导致失败。
- 如果我们打算使用osmesa，则只跳过InitializeStaticEGLInternal中的 GL初始化 。 SwiftShader需要像其他非软件实现一样进行初始化。
- Mac OSX目前不支持SwiftShader ，因此该团队决定继续在该平台上使用无头模式的物理GPU （与其他所有软件都呈现的平台不同）。
- 因此，要在无头模式下禁用WebGL支持，他们决定使用–disable-gpu和–disable-software-rasterizer
Support WebGL in headless的想法仍在讨论中，但是SwiftShader fails an assert on Windows in headless mode一个错误，如下所示：
[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
结论
此错误不会影响您的@Test ，您可以暂时忽略该错误。
这似乎是最新版Chrome（65.0.3325.146）的问题。 通过回滚到早期版本的Chrome（64.0.3282.186），问题就消失了。
如果我找到更多信息，将进一步调查并在此更新，但作为临时解决方法，您可以卸载chrome并安装版本64.0.3282.186。