Error Message: VMware Workstation: Failed to encrypt virtual machine. (Take 2.)

[John Yacono]

I get the error message "VMware Workstation: Failed to encrypt virtual machine." when I try to encrypt a freshly created Windows 10 virtual machine.

 

Particulars:

VM Workstation 17.6.2 build-24409262 and Windows 10 22h2 64-bit media creation tool downloaded and used the same day the VM was built.

Host is running Windows 8.1 64-bit

Virtual disk current size: 10.8 GB

Virtual Disk Max size 100GB

Space left on host disk: 673.4 GB

Things tried:

I restarted workstation.

I had taken a snapshot of the VM prior to my first attempt, but deleted the snapshot after getting the warning that it needed to be deleted before encryption.

Restarted the VM then shutdown it down after snapshot was removed.

Tried this with an empty Win 10 VM (postponed OS installation); same result.

VM is shutdown before each attempt.

It doesn't matter if I encrypt all files or just the TPM-related files.

Tried all sorts of secure passwords.

Ran chkdisk on host HD.

Verified NTFS disk-access credentials for folder/files for the VM.

I removed file/folder compression from the host, too.

Was successful using VM Workstation 12 on another PC to build a populated Win 10 VM and encrypt it. Then I moved it to the VMWS 17.6.2 PC and updated its virtual hardware. When launching it I was given the option to update the encryption, which just produced a failed to re-encrypt message. It will run however with the older encryption on the VMWS 17.6.2 PC.

 

I hope someone can tell me how to proceed, I'm out of ideas.

 

Thanks very much in advance.

BTW, I'm adding more details to my original request for help in this new thread in the more active discussion section rather than adding them to the original post in the questions section which got no responses. This is not an attempt to double-post all the same info in the same place or to be abusive.

[RaSystemlord]

Not familiar with the subject in hand, but ...

As for an idea: Try with 17.5.2 - I don't think it has any of these recent problems. There is also no shortcoming using it with any Windows version 10 or 11, to my knowledge. I use it a lot with Win 10 / Ryzen and tested a lot (but briefly) with Win 11 / Intel.

[John Yacono]

Thank you for the suggestion, it's much appreciated.

Unfortunately, I go the same result.

Were you successful at encrypting a VM with version 17.5.2 or were you just suggesting I give it a shot it based on your otherwise positive experiences with that version? I'm thinking the later, but asking just to be sure.

[RaSystemlord]

Yes, it was the latter.

Sorry, I cannot specifically suggest you anything about encryption.

[John Yacono]

I appreciate that you took the time to provide the input you could.

Update for those that might come across this issue: Although I couldn't find the correct log file that addressed the error at first, I read in some forum that the help>about screen listed the locations and names of the current log files, so I checked them out. The encryption is failing because the encryption method used by VMWS 17.x is supported by Windows 10 and above, not my old version of Windows.

While I'm grateful for being able to use such a powerful tool for personal use without paying for a license, I think it would be useful if all error messages displayed the line in the log that describes the root cause. If you can record an error, you can display an error, or at the very least a link to the log file in question (which would be a pretty universal fix for many error dialogs). I think that such features will become particularly relevant as the population of personal users--who are less inclined to automatically look for log files--grows.

I hope this is helpful.

[Technogeezer]

The encryption is failing because the encryption method used by VMWS 17.x is supported by Windows 10 and above, not my old version of Windows.

Workstation 17 (which is where the new encryption scheme first appeared. IIRC)  is supported on Windows 10 and later according to https://knowledge.broadcom.com/external/article/315653/supported-host-operating-systems-for-wor.html . Not surprising that there could be problems when trying to run it on older Windows release.  

------------------------------
- Paul (technogeezer)
vExpert 2025
------------------------------

[RaSystemlord]

Thank you!

As for a discussion:

A software company cannot support anything that Microsoft OS is not supporting. Win 7 and before are not. It is out of reach for a software company to guarantee anything. Development environments can fail anywhere, depending on what has been used.

As for error message: A single piece of software (which is not directly handling hardware) can be made so that it never crashes and it always gives out a relevant error message. Almost nothing is done like that, because writing the error handling code to everywhere, adds a lot of lines to the code, and programmers are just lazy or not required to do first-class work. If you are using old code somewhere, like every software company ends up doing, then it gets more complicated and what I wrote above does not apply (because the old code was not done correctly). This is the ideal situation - if you call up Microsoft-thingies, like encryption, it is up to the 3rd party to enable a working procedure to find out why it fails - I mean, it is yet again out of reach by the software company (like VMware).

So, there are many reasons why this ideology doesn't work always. Since Windows 4.0 - OS has been allowed to crash without OS being able to handle it. In theory Windows 3.5.1 never crashed - but that was ignored later on. That's why we have those crashes. When comparing to Linux, it practically speaking never crashes - it's desktop can crash and what not, but the underlying operating system Linux is still working and you might be able to just start the user interface again.