Windows XP/Vista and 7 emulation issue on VMware Worksation 25H2

[System 33]

Hello

Since 25h2, there have been major emulation problems with 3D acceleration on Windows XP and Vista, and

to a slightly smaller effect on Windows 7.

Each OS behaves differently with 3D acceleration.

Windows XP: Black screen after loading (system unusable).

Windows Vista: Disastrous performance (system almost unusable)

(Windows disables Aero because it detects that it is slow).

Windows 7: Lots of small graphics bugs and refresh issues, usually when you leave the cursor on an option and it highlights.

Disabling 3D acceleration solves the problem but creates performance issues on resource-intensive tasks as well as the loss of Aero.

If anyone has a solution to fix this bug, I'm interested.

And I hope that this will be fixed in the next version. :/

thanks

-------------------------------------------

[Shibdas Bandyopadhyay]

Can you please upload the logs (vmware.log and mksSandbox.log) and maybe video of the graphical corruption that you are seeing with 25H2

-------------------------------------------

[System 33]

Hello, Here what you requested.

Hope this help

-------------------------------------------

 Video

• 24dded56-9351-4ff7-8e42-0199fe9f8766_file

Attachment(s)

vmware - Vista.log   338 KB 1 version

mksSandbox - Vista.log   56 KB 1 version

vmware - XP.log   344 KB 1 version

mksSandbox - XP.log   56 KB 1 version

[Shibdas Bandyopadhyay]

Thanks for the videos and logs, we are actively looking at this. Can you please put this config option mks.enableVulkanPresentation=False and see at least some of the issue you mentioned goes away?

-------------------------------------------

[System 33]

Hello, 

I tried adding this line on VMX with fresh XP and Vista installations, but it had no effect.

Windows XP still produces a black screen, and Vista still runs very slowly with Aero. (All when 3D acceleration is enabled)

Thanks

-------------------------------------------

Attachment(s)

Windows Vista x64 Edition.vmx   3 KB 1 version

mksSandbox - XP No Vulkan.log   56 KB 1 version

vmware - vista No vulkan.log   341 KB 1 version

vmware - XP No vulkan.log   374 KB 1 version

Windows XP Professional.vmx   3 KB 1 version

mksSandbox - Vista No vulkan.log   56 KB 1 version

[Shibdas Bandyopadhyay]

That's what I expected.. One more experiment to try, do those VMs work well with last release 17.6.2?

-------------------------------------------

[System 33]

The black screen problem disappears with Windows XP on 17.6.2.
There are just the usual screen refresh bugs with this version of VMware.

However, it still lags a lot on Windows Vista.

The effects are the same with or without Vulkan.

-------------------------------------------

[System 33]

Windows XP no longer has a black screen in 17.6.2, just the usual screen refresh bugs found in these versions.

However, Vista still has the same performance issues in 17.6.2.

(Vista boots very slowly on 17.6.2, but this is seem to be fixed in 25h2.
The only remaining issue is performance with Aero.)

-------------------------------------------

Attachment(s)

Vista Log 17.6.2 No vulkan.zip   41 KB 1 version

Vista Log 17.6.2.zip   42 KB 1 version

Log XP 17.6.2 (No vulkan).zip   42 KB 1 version

Log XP 17.6.2.zip   40 KB 1 version

[Shibdas Bandyopadhyay]

We have added some config options for what it looks like to be screen refresh issue for 25H2 release but if you are seeing black screen 25H2 that does not matter yet. We have some guesses as to what might be causing this. Thanks for the logs, we are still trying to reproduce this reliably, some other asks will come your way if you are willing to try those out.

-------------------------------------------

[System 33]

Of course, I am open and ready to your questions and requests.

By the way,
here is my configuration, which I forgot to mention:
Intel Core I5 12450H
16GB DDR4 SODIMM
500GB NVME PHISON E19-512G
2 TB WD_Black SN770
GPU 0 = Intel UHD Graphics (driver up to date)
GPU 1 = Nvidia RTX 4060 (driver up to date)
Windows 10 (with free EU ESU)

-------------------------------------------

[kasper]

You are asking for the impossible.  XP, Vista, and 7 supporting 3d graphics on multiple hardware environmments?   All of these OS's are no longer supported by MS.   My guess is 3d graphics would work best with a SUPPORTED OS.   Why not just disable 3d graphics on these obsolete guests?  I refer you to 'Fast Times At Ridgemont High' about a distance on 'our time'.   Folks, if you are going to support seriously outdated software what you really need to do is make a 'freeze in time'.   Take an image of the host and guest when it is working.   And use that.   You have to realize you are DEGRADATING the newer software EXPECTING the old software to work.

