VMware Communities
0WayneH0
Hot Shot
Hot Shot
Jump to solution

VMware Workstation unrecoverable error: (svga)

One of the good things with Workstation, historically speaking, has been the 3D support. Lately, however, I have noticed significant slow down (recently upgraded to Workstation 12.5.7 from 11.1.x, which may have something to do with it) and so wondered whether upgrading the VM hardware from v10 to v12 would help. Unfortunately, however, it seems not to work at all.

My host is Win 8.1 (x64), with a nVidia Quadro K2100M.

In a Windows 7 x64 guest, when I run an application that uses OpenGL, I get an error that looks like:

VMware Workstation unrecoverable error: (svga)

Exception 0xc0000005 (access violation) has occured.

In a Windows 10 x64 guest, when I run the same application, I get this:

VMware Workstation unrecoverable error: (svga)

-- DETECTED D3D11 DEVICE REMOVAL --

Going back to hardware v10 seems to avoid the problem, but the performance is pretty poor, to the point of becoming unusable in certain circumstances.

I have tried updating the drivers for the Quadro card, multiple times, and it did not help. My hope was that maybe Windows 10 would work better (guest) than Windows 7, but it seems not.

Any quick tips or thoughts? What are other people's experiences with the 3D support in 12.5.7?

1 Solution

Accepted Solutions
bluefirestorm
Champion
Champion
Jump to solution

Check/verify that the SVGA 3D driver for the Windows guest VMs are version 8.15.1.50 (or higher from the latest VMware Tools) and hardware compatibility set to 12.

By default VMware workstation will use DX11 to provide DX10/OpenGL 3.3 features for the Windows VMs with hardware compatibility 12, assuming there are no manual edits to the vmx configuration files. The OpenGL 3.3 support within the guest is for the core profile so some OpenGL extensions/capabilities may not be available. It will also use the first graphic adapter that it sees. So if the system has multiple graphic adapters such as Intel integrated and discrete graphics from Nvidia/AMD, it will just create a DX11 render device that it sees unless it is overridden in the vmx configuration file.

Option 1: Ensure that Nvidia is the DX11 render device by selecting Nvidia as the default graphics processor in the Nvidia Control Panel since it appears you have a laptop with the Quadro K2100M graphics or add/edit these lines to the vmx configuration file.

mks.enableDX11Renderer = "TRUE"

mks.enableD3DRenderer = "FALSE"

mks.dx11.vendorID = "0x10de"

So if you have multiple graphics adapters, you would want to see in the vmware.log file the "Successfully created a device" line after it finds the Nvidia Quadro K2100M card.

| mks| I125: MKS-RenderMain: RenderMain: PowerOn allowed DX11Renderer MKSBasicOps

| mks| I125: MKS-RenderMain: Collecting RenderOps caps from DX11Renderer

| mks| W115: DX11Renderer: Enumerating adapter 0

| mks| W115: DX11Renderer: `Intel(R) HD Graphics 530` vendor=0x8086 device=0x191b revision=6

| mks| W115: DX11Renderer: video=128MB system=0MB shared=8123MB

| mks| W115: DX11Renderer: Enumerating adapter 1

| mks| W115: DX11Renderer: `NVIDIA GeForce GTX 960M` vendor=0x10de device=0x139b revision=162

| mks| W115: DX11Renderer: video=4065MB system=0MB shared=8123MB

| mks| W115: DX11Renderer: Successfully created a device

| mks| W115: DX11Renderer: Enumerating adapter 2

| mks| W115: DX11Renderer: `Microsoft Basic Render Driver` vendor=0x1414 device=0x008c revision=0

| mks| W115: DX11Renderer: video=0MB system=0MB shared=8123MB

Option 2: Switch to OpenGL 4.0 instead of DX11 for VMware Workstation by having these lines in the vmx configuration since Quadro K2100M can support OpenGL 4.5

mks.enableGLRenderer = "TRUE"

mks.enableDX11Renderer = "FALSE"

mks.enableD3DRenderer = "FALSE"

I only switched over a few days ago. But comparing the 243 SVGA 3D capabilities in the log file when using DX11 vs OpenGL 4.0; it looks that the Windows guest VM will have better graphics capabilities (for example 32 vertex texture shaders vs 16 in DX11). But the OpenGL option doesn't work well at all with the Intel HD530, even the Windows 10 logon screen and menus are not rendered properly.

