![](https://i.imgur.com/9UQ54uc.gif"){kind=small}
Hello friends. Last year, VMware released Version 17 of Workstation. I installed it right away, but encountered a major issue afterwards.
There seems to be no problem on systems using UEFI like Windows 10 and 11. However, on virtual machines using Legacy BIOS like Windows 7 and XP, I can hardly even see the BIOS screen. I struggle to even access BIOS. By selecting the "Power On to Firmware" option to enter the machine's BIOS, the BIOS interface then becomes extremely slow.
This doesn't usually pose a problem for operating systems that support VESA BIOS Extensions like Windows XP, 7, and 8.1. However, when I tried to install Windows 2000 earlier, I struggled greatly due to this issue. Since Windows 2000 lacks VBE support, the installation interface operates at 640x480 resolution and 4-bit color depth. When I reached the Windows 2000 installation interface, it was so slow that even the mouse was practically unusable. Additionally, the system reset twice due to another issue during the installation process. Therefore, I decided to postpone the installation for now.
My system consists of an AMD Ryzen 5 3600 processor, MSI B450 Tomahawk MAX motherboard, and MSI GTX 1660 Super Gaming X graphics card. I am using Windows 11 Pro 22H2 64-Bit as the operating system.
Many sources suggest checking the vmware.log file for "Monitor Mode: ULM" indicating an issue caused by an open Hyper-V. However, in my case, the log shows "Monitor Mode: CPL0," meaning Hyper-V is completely disabled. Therefore, the issue is not related to Hyper-V.
A powercfg command has been recommended for 12th gen Intel processors, but I am not using an Intel processor; mine is Ryzen 5 3600.
At my workplace, there is no such issue on a system with a Ryzen 5 5600G processor and Radeon Vega 7 GPU. One user in the VMware forums shared information related to an NVIDIA driver, which I have yet to try.
What do you think could be the cause of the issue? I need to resolve it quickly in order to install Windows 2000. I suspect the reset issue is unrelated, so if I can address the lag problem, I will then focus on resolving the reset problem.
Update (November 2, 2023): I performed a clean format on my computer on Tuesday and installed Windows 11 Pro 23H2. My brother has recently upgraded to a new computer, so he handed down his old computer to me. Consequently, I formatted the computer to get rid of my brother's remnants.
After formatting, I installed NVIDIA driver version 546.01 (I remember it was version 537.42 before formatting) and then installed the newly released VMware Workstation 17.5. Afterwards, I opened my virtual machines and tested them, and the results were excellent. The BIOS screens now run smoothly. I also tried to install Windows 2000, which used to have extreme mouse lag during the GUI installation making movement nearly impossible. Now, it runs as smooth as butter. Unfortunately, I couldn't complete the installation due to a reset, but at least the BIOS lag issue is gone.
I'm not sure if the problem was solved by VMware Workstation 17.5, NVIDIA driver version 546.01, or the clean format, but after all these steps, the issue was resolved.
There seems to be no problem on systems using UEFI like Windows 10 and 11. However, on virtual machines using Legacy BIOS like Windows 7 and XP, I can hardly even see the BIOS screen. I struggle to even access BIOS. By selecting the "Power On to Firmware" option to enter the machine's BIOS, the BIOS interface then becomes extremely slow.
This doesn't usually pose a problem for operating systems that support VESA BIOS Extensions like Windows XP, 7, and 8.1. However, when I tried to install Windows 2000 earlier, I struggled greatly due to this issue. Since Windows 2000 lacks VBE support, the installation interface operates at 640x480 resolution and 4-bit color depth. When I reached the Windows 2000 installation interface, it was so slow that even the mouse was practically unusable. Additionally, the system reset twice due to another issue during the installation process. Therefore, I decided to postpone the installation for now.
My system consists of an AMD Ryzen 5 3600 processor, MSI B450 Tomahawk MAX motherboard, and MSI GTX 1660 Super Gaming X graphics card. I am using Windows 11 Pro 22H2 64-Bit as the operating system.
Many sources suggest checking the vmware.log file for "Monitor Mode: ULM" indicating an issue caused by an open Hyper-V. However, in my case, the log shows "Monitor Mode: CPL0," meaning Hyper-V is completely disabled. Therefore, the issue is not related to Hyper-V.
A powercfg command has been recommended for 12th gen Intel processors, but I am not using an Intel processor; mine is Ryzen 5 3600.
At my workplace, there is no such issue on a system with a Ryzen 5 5600G processor and Radeon Vega 7 GPU. One user in the VMware forums shared information related to an NVIDIA driver, which I have yet to try.
What do you think could be the cause of the issue? I need to resolve it quickly in order to install Windows 2000. I suspect the reset issue is unrelated, so if I can address the lag problem, I will then focus on resolving the reset problem.
Update (November 2, 2023): I performed a clean format on my computer on Tuesday and installed Windows 11 Pro 23H2. My brother has recently upgraded to a new computer, so he handed down his old computer to me. Consequently, I formatted the computer to get rid of my brother's remnants.
After formatting, I installed NVIDIA driver version 546.01 (I remember it was version 537.42 before formatting) and then installed the newly released VMware Workstation 17.5. Afterwards, I opened my virtual machines and tested them, and the results were excellent. The BIOS screens now run smoothly. I also tried to install Windows 2000, which used to have extreme mouse lag during the GUI installation making movement nearly impossible. Now, it runs as smooth as butter. Unfortunately, I couldn't complete the installation due to a reset, but at least the BIOS lag issue is gone.
I'm not sure if the problem was solved by VMware Workstation 17.5, NVIDIA driver version 546.01, or the clean format, but after all these steps, the issue was resolved.