Corrupted VMDK

[Anthony_Jones]

As I boot up my VM I get this error: "The disk ... has one or more internal errors that cannot be fixed". The error started appearing after I tried performing defragmentation from VM settings menu. Although the defragmentation process finished correctly, it seems like something weng horribly wrong.

 I'm using VMWare Workstation 16 Player (16.2.3 build-19376536) on Windows 10 x64.

The attachement includes metadata of all of the vmdk files of the VM.

[continuum]

Try to replace slice 7 with a new blank one.
And try to run
vmware-vdiskmanager -R against the vmdk

For now I would assume that the defrag-vmdk function is broken and avoid it.
The -R function seems to be improved a bit - nowadays I would no longer consider it a bluff - but you may need to run it a few times.
Read the vdiskmanager.log - as long as it fixes errors rerun it.

Ulli

[Anthony_Jones]

I didn't know where to get a new blank slice, so I just created an empty zero size file and call it slice 7's name. I run "vmware-vdiskmanager -R" a few times and here's what I got:

[continuum]

You create a dummy VM and with that you create a new vmdk with the same size but do not install anything into it.
Thats where you can then steal an empty slice

[Anthony_Jones]

Ohh, this is awkward... I didn't even think about that.

Okay, I did what you said but the result is still the same. 

I run diskmanager on the first vmdk slice, the one with no index. Then I run it on every other slice. Same result.

I do it in the console, like this:

I feel like I'm doing something wrong, sorry I'm not really good with computers.

[a_p_]

You're doing nothing wrong, because it's "Windows 10 x64-s003.vmdk" that has corrupted Metadata. I'm currently taking a deeper look at this, but can't promise you anything at this time.

André

[a_p_]

Here we go. What I was able to do, is to fix the metadata, so that the file will get recognized as a valid .vmdk file, but I can't tell you how much data corruption to expect within the guest OS. So please consider to backup the VM's folder prior to do the modification, and create a snapshot after injecting the metadata (before powering on the VM).

To inject the modified metadata into the .vmdk file, please download dsfok.zip from https://sanbarrow.com/vmdk-tools.html and extract dsfi.exe. With "dsfi.exe" and the extracted .bin file from the attached .zip archive in the VM's folder, run the following command.

dsfi.exe "Windows 10 x64-s003.vmdk" 0 524288 "Metadata-Windows 10 x64-s003-fixed.bin"

Usage: dsfi.exe <destination> <offset> <size> <source>

André

[a_p_]

Here we go. What I was able to do, is to fix the metadata, so that the file will get recognized as a valid .vmdk file, but I can't tell you how much data corruption to expect within the guest OS. So please consider to backup the VM's folder prior to do the modification, and create a snapshot after injecting the metadata (before powering on the VM).

To inject the modified metadata into the .vmdk file, please download dsfok.zip from https://sanbarrow.com/vmdk-tools.html and extract dsfi.exe. With "dsfi.exe" and the extracted .bin file from the attached .zip archive in the VM's folder, run the following command.

dsfi.exe "Windows 10 x64-s003.vmdk" 0 524288 "Metadata-Windows 10 x64-s003-fixed.bin"

Usage: dsfi.exe <destination> <offset> <size> <source>

André

[Anthony_Jones]

I did everything you said. I injected the fixed metadata and the vmdk file got recognized correctly, the error was gone. It even started booting up. Then windows tried to run the repair process, got stuck with BSOD and went to reboot, and that repeated over and over.

Stopcode: PAGE_FAULT_IN_NON_PAGED_AREA

What could caused the error: WimFsf.sys

I was about to give up but remembered something!

See, before looking up for the solution online, I attempted to attach this corrupted vmdk to another vm and read the data from it as it was an external drive. Obviously it didn't work — I got the same error as before, the vm refused to boot up at all (I even thought this second vm got broken but I managed to get it fixed by manually removing the line about the corrupted disk image from the vmx file).

So I thought maybe it could work now that the vmdk metadata is fixed. I attached it to my second vm and — guess what — it worked! While the vm itself is broken and refuses to boot up, I still could successfully copy all my data to a safe place.

I can't thank you enough, you're my hero