So if you successfully switch to OpenGL as the render engine for the guest VM you should see something like this in the vmware.log file.

| mks| I125: GLHostWin32: : Created context with GL 2.1, core: 0, robust: 0

| mks| I125: GLHostWin32: : Created context with GL 4.0, core: 0, robust: 1

| mks| I125: OpenGL Version: "4.5.0 NVIDIA 382.05" (4.5.0)

| mks| I125: GLSL Version: "4.50 NVIDIA" (4.50.0)

| mks| I125: OpenGL Vendor: "NVIDIA Corporation"

| mks| I125: OpenGL Renderer: "GeForce GTX 960M/PCIe/SSE2"

View solution in original post

3 Replies
bluefirestorm
Champion
Champion
Jump to solution

Check/verify that the SVGA 3D driver for the Windows guest VMs are version 8.15.1.50 (or higher from the latest VMware Tools) and hardware compatibility set to 12.

By default VMware workstation will use DX11 to provide DX10/OpenGL 3.3 features for the Windows VMs with hardware compatibility 12, assuming there are no manual edits to the vmx configuration files. The OpenGL 3.3 support within the guest is for the core profile so some OpenGL extensions/capabilities may not be available. It will also use the first graphic adapter that it sees. So if the system has multiple graphic adapters such as Intel integrated and discrete graphics from Nvidia/AMD, it will just create a DX11 render device that it sees unless it is overridden in the vmx configuration file.

Option 1: Ensure that Nvidia is the DX11 render device by selecting Nvidia as the default graphics processor in the Nvidia Control Panel since it appears you have a laptop with the Quadro K2100M graphics or add/edit these lines to the vmx configuration file.

mks.enableDX11Renderer = "TRUE"

mks.enableD3DRenderer = "FALSE"

mks.dx11.vendorID = "0x10de"

So if you have multiple graphics adapters, you would want to see in the vmware.log file the "Successfully created a device" line after it finds the Nvidia Quadro K2100M card.

| mks| I125: MKS-RenderMain: RenderMain: PowerOn allowed DX11Renderer MKSBasicOps

| mks| I125: MKS-RenderMain: Collecting RenderOps caps from DX11Renderer

| mks| W115: DX11Renderer: Enumerating adapter 0

| mks| W115: DX11Renderer: `Intel(R) HD Graphics 530` vendor=0x8086 device=0x191b revision=6

| mks| W115: DX11Renderer: video=128MB system=0MB shared=8123MB

| mks| W115: DX11Renderer: Enumerating adapter 1

| mks| W115: DX11Renderer: `NVIDIA GeForce GTX 960M` vendor=0x10de device=0x139b revision=162

| mks| W115: DX11Renderer: video=4065MB system=0MB shared=8123MB

| mks| W115: DX11Renderer: Successfully created a device

| mks| W115: DX11Renderer: Enumerating adapter 2

| mks| W115: DX11Renderer: `Microsoft Basic Render Driver` vendor=0x1414 device=0x008c revision=0

| mks| W115: DX11Renderer: video=0MB system=0MB shared=8123MB

Option 2: Switch to OpenGL 4.0 instead of DX11 for VMware Workstation by having these lines in the vmx configuration since Quadro K2100M can support OpenGL 4.5

mks.enableGLRenderer = "TRUE"

mks.enableDX11Renderer = "FALSE"

mks.enableD3DRenderer = "FALSE"

I only switched over a few days ago. But comparing the 243 SVGA 3D capabilities in the log file when using DX11 vs OpenGL 4.0; it looks that the Windows guest VM will have better graphics capabilities (for example 32 vertex texture shaders vs 16 in DX11). But the OpenGL option doesn't work well at all with the Intel HD530, even the Windows 10 logon screen and menus are not rendered properly.

So if you successfully switch to OpenGL as the render engine for the guest VM you should see something like this in the vmware.log file.

| mks| I125: GLHostWin32: : Created context with GL 2.1, core: 0, robust: 0

| mks| I125: GLHostWin32: : Created context with GL 4.0, core: 0, robust: 1

| mks| I125: OpenGL Version: "4.5.0 NVIDIA 382.05" (4.5.0)

| mks| I125: GLSL Version: "4.50 NVIDIA" (4.50.0)

| mks| I125: OpenGL Vendor: "NVIDIA Corporation"