-------------------------------------------

[System 33]

Virtual machines were designed to run both modern and legacy systems - that's one of their primary purposes.
Many users and companies still rely on VMware Workstation to maintain or support older systems for compatibility, testing, or archival reasons.
A Broadcom employee has already confirmed that this issue is legitimate by asking more info.
Disabling 3D graphics isn't a real solution - it's just a workaround, and I already mentioned that earlier.

-------------------------------------------

[RaSystemlord]

Do not know about the impossible in virtualization of old system, but @kasper has a point.

The freeze system would be non-costly workstation running Windows 11 and VMware 17.5.2 - I mean running anything on those old systems does not give any load on a modern hardware. From the writing here and elsewhere EVERYTHING works just fine with that version. I do not think there is any reason to have a newer version for it. By doing this, you could perhaps get rid of all the "domain computer non-sense" - I mean, you are not browsing through the interwebs using vista and xp and the rest - on the contrary, you are probably running some old-fashioned software that couldn't care less about the connection to internet.

Well, there may be different requirements and lots of variations from that ... but just for the discussion that @kasper started.

[System 33]

Hello

I understand your point of view: 
Kasper sent me a private message after that, 
Here is my response, which I am making public

"Thank you for your suggestions, but your proposal raises several major issues in my situation:

Security Risks and Obsolescence: Sticking to an obsolete version of Workstation would mean ignoring security vulnerabilities, which would put my host operating system at risk.

Impact on Modern Systems: Rolling back to an older Workstation version would likely degrade the performance of my modern virtual machines (recent Windows 10/11, Linux), as they rely on the optimizations of the newer releases.

Conflicts and Stability: Installing and maintaining two major versions of VMware on the computer is not recommended and risks creating driver conflicts and instability.

Nature of the Issue: The current problem is most likely related to the recent transition to the Vulkan API in Workstation 25H2, which has introduced bugs affecting various systems, both old and modern.. For instance, 3D acceleration performance on Windows 7 has been significantly improved with 25H2 despite the minor graphical glitches, proving that older systems have not been completely abandoned by the dev and can get better. 

3D Acceleration: 3D acceleration is essential, and disabling it is simply a workaround that significantly degrades the performance of these OSes, even for basic tasks.

I didn't like the accusatory tone at the end of the message on the discussion thread. Even the AI I use to translate messages detected it. 

VMware has always been retro compatible without any major problems. The bugs I've noticed seem to be completely unintentional. Otherwise, the employees would have ignored my request, but no, they asked me for a video.
This proves that they have no intention of leaving emulation defects on older systems.

A company can use VMware solutions to emulate older systems.
My former company used it for obscure CNC transfer software from the XP era.
The software uses 3D visualization that only worked with 3D acceleration.

You could tell me about older versions, but as I said in my reply to the private message, it's a security risk. 
The CNC software uses the internal network to transfer the program. If a malicious program infects the XP VM due to its vulnerabilities, it will remain in the VM, but with an older version of VMware, it could exploit a vulnerability and exit the VM and move to the host.

-------------------------------------------

[RaSystemlord]

Thanks for the clarifications System 33. They are helpful.

After all, this is a discussion Forum where misunderstandings are more than possible. I'm all for the discussion, as long as it is civil. I don't care too much about the tonality, because that is culture dependent - I'm more for what has actually been said.

You seem to have a valid case of wishing new versions to work properly. As a customer, you are more than entitled to demand that, too.

My take on this is more to give some ways to go round the problem, which I don't think hit the mark in all accounts, and also let know of my experiences on that matter - as I said this IS a discussion Forum. Here is some more:

I checked my old XP and Win 7 environments and they work just fine with 17.5.2 and Win 11 Pro 24H2. Obviously, with brand new hardware (Intel Ultra Core 9), much quicker than ever before. The first one did not have 3D acceleration selectable the latter one did. I have not Upgraded the VMware version for a very long time - no need. I don't have a Vista client, because I used Vista as a Host at XP times. XP was really bad for that purpose with 32-bit, but Vista 64-bit SP 1 rather good. It was short lived, because we moved to Linux as a main Host, which had been 64-bit for a long time. Interoperability with Windows worked just fine with VMware (external disk with NTFS and all that).

