Graphical corruption when using VMware Workstation with 3D acceleration.

[Carlisle]

Hi, I performed several updates today and I ran into an issue involving graphical corruption when running Windows under VMware Workstation. I initially thought it was Workstation's problem, because that was one of the things I updated (to current release, 17.6.4, from 17.6.3), but it may be related to the Intel Xe's graphic drivers.

This is what I have assessed so far and some details:

• It is a Core i7 1255U laptop without dedicated graphics card, only the integrated Intel one.
• I am running Windows 10 Education, up to date, the guest is Windows 10 Pro (new install triggers it, so it seems unrelated to SW installed in the VM).
• The problem arises when 3D acceleration is enabled and VMware uses its Vulkan renderer, it doesn't seem to happen when the DirectX 12 one is used instead (mks.enableVulkanRenderer = "FALSE" in the VMX file).
• When it happens, the host Windows Event Viewer registers a 4101 event for the display stating: Display driver igfxn stopped responding and has successfully recovered.
  
• It happens with drivers .6881 and .6913 at least, the only known-good I know of so far is .6325, it was the one I was running before today's updates and except from going back to it to test, I haven't checked in-between those releases to see which one was the first to fail.

I would like to know what I would need to run to gather some debug data related to the graphics, or how to provide more details, or who to contact.

This is what I see:

I also left a video from earlier here; corruption can be seen around the 1:25 mark when that machine is booting while 3D acceleration was enabled: https://vimeo.com/1102260738

I found another thread from earlier this year that could be related: https://community.intel.com/t5/Graphics/Graphical-Image-Corruption-with-VMware-Workstation/m-p/1671194

[JedG_Intel]

Hello Carlisle,

Thank you for posting on Intel Community Forum.

It appears the problem may be linked to the Intel Xe integrated graphics drivers, particularly when using the Vulkan renderer with 3D acceleration enabled. Your observations, including the Event Viewer logs and driver version comparisons, are very helpful.

To address this effectively, kindly share the information below.

1. Have you tried rolling back to the .6325 driver version to confirm if the issue is resolved?

2. Does disabling 3D acceleration solve the issue?

3. Kindly share the Event Viewer logs.

Additionally, to have a better understanding of your system configuration and components please generate System Support Utility (SSU) report. Please follow instructions here and send the report - How to get the Intel® System Support Utility Logs on Windows*

I look forward to your response.

Best regards

Jed G.

Intel Customer Support Technician

[Carlisle]

Hi Jed, thank you for your reply. I downloaded all WHQL drivers I could find since the one that worked and did some more tests earlier.

.6458 is the last one to still have no artifacts/corruption, .6559 from February 04, 2025 was the first to show some problems. On VM power on, the VMware logo and Windows loading screens show the same patterns @Omegashel reported back then:

Artifacts on boot already

Pattern persisting when fully loaded

From the VMware renderer log all I could understand was that the .6559 driver implemented a Vulkan extension that .6458 didn't, VK_EXT_load_store_op_none; the rest seemed to be about the same.

.6647 and .6651 show the same patterns, but I believe it was .6734 (or .6737) from April when things improved a bit, boot VMware logo and Windows' loading screens were showing correctly, and corruption only appeared when the machine had fully booted (in this screenshot, .6737 were in use):

Desktop screenshot when fully booted

The only difference I could see comparing the renderer logs was another extension that had been implemented, VK_EXT_non_seamless_cube_map. The rest of the drivers I tried, .6790, .6784, .6881 and .6913 led to the same behavior, corruption appearing once the machine fully boots.

I didn't appreciate any problem when DirectX 12 was used as renderer with any of the drivers I tested, or when 3D acceleration isn't enabled, I checked with them all. Regarding your first question, yes, going back to one of the drivers that don't produce faulty visuals makes things work as expected when the Vulkan renderer is used, I went back to .6458 from .6913 to confirm.

As for the event logs, I cleared them between tests to isolate things, but I noticed the 4101 even wasn't always triggered, most of the time there was no indication of any problem in the logs at all. The data that event registers seems minimal as well, and it is always the same:

Event log detail

I attached an SSU log to this reply and I can provide any others or run more tests if needed.

