[VMware Player] Try to add virtual TPM to vmx file but VMX file is corrupt after the edit

[testcb00]

Hi everyone, I am new to this forum. I have a Windows 10 Insider Virtual Machine but I cannot open it after I edited the vmx file.

Since the Windows 10 Insider Build is near expired, the only way I can do is to add a virtual TPM module and upgrade the Windows 11. I try to follow this guide and add managedvm.autoAddVTPM = "software" to the vmx file.

https://www.neowin.net/news/windows-11-compliant-tpm-support-added-to-the-free-version-of-vmware-162...

However, after I added the vmx. The VMware Player show that Error while opening virtual machine. VMX file is corrupt.

My platform is VMware Player 16.2 Free Version (Windows 10). I also installed VMware Workstation Player Pro on another Windows 10 VM (VM2), copy the whole VM to VM2 and it said it is an encrypted VM.

How to generate the original vmx? or my data is total lost under this condition?

[scott28tt]

A moderator should be along to move your thread, Horizon and Workstation Player are different products.

[wila]

Hi,

I tried answering your post earlier, but the forum software ate my answer.

Let me try again.

While your data is not technically gone, you do have a serious problem.

First read this article I write today about the vtpm:
https://www.vimalin.com/blog/what-you-should-know-about-vmwares-experimental-vtpm/

As you can read there.. the "it's not encrypted" VM... is partly encrypted.
I don't know why it isn't working for you, if I would have to guess then it would be due to your text encoding ( "Shift_JIS" ) but not sure, there are a number of things that might have caused this.

FWIW, the error itself is wrong.. I can open your attached .vmx file after removing the encrypted strings, deleting the .vmsd + .nvram files and creating a blank 60GB monolithicsparse virtual disk.

Sounds like the descriptor snippet in your virtual disk is encrypted and that you need to replace that in order to be back in business.

Doing that part is not my strength, perhaps @a_p_ can help with that part.

--
Wil

[bluefirestorm]

Agree with wila there are multiple problems here. The best thing is to re-create the VMDK descriptor. So if an old backup that is the unencrypted VMDK descriptor of the virtual disk, you can use that; otherwise will need manual recreation. Then go back to the state of before the vTPM (can re-create the vmx from the test.zip).

Additional problems I see aside from what already mentioned, the test.zip shows log using version 16.1.2 and virtual HW version 12 while the other log shows version1 16.2. There are no vTPM entries (vtpm.present, the vTPM endorsement keys) and no firmware = "efi" in the test.zip file.

2021-10-23T03:16:28.949+09:00| vmx| I005: Log for VMware Player pid=6276 version=16.1.2 build=build-17966106 option=Release
2021-10-23T03:16:29.284+09:00| vmx| I005: DICT virtualHW.version = "12"

2021-10-23T03:16:29.926+09:00| vmx| I005: DISKLIB-DSCPTR: Opened [0]: "Windows 10 x64.vmdk" (0xa)
2021-10-23T03:16:29.927+09:00| vmx| I005: DISKLIB-LINK : Opened 'R:\Virtual Machine\Windows 10 x64\Windows 10 x64.vmdk' (0xa): monolithicSparse, 125829120 sectors / 60 GB.
2021-10-23T03:16:29.927+09:00| vmx| I005: DISKLIB-LIB : Opened "R:\Virtual Machine\Windows 10 x64\Windows 10 x64.vmdk" (flags 0xa, type monolithicSparse).
2021-10-23T03:16:29.927+09:00| vmx| I005: DISKLIB-LIB_MISC : DiskLib_GetStorageBlockSizes: Failed to get storage block sizes, The virtual disk requires a feature not supported by this program.
2021-10-23T03:16:29.927+09:00| vmx| I005: DiskGetGeometry: Reading of disk partition table
2021-10-23T03:16:29.934+09:00| vmx| I005: DISK: Disk 'R:\Virtual Machine\Windows 10 x64\Windows 10 x64.vmdk' has UUID '60 00 c2 95 93 b4 9c 6e-d4 6e 9c 28 00 1f 84 1a'
2021-10-23T03:16:29.934+09:00| vmx| I005: DISK: OPEN 'R:\Virtual Machine\Windows 10 x64\Windows 10 x64.vmdk' Geo (7832/255/63) BIOS Geo (7832/255/63)
2021-10-23T03:16:29.940+09:00| vmx| I005: DISKUTILWIN32: DiskUtilW32IsATASSDDevice: Failed to send ATA IDENTIFY command to the target device.
2021-10-23T03:16:29.941+09:00| vmx| I005: DISKUTILWIN32: DiskUtilW32IsScsiSSDDevice: Reported rotation rate = 1