As I said, you seem to have a case to worry about security - that is never wrong these days. My take on that is (main was) slightly different - putting all the eggs in the same basket was just wrong. We had separate technical systems, which were not in corporate network. Also, we didn't think about doing any kind of team virtualization with workstation-class software - we had other systems for that kind of work. Nowadays, corporate virtualization is never relying on workstation-class software, but rather VMware Horizon (or Citrix) - those have all the security gadgets in the world.

When workstation virtualization is used by people who actually know what they are doing, I don't have any worries here. I mean worries with not-the-very-latest-vmware versus using the-latest-with-lots-of-other-problems. If something vulnerable needs to be done, well, we have Linux for that - on a workstation-level of things Windows can be put aside - ultimately, use Puppy Linux from a read-only boot. On a corporate level - obviously not on the client, but there Windows is not used as a Host anyway - VMware Horizon nor Citrix are no Windows systems.

Well, just for the discussion - with your latest posts, I think you have (almost) all figured out already.

[System 33]

"Haha, I admit I tend to get carried away when I feel like someone is looking down on me, but it passes quite quickly.

I am open to serious and respectful debate on this kind of subject; there is a lot to discuss and learn.

In my former company, they used an old XP machine for the CNC software, but it broke down, so they had it run directly on VMware Workstation on PCs in the design office.

This wasn't a situation that required professional software; Workstation was sufficient just for one XP VM.

The idea of Linux wasn't bad, but it would have required a dedicated PC for the XP VM, as the other PCs all needed Windows because of the CAD software.

But anyway, the company went bankrupt before that (major flooding)."  ¯\_(ツ)_/¯

-------------------------------------------

[Michael Banack]

For the WinXP issue, I have two things you could try:

1) In the .vmx file, try changing these two settings (or adding them if there's no existing entry):

svga.autodetect = FALSE

svga.vramSize = 134217728

That might reduce your maximum allowed resolution, but might fix the issue.

2) If that doesn't work, in the .vmx file, lower the virtualHW.version to "10" .  

That might lose some virtual hardware or 3D features, but might also work-around the issue.

-------------------------------------------

[System 33]

Solution 1 (svga.autodetect = FALSE, svga.vramSize = 134217728) :

The image speaks for itself, haha.
The VM is blocked at a single resolution, the color is only 4-bit, but at least I don't have a black screen.

Solution 2 (virtualHW.version to "10") :

I didn't get a black screen and the system is usable.
Probably due to the settings, each refresh on the screen takes a little time to refresh in a mosaic pattern.         

Thanks, that's already better than a black screen.

-------------------------------------------

 Video

• 108bce4b-5aa0-43cc-984d-019a0dc3725c_file

[Shibdas Bandyopadhyay]