By the way, when going back to the previous version of the drivers I realized there is a minor bug in the installer. It (or a component it uses) seems to depend on .NET 8, so the runtime for it is installed beforehand; but it doesn't take into account that a more recent version of the runtime may be already present in the system, it is installed unconditionally. For instance, the Desktop Runtime 8.0.10 may be installed even when 8.0.18, the current one, already is.

It doesn't influence anything, and I believe those runtimes would be serviced through Windows Update when new stable versions are released, but I thought it doesn't hurt to mention it.

[JedG_Intel]

Hello Carlisle,

Thank you very much for the detailed information you’ve shared. It’s truly appreciated and will be instrumental in helping us move forward with our investigation. I’ll be reviewing this matter thoroughly with the relevant teams. Please rest assured that I will get back to you as soon as I have an update or need further clarification

Best regards

Jed G.

Intel Customer Support Technician

[JedG_Intel]

Hello Carlisle,

I'm writing to inform you that we tried to recreate the issue but could not recreate it using the latest graphics driver: 32.0.101.6913 with VMWare 17.6.4.

To further troubleshoot the issue, please try to install the latest graphics driver 32.0.101.6972 and try it again with VMWare 17.6.4. Please also make sure to check the MD5 hash for VMWare and the ISO used by VMWare

If the same issue persists on your end, please let me know so we can further investigate.

Best regards

Jed G.

Intel Customer Support Technician

[Carlisle]

Hi Jed, thank you for everything.

I just tried the drivers you linked to, and the outcome is the same. I checked with a clean install of Windows 10 too (in the host, my laptop) just in case, I am going to see if the same happens on Windows 11 and report back. Is there any debug or trace mode that could be enabled for the drivers? Since you couldn't replicate it, I'll try to provide as many details as possible.

I have attached the logs I could get from the virtual machine execution to this post (mksSandbox.log is the one for the renderer), in case they are of any use. It is also entirely possible that the problem lies in Workstation's Vulkan renderer, and since I can still get 3D acceleration with the DX12 one, I am not too bothered by this; I am reporting it in case something is wrong. I'll try contacting Broadcom through their forums as well.

I find it odd that it happens consistently for me, with any driver past .6458, I wonder what the trigger is. The problem I see is the same @Omegashel had, but their machine was from a different OEM (Dell, mine is Acer) and had a slightly older CPU (11th gen, they had an i5 1135G7). Acer never published newer drivers for this machine, it'd be running 31.0.101.4032 from late 2022 regardless of bugs and vulnerabilities if it were up to them (there is at least 1 Intel advisory that applies and accompanying CVE-2024-21864).

PS. All versions of the software were latest, Windows was up to date, VMware Workstation was 17.6.4 and VMware Tools were updated to 13.0.1 (there were recent vulnerabilities in various drivers). Hyper-V was disabled in the host, so the hypervisor was VMware's.

[Carlisle]

A little update, the host being Windows 10 may be a requirement for it to fail.

A clean install of Windows 11 using the same set of drivers for the laptop made the VM boot without artifacts using the Vulkan renderer. I didn't test extensively; I am using the same VM to keep the rest of variables more or less stable, and I could power it on some 5 times without any video corruption (restarting the host in-between as well for good measure).

I was also able to reproduce it on another machine, it isn't nearly as powerful as the laptop, but it is all I have access to. It is a mini-PC with another Alder Lake CPU (N100), so I could use the same drivers for both. The results were consistent: if the host is Windows 10, the Vulkan renderer doesn't work as expected, but if the host is running Windows 11, I didn't appreciate any problem.

Both 10 and 11 clean installs were updated to the July cumulative updates prior to testing, and aside from the OS, drivers and whatever Store apps are bundled with them by default, only VMware Workstation 17.7.4 was installed.

[JedG_Intel]

Hello Carlisle,

I truly appreciate all the effort you’ve put in so far. The isolation work you’ve done is incredibly valuable and will significantly support our ongoing investigation.

We'll further troubleshoot the issue together and I'll give you another update as soon as it's available.

Thank you for your understanding.

Best regards

Jed G.

Intel Customer Support Technician

[kamild_]

This issue was not exclusive to Windows 10. I'm running Windows 11 24H2 and I was having this same exact problem on driver version 32.0.101.6651. Fortunately, updating the driver to version 32.0.101.6972 has solved this problem.

[Carlisle]

Oh! I could only reproduce it when the host is Windows 10, I didn't test as extensively on Windows 11, but I had no artifacts or corruption there; I don't recall if I tried .6651 on Windows 11.

