When a Windows virtual machine (VM) configured with the VMware Tools upgradeAtPowerCycle policy undergoes automated Windows updates, conflicts can arise between the Guest OS boot routines and the VMware Tools auto-upgrade process. This overlap often leads to installation failures, resulting in missing drivers (e.g., VMXNET3) or the uninstallation of existing VMware Tools components.
Symptoms
vmupgrader_msi.log) show errors: 1723, 1603, 19, or 21009.VMware vSphere ESXi 8.x
VMware Tools 11.x, 12.x, 13.x
Guest OS: Windows Server (all versions)
This issue occurs due to a race condition between the Windows startup/shutdown routines and the VMware Tools auto-upgrade engine with the VMware Tools upgrade policy upgradeAtPowerCycle. This contention is often exacerbated by real-time security software (e.g., Antivirus/EDR) locking core installer binaries or registry keys during the update process.
VMware Tools 11.x and later installers handle this error by alerting the user while allowing the process to continue. If a failure occurs:
Workaround:
Disable Auto-Upgrade Policy:
tools.upgrade.policy to Manual on production virtual machines.Configure Security Exclusions: Exclude the following paths and processes from your real-time security software to prevent file-locking collisions:
C:\Program Files\VMware\VMware Tools\ , C:\ProgramData\VMware\ , C:\Windows\Installer\ , and C:\Windows\Temp\vmware-SYSTEM\setup64.exe, vmtoolsd.exe, VGAuthService.exePerform Manual Reinstallation:
setup64.exe /s /v "/qn REBOOT=R"Decouple update cycles: VMware Tools updates should be managed out-of-band via vSphere Lifecycle Manager (vLCM) or manual deployment, rather than relying on automatic power-on upgrades for production workloads.