For the mosaic pattern problem please use mks.vk.syncPerEndFrame=TRUE if you have vulkan presentation running (i.e. you don't have mks.enableVulkanPresentation=FALSE in the config file). If you have similar 'screen refresh' issues that you mentioned for other VMs please use that config option there too or put it in global/user config.

I think we now know what might be going wrong. I have a similar laptop as yours and after trying out few VMs I was able to hit it.

-------------------------------------------

[System 33]

Thanks, the mosaic effect seems to have disappeared.
That's a good XP workaround for the moment.

I'm now going to try Michael Banack's method too.

-------------------------------------------

[Michael Banack]

For the WinXP issue, we've determined the problem is that we're exposing a higher maximum texture size on your GPU than our WinXP driver is prepared to handle.

So if you want to put the other settings back, you should be able to avoid this issue with just this .vmx line:

featMask.vm.svga.maxTextureSize="Max:16384"

-------------------------------------------

[System 33]

Adding your line 

featMask.vm.svga.maxTextureSize="Max:16384"

in .vmx has resolved the issue with Windows XP displaying a black screen on the last compatibility setting !
There were screen refresh issues, but adding

mks.vk.syncPerEndFrame=TRUE

 provided by Shibdas Bandyopadhyay solved them !

It must be since 15.x.x that I haven't had a Windows XP VM run so smoothly on VMware Workstation. :)

---

I tried adding 

 mks.vk.syncPerEndFrame=TRUE 

 to the Windows 7 VM that was having graphics issues, and it seems to have solved the refresh problems, making the Windows 7 VM much smoother !

I think that the source of the 25H2 issues has now been found with regard to Windows XP and Windows 7 !

---

But there is still one capricious one that continues to struggle enormously with Aero or tasks requiring GPU power: Windows Vista :/

I remain available for your requests and thank you for Windows XP and 7.

-------------------------------------------

[System 33]

I found a suitable solution for Windows Vista.

I downgraded the VMware tool version from 11.0.6 to 10.3.5.

I remembered that version 11.x.x always had problems on Vista.
(For example, the performance index does not run and remains frozen, and certain text does not appear in programs, for example in integrated games),
while 10.3.5 is the latest version that does not have these problems.

And then added the line :

mks.vk.syncPerEndFrame=TRUE

After all that, my Vista VM runs more smoothly and no longer slows down to the point where Aero is automatically disabled.
I hardly ever get refresh bugs anymore.
Performance isn't as good on my Windows 7 VM, but it's much better than before.

-------------------------------------------

[Shibdas Bandyopadhyay]

Yeah, the vista issue is something else and our QE can't reproduce it yet. I explained the difference between the presentation and renderer in a a different thread here https://community.broadcom.com/vmware-cloud-foundation/discussion/25h2-unrecoverable-error-svga-on-start-of-a-win11-guest-on-a-win10-host-1752-is-ok but you can turn off vulkan renderer by using mks.enableVulkanRenderer=False and check if that changes anything (mks.enableVulkanPresentation=False only turns off the presentation but we will still continue to use vulkan for rendering).

-------------------------------------------

[System 33]

Thanks for the workarounds. For now, my Vista VM remains stable with the settings I set above, which suits me better than an unusable VM.

-------------------------------------------

[Fred.S]

I just updated my i5 laptop to 25H2 so I'm posting this because I can say it works OK.
My other computer will be updated in a few days but they all share the same code block in their VMX for XP:

# 3D
mks.enable3d = "TRUE"
# If 3D acceleration cannot be enabled, or you get a warning
# this may allow access to 3d drivers
mks.gl.allowBlacklistedDrivers = "TRUE"
# This switches the 3D acceleration from the default DX11 to OpenGL.
mks.enableDX11Renderer = "FALSE"
mks.enableGLRenderer = "TRUE"
## Vulkan Renderer is a device independent API that should work with all GPU,
## either does not work or isn't implemented 
mks.enableVulkanRenderer = "FALSE"

-------------------------------------------

[RaSystemlord]

Yes, I was telling about my old XP and Win 7 VMs working just fine.

Now it feels that it verified that there is (almost) nothing wrong with the current software, in this regard - just that the settings in the file have gone wrong.

The interesting part is that have the settings gone wrong at SOME upgrade of the VM version? Or have they been manually changed at some point? Or does a newly made VM, or not-so-newly-made VM, write or has written wrong settings. Anyway, at the times when XP and Win7 were new, the settings were right for them.

Well, perhaps interesting, but there is probably nothing to be done for that matter. You just need to be aware of this possibility.

[Shibdas Bandyopadhyay]

Couple of things

1. We don't use GLRenderer anymore with 25H2 so all gl settings like allowblacklistedDrivers, enableGLRenderer does not have any effect.
2. Vulkan renderer is the preferable way to run things, we are actively testing and developing on it, DX12 Renderer is pretty much unchanged and DX11Renderer is long frozen. 

-------------------------------------------

[System 33]

I noticed that on Windows 7 VMs (less so on Vista). When you resize certain windows such as Windows Media Player with Aero, it destroys graphics performance and saturates the video memory, which automatically disables Aero if you persist.

Also, if a program requires 3D or, for example, a video playback with an external slide animation, it destroys performance.

-------------------------------------------

[Shibdas Bandyopadhyay]

Can you post the logs and a video? What is the graphics memory setting for the VM, VM->settings->display->graphics memory and what happens if you increase it?

-------------------------------------------

[System 33]

Here is the requested information.

(I haven't figured out how to change the language in VMware Workstation, but I hope this helps.)

-------------------------------------------

 Video

• 238d5f0e-ef44-4f50-b9f6-019a8e7c2cda_file

Attachment(s)

Windows 7 x64.vmx   4 KB 1 version

mksSandbox.log   57 KB 1 version

vmware.log   355 KB 1 version

[Fengzi Lao]

Hello Michael,

After adding the code featMask.vm.svga.maxTextureSize="Max:16384" to my new installed XP virtual machine's vmx file and installing VMTools, I encountered a display problem.

Specifically, XP seems to only display 640x400 part in the top left corner; no matter how high I increase the XP resolution, the rest of the screen remains completely black.

This problem appears to occur randomly. After several cycles of shutting down and turning the virtual machine on and off, the screen sometimes returns to normal and sometimes it does not.

I'm using VMware 25H2, and I haven't added any other code to the vmx file besides this one.

Regardless, I'm very grateful for your willingness to do some work for people using XP virtual machines in VMware. The display errors in VMware have been around for several years, and they are most noticeable on XP and Vista guest. However, considering that large customers who typically use VMware are likely not very concerned about graphics performance, I didn't have high hopes that these issues would be alleviated.

-------------------------------------------

[Michael Banack]

If you take a screenshot when it's like that, do you see the whole screen contents on the screenshot?  Or just the upper 640x400 portion?

That sounds like you're hitting an issue with your Host graphics driver drawing into our window, rather than a problem on the WinXP side.

You could try setting these options to fallback to GDI for drawing, at a slight performance cost:

mks.enableGDIPresentation=TRUE
mks.enableDXGIPresentation=FALSE
mks.enableVulkanPresentation=FALSE
mks.enableDX12Presentation=FALSE

Although I would recommend taking them out when you upgrade to the next version of Workstation if they're no longer needed.

-------------------------------------------

[kasper]

Here maybe a good example of where a short term fix to the VMX file fails.   Here is where an AI response fix fails.   It maybe the Author only wants a short term fix.   It maybe the applications can now only run in a certain hardware / software environment.   In that case virtualization may be a solution but you need to realize the implications in regards to new hardware, new software, and TIME.   I do not know the specifics.   What I do know is if you are hardware/OS/application bound, you want to consider FREEZING your environment.   And if you decide to freeze your environment you want to focus more on security and how to lock that down.  PS.  Please keep in mind that Workstation is A TYPE 2 HYPERVISOR.   That has all sorts of implications in regards to this issue.   Do the DD.

-------------------------------------------

[System 33]

I have already explained all my arguments for maintaining the minimum operation of legacy systems on the latest versions of VMWare.

"Here is a good example of where a short-term fix to the VMX file fails."
I don't understand your statement, since it was a default setting issue with Vulkan and the problem was solved by adapting the settings to the standard for these systems.

These options are not related to XP and 7, but to the VMware emulation itself.
An engine transition breaks things, and it's true that the chances are higher on an older system.

But it just goes to show that correcting the two bad default parameters is enough to make XP or 7 run even more smoothly than before.

With a smaller development team than before, this is much more likely to happen. Proof of this is that the version before 25h2 had the same refresh problem on Windows 10 and 11 and was fixed in 25h2.

Also, I don't understand what AI has to do with this.

-------------------------------------------

[Mykhailo Bunakov]

Thank you System 33 and other users who have raised and resolved the issue of running legacy operating systems on VMware!!!

-------------------------------------------

[Yagami]

Thats happens here too ¬¬

------------------------------
月を見る度思い出せ...
------------------------------

[aqua95]

Hello. Glad to see a thread like this being created and actually being looked at by employees.

I've been experimenting with Windows Vista for quite a few years now. The performance issue on Windows Vista guests has been a problem ever since VMware 16.0. What happens is that dwm.exe is leaking memory, and even if you disable aero, i mean general usability is probably fine but graphically intensive apps run very poorly (0-1 fps). There are 2 ways to get the issue fixed, in which both of them are limiting:

1. Change the VM compatibility to VMware 15.x if you want to keep using VMware Tools 11.0.6. This will fix performance issues and preserve DirectX 10/10.1 compatibility (best deal as of right now, but we're still lacking DirectX 11)
2. If you for some reason want to keep using the VM in latest VMware hardware compatibility, then you will have to downgrade VMware Tools to 10.3.10. This will fix the issue, but it will limit you to DirectX 9.

While i was experimenting with Vista back in the day, i found that the vmware graphics driver found in VMware Tools 11.2.6 files (which you can get by doing setup.exe /A on a supported guest OS) still has support for Vista, and it also supports DirectX 11. It may be unintentional, but it's there nonetheless. And with that discovery, let's go back to the main problem:

None of these solutions will provide DirectX 11 on Vista. If you want to have DirectX 11, you have to use VMware 16.x or later comatibility, therefore breaking performance. Using VMware 15.x compatibility will limit you to DirectX 10 despite having the DirectX 11 compatible graphics driver, and downgrading to VMware tools 10.3.10 (well in this case the vm3d driver from this version of vmware tools) will limit you to DirectX 9.

I know Vista has been unsupported since VMware 16, but like why leave it in such a bad note? And it's not a bad os like people think. Plus, DirectX 11 support for Vista has been brought officially by Microsoft with platform update (kb971512). So, why this issue?

-------------------------------------------