For vTPM to work, the firmware needs to be UEFI (firmware="efi" needs to be there). But before adding that line the guest OS will need to convert from MBR to GPT first. That should be done using the MBR2GPT tool.

https://docs.microsoft.com/en-us/windows/deployment/mbr-to-gpt

To enable secure boot for Windows 11,

uefi.secureBoot.enabled = "TRUE"

also needs to be in the vmx file.

Anyway, get the VMDK descriptor back to its original state.

[a_p_]

Rebuilding a descriptor file is basically an easy thing if it's a standalone file, but in this case a monolithic virtual disk format is in use which has the descriptor embedded.

Anyway, what I noticed is that the configuration (.vmx) file points to the same virtual disk (.vmdk) file twice, which should not be the case. It's used for scsi0:0 as well as sata0:1. I'd suggest that - after backing up the VM's files - you remove the "sata0:1..." lines from the .vmx file. Ensure that Workstation Player is closed when you edit the file, so that it is re-read after the modification.

André

[testcb00]

I am not sure what is the correct way to rebuild the descriptor.

Here is the guide which I get from Google. https://kb.vmware.com/s/article/1015634

However, it seems that this guide is for creating a new vm disk. May you provide a simple guide of using the command?

From wila's blog, part of the vmdk might be encrypted. I cannot find other related material to rebuild the descriptor in this case.

I have prepared a copy of that 60GB vmdk for testing. Thank you.

[a_p_]

The KB article unfortunately doesn't help with an embedded descriptor.

To find out what can be done, I need the .vmdk file's metadata. Assuming that the encryption didn't resize the metadata section, it is the first 7,929,856 Bytes.

One option to extract that part is to download https://sanbarrow.com/files/dsfok.zip, extract the executables, and run the below command in the VM's folder. Then compress/zip the ".bin" file and attach the .zip archive to a reply post.
Any other option/tool to extract that data from the .vmdk file is ok too.

dsfo.exe "Windows 10 x64.vmdk" 0 7929856 "Metadata.bin"

André

[testcb00]

Thank you, André

Here is the bin file. MD5 = 27fc0a27149f95c8655e379bd286702e

I would like to know how to determine if the metadata section is (not) resized and how to read the metadata.

I try to open the bin file but I cannot see the data, it seems that the metadata is encrypted.

[bluefirestorm]

From the looks of it, the descriptor got encrypted. It is from offset hex 200 - hex 550. (See attached screenshot).

I am not sure if the encoding would be UTF-8 on Windows OS with Shift-JIS character set. But my best guess is it should not matter to the guest OS inside.

If you have a working Python3 environment in your host machine (or some other machine), I wrote a quick and dirty Python program (the replaceVMDK.txt in the attachment, .py attachments not allowed) that would read a text file that has the encrypted descriptor and replace the location. I suppose this program can be modified to write directly to the VMDK instead of the metadata.bin file.

[a_p_]

The solution provided by @bluefirestorm should work. However, if you don't have Phython installed, you can easily fix the issue yourself.

1. create a new (temporary) VM with the same name "Windows 10 x64.vmdk" and the same virtual disk format (60GB - Monolithic Sparse, i.e. as a single file) as the existing one, but in a temporary folder
2. extract the header data from the temporary VM's .vmdk file using dsfo.exe
   dsfo.exe "Windows 10 x64.vmdk" 0 1536 "Metadata-OK.bin"
