VMware Workstation Update Broke VMs – Fix It Fast

I know that sinking feeling

You clicked "Update" on VMware Workstation, and now your VMs won't boot. Black screen, hung on "Starting Windows", or a cryptic error about virtual hardware. Been there. Let's fix it.

The fix that works 9 times out of 10

Skip the forum threads about reinstalling from scratch. The real fix is a two-part process: edit the VMX file, then reinstall VMware Tools. Here's the exact order.

Power off the broken VM completely — don't just suspend it. Use vmrun stop "/path/to/your.vmx" hard if needed.
Edit the VMX file — it's a plain text file alongside your VMDK. Open it in Notepad or VS Code. Look for this line:
```
virtualHW.version = "21"
```
If it's set to 21 (Workstation 17.5.x), change it to 20 (Workstation 17.0.x). Save and close.
Start the VM — it should boot now. You might see a warning about virtual hardware mismatch. Ignore it.
Reinstall VMware Tools — from the VM menu, select Install VMware Tools. In the guest, run the installer. On Linux guests: sudo ./vmware-install.pl -d. Reboot the guest.
Now update the VMX again — change virtualHW.version back to 21, save, power on. This time it'll pick up the newer version without breaking anything.

That's it. The VM should be fully working again.

Why this works

What's actually happening here is that VMware Workstation 17.5 introduced a new virtual hardware version (21) that includes changes to the PCIe topology and UEFI boot path. When the update applies to an existing VM, it bumps the hardware version before VMware Tools has the matching drivers. The VM then tries to boot using a driver set that doesn't understand the new bus layout—so it hangs or fails outright.

By rolling back to version 20, you tell the hypervisor to emulate the old hardware layout. The guest's existing drivers work fine. Then, after reinstalling Tools (which now ships with version-21-aware drivers), you can safely upgrade the VMX again. The reason step 3 works is that the Tools installer detects the current hardware version and deploys the correct drivers.

Important: This happens because VMware updates the virtual hardware silently during the upgrade. You never get a prompt asking if you want to keep the old version. It's a design choice that assumes everyone wants the latest, but it breaks production VMs.

Less common variations

Sometimes the issue isn't just the hardware version. Here are two edge cases I've run into:

Corrupted NVRAM file

If your VM has UEFI boot and you're getting a black screen with a blinking cursor, delete the .nvram file in the VM folder. VMware will recreate it on next boot. This fixes cases where the update corrupted the UEFI firmware state.

VMware Tools fails to install

On some Linux guests (Ubuntu 22.04 with kernel 6.2+, for instance), the new Tools version might fail to compile the kernel modules. The trick is to install linux-headers-$(uname -r) and build-essential before running the installer. If that still fails, use vmware-install.pl --default and manually answer yes to module compilation prompts.

Snapshot chain corruption

If you had snapshots before the update, the new hardware version can break the delta disk chain. The symptom is a VM that boots to a blue screen or kernel panic. In this case, the safest fix is to revert to the baseline snapshot before the update, then apply the VMX edit above. Discard the post-update snapshots—they're based on the wrong hardware version and won't work reliably even after a fix.

Prevention for next time

Preventing this is straightforward:

Always take a full VM snapshot before updating VMware Workstation. Not a snapshot of the VM—a full backup of the VM folder. Snapshots can fail if the update changes the disk format.
Check the VMware Workstation release notes for any mention of virtual hardware version changes. If they bump the version, manually upgrade your VMs later, one at a time.
Set virtualHW.version explicitly in your VMX after you've verified the VM works on the new version. This prevents accidental downgrades in future updates.
On critical VMs, delay the Workstation update by at least two weeks. Let others test it first. Yes, it's boring advice—but it's free and it works.

One last opinionated note: if you're running production VMs on Workstation, consider moving to VMware Workstation Pro or a proper hypervisor like ESXi. Workstation Player and the free Workstation Pro have limited support, and a broken update can cost you hours. But that's a rant for another day.