| mks| I125: OpenGL Renderer: "GeForce GTX 960M/PCIe/SSE2"

0WayneH0
Hot Shot
Hot Shot
Jump to solution

Firstly, thanks a million for such a helpful reply.

You are right that my system has two video cards, and the default graphics card is not the nVidia card; it's an Intel HD 4600.I have been using the nVidia Control Panel to associate the nVidia Quadro card with the vmware-vmx.exe process and to that end, specifying the hardware vendor in the *.vmx did not help, since it seems that part of things was already working correctly.

I spent quite a bit of time investigating the effects of using the options you suggested and ran a series of tests using both the Intel HD 4600 and nVidia Quadro cards and also using Workstation hardware v10 and v12. To reduce the number of combinations of settings I stuck to testing using a Windows 7 x64 guest.

The executive summary of said tests is that your option #2 (mks.enableGLRenderer = "TRUE") was the most successful. I still encounter some issues with it (detailed below) and the performance is still pretty ordinary (not a huge amount better than running with software rendering alone), but it is WAY better than the performance I was seeing with 3D enabled and HW v10 and also avoids the crash when using HW v12. So for both of these things I am really thankful. (Oh, and since I didn't mention it, my SVGA 3D driver was up to date in all guests).

In case you are interested in the full details, also for any other interested reader, these are the main tests that I performed (I have left out tests that went off the beaten track or don't add any significant value to this response), with notable differences in input and outcome highlighted.

The constants in this set of tests are:

Guest: Windows 7 x64

SVGA 3D Driver: 8.15.1.50

Host: Win 8.1 x64 with Intel HD 4600 and nVidia Quadro K2100M

Workstation version: 12.5.7

Test#1

HW10 (hardware version 10)

mks.enable3d = "FALSE"

(all other mks entries removed)

No nVidia GPU activity (recorded by host)

Display in OpenGL app looks good, which is contrary to what I have been used to in the past (using 3D rendering generally results in some rendering issues). Performance is slow, but usable. Better performance than the experience that lead me to post the original post.

Test#2

HW10

mks.enable3d = "TRUE"

(all other mks entries removed)

Host records activity on the nVidia GPU

Display in OpenGL app is characteristic of problems with 3D rendering in a VM. Certain presentation features do not work properly. Performance is back to very poor (worse than software rendering). This is the problem that I was running into and that which prompted me to try HW v12 as a potential solution. I do not recall Workstation 11.1.x having such poor 3D performance.

Test#3

HW12

mks.enable3d = "TRUE"

(all other entries removed)

Host records activity on the nVidia GPU

Application crashes as per original post. VMware Workstation unrecoverable error: (svga) -- DETECTED D3D11 DEVICE REMOVAL --

    nVidia display driver crashes (and recovers) on host.

This is the problem that prompted the original post.

Test#4

HW12 (repeat test, but using different OpenGL application start up approach** that avoids the crash)

mks.enable3d = "TRUE"

(all other entries removed)

Host records activity on the nVidia GPU

Display in OpenGL app is characteristic of problems with 3D rendering in a VM. Certain presentation features do not work properly. Performance is worse than with HW10. It's unusable.

** (In testing different things I found that a particular set of steps when running the OpenGL application could avoid the crash when using HW v12).

Test#5

HW12 (using Intel HD 4600)

mks.enable3d = "TRUE"

mks.enableGLBasicRenderer = "FALSE"     (added since I was tinkering with this setting at one point; ensured that it's disabled).

mks.enableGLRenderer = "TRUE"

mks.enableDX11Renderer = "FALSE"

mks.enableD3DRenderer = "FALSE"

Host records no activity on the nVidia GPU.

Application openGL pane draws completely black.

Application possesses other graphical artefacts (e.g., in WPF UI).

Log file contains:

2017-08-21T14:04:41.440+09:30| mks| I125: GLHostWin32: : Created context with GL 2.1, core: 0, robust: 0

2017-08-21T14:04:41.456+09:30| mks| I125: GLHostWin32: : Created context with GL 4.0, core: 0, robust: 1

2017-08-21T14:04:41.456+09:30| mks| I125: OpenGL Version: "4.0.0 - Build 10.18.14.4414" (4.0.0)

2017-08-21T14:04:41.456+09:30| mks| I125: GLSL Version: "4.00 - Build 10.18.14.4414" (4.0.0)

2017-08-21T14:04:41.456+09:30| mks| I125: OpenGL Vendor: "Intel"

2017-08-21T14:04:41.456+09:30| mks| I125: OpenGL Renderer: "Intel(R) HD Graphics 4600"

     ...later the log file fills up with this line over and over

2017-08-21T14:05:52.058+09:30| svga| W115: GLShader: No vertex shader bound.

If I repeat the above test (say test 5a), but use the same work around (different application start up process) that avoids the crash when not using the GLRenderer, the application does draw correctly. Performance is better, but still significantly well below that when compared to running directly on the host.

Test#6

HW12 (using nVidia)

mks.enable3d = "TRUE"

mks.enableGLBasicRenderer = "FALSE"

mks.enableGLRenderer = "TRUE"

mks.enableDX11Renderer = "FALSE"

mks.enableD3DRenderer = "FALSE"

Host records activity on the nVidia GPU.

Application draws completely black.

Vmware log contains:

2017-08-21T13:51:14.431+09:30| mks| I125: GLHostWin32: : Created context with GL 2.1, core: 0, robust: 0

2017-08-21T13:51:14.465+09:30| mks| I125: GLHostWin32: : Created context with GL 4.0, core: 0, robust: 1

2017-08-21T13:51:14.465+09:30| mks| I125: OpenGL Version: "4.5.0 NVIDIA 382.05" (4.5.0)

2017-08-21T13:51:14.465+09:30| mks| I125: GLSL Version: "4.50 NVIDIA" (4.50.0)

2017-08-21T13:51:14.465+09:30| mks| I125: OpenGL Vendor: "NVIDIA Corporation"

2017-08-21T13:51:14.465+09:30| mks| I125: OpenGL Renderer: "Quadro K2100M/PCIe/SSE2"

     ...later the log file fills up with this line over and over

2017-08-21T13:53:00.567+09:30| svga| W115: GLShader: No vertex shader bound.

If I repeat the above test (say test 6a), but use the same work around (different application start up process) that avoids the crash when not using the GLRenderer, the application does draw correctly. Performance is better again (best of all tests), but still significantly well below that when compared to running directly on the host. This restores the performance to something like I remember it used to be on previous Workstation versions (though I admit that I can only provide anecdotal evidence on that without going back to Workstation 1.11.x and doing more tests, which is something I really don't want to do for now).

Using the configuration from Test6 (and the OpenGL application work around), this is becomes workable, since the crash no longer occurs and the performance is restored to something usable. If I forget to apply the steps to get the OpenGL app to draw correctly it's just a few mouse clicks without even needing to close the application to rectify this. So, for me this is a good enough work around and gets me trucking once again!

Finally, I tried these "best" settings using a Windows 10 guest and get very similar results with the exception that I notice some graphical artefacts in some additional portions of the application that I am testing. These are only minor issues, but a noticeable difference between Windows 7 and Windows 10.

Reply
0 Kudos
bluefirestorm
Champion
Champion
Jump to solution

I don't see the GLShader: No vertex shader bound. in the log file. Maybe it's simply I am not pushing the graphics capabilities as much as you do inside the guest VM.

There is a slightly more friendly version of the host OpenGL graphics capabilities in the log file that looks like this.

| mks| I125: GLManager: Shader Version 4.00 supported

| mks| I125: GLManager: Host supports 16x multisampling.

<another bunch of lines>

| mks| I125: GLManager: Host supports 32 vertex texture units, 32 fragment texture units, 32 geometry texture units and 192 combined texture units.

That is much friendlier than the section which lists the 243 capabilities

SVGA3dCaps: host, at power on

cap[ 63]: 0x00000020 (MAX_VERTEX_SHADER_TEXTURES) ---> this would be the 32 vertex shader textures

There is also a section for the guest VM with the corresponding 243 capabilities

I125: SVGA3dCaps: guest, compatibility level: No-Clamping

Comparing the 243 capabilities between using DX11 and OpenGL4.0  in the log file, it looks as though using OpenGL is better. I don't think the guest VM would be able to support MSAA if DX11 was the render engine. But I can only guess that VMware uses DX11 by default for Workstation on Windows as not all graphic adapters will deliver pleasant results (the HD 530 that I have is a case in point); aside from the fact some graphic adapters can support DX11 although not necessarily OpenGL 4.x.

Reply
0 Kudos