[JedG_Intel]

Hello Carlisle,

After conducting extensive testing of the Iris Xe Graphics across multiple virtual operating systems, we were unable to replicate the issue as described. Based on the results, the graphics hardware appears to be functioning as expected under similar conditions.

We recommend verifying the integrity of the ISO files being used when creating an image with VMWare, as corrupted or incomplete images may lead to unexpected behavior. Alternatively, for further assistance and more targeted troubleshooting, we suggest reaching out directly to VMware Support.

With this in mid, I will now close this inquiry. If you have further questions or concerns, please submit a new question as this thread will no longer be monitored.

Best regards

Jed G.

Intel Customer Support Technician

[Carlisle]

Hello Jed, sorry for the delay getting back to you, I was away these last couple of days.

Even if the thread won't be monitored, I will write here for whatever good it may do, because I am able to reproduce it on my end and I don't need to do anything out of the ordinary, it is a shame you couldn't get it to happen over there.

I even tried again a few minutes ago starting from scratch with the mini PC because it was the one I could spare reinstalling. Images weren't corrupted, they were downloaded directly from Microsoft through MVS and hashes match. This time instead of the image for VMware Tools, I used the executable directly, but it was also properly signed and authenticated:

• Windows 10, consumer image, updated last month:
  • en-us_windows_10_consumer_editions_version_22h2_updated_july_2025_x64_dvd_f841fba5.iso
  • SHA1: f103f4b6d00fb961e514374e5bd9e7fec9bc7174 
  • SHA2-256: 4dfe862e97fe3b48a1bd6716ee54e9e01e029820c7d354d251720263c6bd2a98
• Windows 11, consumer image, also updated last month:
  • en-us_windows_11_consumer_editions_version_24h2_updated_july_2025_x64_dvd_a1f0681d.iso
  • SHA1: 94e6216cf311364441a7dd10b322327e92dd6cfe 
  • SHA2-256: d25dc407e6bf052c2a4702bd37b19d48b9aa109c9779230fe7ca61da4f9ffebc
• VMware Workstation:
  • VMware-Workstation-Full-17.6.4-24832109.exe
  • SHA1: 19403341df07a01497f507c02c53eaecad8127b7
  • SHA2-256: 10fe3a36f525d88aa133118ab3b5a16b18da88d4aa11b14d74e4164b3fb94ba9
• Visual C++ 2022 Redistributable:
  • VC_redist.x64.exe (14.44.35211.0, signed 11th June 2025).
  • SHA1: 21ce0ee54bff57f69fafa741025bf2f15b356405
  • SHA2-256: cc0ff0eb1dc3f5188ae6300faef32bf5beeba4bdd6e8e445a9184072096b713b
• VMware Tools:
  • VMware-tools-13.0.1-24843032-x64.exe
  • SHA1: 83e56f8723c6ceb810aa488e4b01c83073f01a8e
  • SHA2-256: 829953b6c92719dd32080a46d8fc1089f3b70cd96f954b20803d329aec63a74e

The procedure was as follows:

• I installed Windows 10 Education to a empty SSD installed in the mini PC, nothing else was there.
• It was connected to the Internet and allowed to install missing drivers and Windows' updates (yesterday's, .NET 4.8.1 and .NET cumulative update).
• Since the Intel graphics driver published for the mini PC through Windows Update is already a problematic one, 32.0.101.6737 from April, I didn't install the current release, I left it as it was.
• VMware workstation was installed and a new VM for Windows 11 was created, I used defaults for everything (2 our of the 4 N100 cores for it, 4 GB of RAM, 64GB disk, TPM, etc.).
• I disconnected the network by default for the VM, and installed Windows 11 Pro using the image I mentioned above.
• Since I was just testing, I opened a CMD and used "oobe\bypassnro" to be able to setup a local account.
• The tools installer was copied to the VM and launched, only the Salt Minion component was omitted in the installation.
• Just after the installation completes, the display gets corrupted.

If I lived stateside, I would ship you the mini PC with it all so you guys could experiment as much as you wanted. Since it only seems to happen when the Vulkan renderer is used, I suggest anyone in the same situation to just disable it and use the DX12 one instead.

Thanks anyway for the time you took to try to reproduce it and locate the problem, if anyone wants me to try a debug build of the drivers or something at some point, just let me know.