3. copy "Metadata-OK.bin" to the encrypted VM's folder
4. inject the .bin file into the encrypted .vmdk file using dsfi.exe
   dsfi.exe "Windows 10 x64.vmdk" 0 1536 "Metadata-OK.bin"

This will of course only fix the .vmdk file, but not the other encrypted files, so it may be necessary to do some other things (see @wila 's blog post).

André

fd

[testcb00]

Thank you for your help.

I tried both program and command. After the modification, I tried to follow this guide https://stackoverflow.com/questions/46193933/how-to-repair-vmx-file-corrupted-at-vmware, create a new VM to use the modified vmdk file.

However, the VMware Player said The selected virtual disk is incompatible with this workstation 12.x virtual machine. I also try to create a new VM with the same name. I can add the vmdk using the Existing disk file method but I cannot find the boot file. From blog, some file are encrypted including the .nvram file which store boot data.

Besides, I boot the Windows Installation ISO in the new VM and I can see the Partition. I can also read the data but I cannot make it bootable.

As I can read the data from the modified vmdk and create backup, I think I can create a new VM and rebuild my environment based on the backup.

Thank you very much.

[bluefirestorm]

If you have a Python3 environment, you can play around with the text file to replace the contents of the metadata. The longContentID and UUID were taken from the vmware.log that was in the test.zip. You can see that there is a virtualHWversion entry in the VMDK descriptor. So if you created using version 16.x software, the virtual disk descriptor might be virtual hardware version 18 (16.0/16.1) or 19 (16.2).

AFAIK, the boot information should only be in the nvram if the VM is using UEFI. From the log, the firmware="efi" entry was not there, so I suppose that it is using BIOS and not UEFI. So the new VM you could should also be using BIOS. In the past, a VM with virtual BIOS can safely delete the nvram without worry. Aside from that, the vmsd would also need to be removed and the dictionary entries related to vTPM from the vmx would also have to be removed.

But from your screenshot, it looks like it has 4 partitions. The MBR2GPT tool will only work if it has 3 partitions. You would need to have the GPT partition to have UEFI VM to boot and you need UEFI for vTPM to work.

Anyway, try to get the old virtual disk boot again first if you still want to continue to do so.

[9etzen]

I have the same issue and want to attempt same solution so I'm trying not to start an entirely new post; I hope that is ok.

problem: virtual machine having vTPM feature and which previously did not prompt for password until VM was moved to new device/laptop.

solution: replacing encrypted virtual machine descriptor with an unencrypted descriptor, for virtual machine having vTPM feature and which previously did not prompt for password until VM was moved to new device/laptop.

I detailed my problem in this reddit post, where I included virtual machine config file, and pictures of my VM directory folder, properties, etc.

Vmware Workstation Player 16 VM asking for encryption password on new laptop; never did on old lapto...

However, my post boils down to 4 questions:

1. When I create the new temporary virtual machine which I will need for its unencrypted descriptor, can I get away with creating a blank VM by choosing the option "I will install the operating system later. The virtual machine will be created with a blank hard disk" OR am I required to use the same IMAGE as used for the original "encrypted" virtual machine? https://imgur.com/2CbzWhe

2. I can't recall the exact size of my "encrypted" virtual machine AND now that its prompting for password, the option "settings" (which contains data about volume size) is greyed out. So instead I right-clicked on the VMDK file and clicked properties and it lists 60.9GB under "size." Is this an accurate way of checking volume size OR is there some other more accurate method? https://imgur.com/kfaFLup

3. Originally on my old laptop, my virtual machine was smaller (I think 30GB or 40GB). Then I increased the size and then added the vTPM feature, although I can't be certain that was the order. In this case, will your solution still work?

4. Here's a directory of my virtual machine folder: https://imgur.com/r9HHbRA