Note
This English version was translated and polished with the assistance of an LLM (Large Language Model).
Recently, after upgrading from an older version of VMware Workstation to VMware Workstation 26H1, a cloned Windows 11 virtual machine on my computer would no longer open without asking for its encryption password:
This virtual machine is encrypted.
You must enter its password to continue.
The source VM—the VM from which the clone was created—still booted normally and unlocked automatically using the password stored in Windows Credential Manager. The cloned VM, which had worked without issue before the upgrade, instead stopped at the password prompt.
Core Mechanism: Change in Credential Indexing Method
To understand the root cause, we first need to know why the Windows 11 VM was encrypted. Windows 11 officially requires TPM 2.0 for supported installations, and adding a virtual TPM (vTPM) causes VMware to require encryption for the VM files that contain sensitive configuration data.
Log Analysis
VMware runtime logs reveal a difference in credential lookup behavior before and after the upgrade.
Authentication in older Workstation versions:
Older Workstation versions used encryptedVM.guid in the .vmx file as the unique identifier for matching a password stored in Windows Credential Manager.
1 | GetEncryptionVmGuidFromConfigFile: Fetching encryptedVM.guid from config file |
Observed authentication behavior in Workstation 26H1:
In my testing, Workstation 26H1 instead looked up the saved credential using the full path to the VM’s .vmx file as the credential target name. After the source VM was successfully opened and unlocked in 26H1, a new path-based credential entry appeared in Credential Manager:
1 | VMware Encrypted VM: D:\Virtual Machines\Windows 11\Windows 11.vmx |
Since the cloned VM did not undergo this migration, no entry pointing to the clone’s .vmx path existed in Credential Manager. When 26H1 attempted to start the cloned VM, the following authentication failure was logged, requiring manual intervention:
1 | Failed to find credential for D:\Virtual Machines\Windows 11 Clone\Windows 11 Clone.vmx, searching... |
Solution: Credential Extraction and Re-entering the Password
Because the cloned VM has the same encryption.keySafe value as the source VM, the clone inherited the source VM’s encryption password. The stored password for the source VM can therefore be retrieved and entered when unlocking the clone.
The key technical reference here comes from the solution provided by GitHub developer andshrew: Retrieving VMware Workstation VM encryption passwords.
Although the Windows Credential Manager GUI does not display passwords in plain text, the current user can invoke the Win32 CredReadW API to read generic credentials saved under their account.
Remediation Steps
Locate the Source VM’s Legacy Credential: Open the source VM’s
.vmxfile in a text editor and find itsencryptedVM.guidvalue. This GUID was used as the credential target name by older Workstation versions and should look like{833AB4F5-587E-4B11-9260-4DB13742FA7F}. In this case, the corresponding legacy entry was still present underCredential Manager→Windows Credentials.Retrieve the Plaintext Password: Use the PowerShell/C# script provided by andshrew to call
CredReadW, passing it the exactencryptedVM.guidvalue found in the.vmxfile. The reference script usesMarshal.PtrToStringAnsi. If the password contains characters that are decoded incorrectly, PowerShell 7 users can tryMarshal.PtrToStringUTF8instead.Enter the Extracted Password:
- Paste or type the extracted plaintext password into VMware’s unlock prompt for the cloned VM.
- Select
Remember the password on this machine in Credential Manager. - The virtual machine should now unlock and function as expected.
Verify Status: Inspect the log or fully exit and restart VMware Workstation to confirm that the new path-based credential was persisted:
Text 1
Password for VMware Encrypted VM: <Clone Path> saved to Credential Manager
Once fixed, Credential Manager will independently maintain credentials for both the source VM and the cloned VM. This is the standard behavior of 26H1 and requires no further action.
Takeaway: It’s always a good idea to keep a backup copy of your passwords.