VM suspended: 'the system cannot find the file specified' Unable to open *.vmdk

[ascreek]

After suspending VM yesterday night, I came back and I get the error cannot open the vmdk file because the system cannot find it. The file is there. I can browse to it and see it. My vmx file appears to be in good shape. I am using windows 8.1. If someone can help, I would appreciate it, please!

I don't care about losing/restoring the current suspended status, just to be able to reboot the VM.

Attached are list of files and folders and vmware.log extract.

Thank you.

[continuum]

Please do not attach random snippets of vmware.log files- that does not help.
Please attach the complete vmware.log and Windows 10 LTSB 2016 x86 Crystal.vmdk

Ulli

[ascreek]

Thank you for your reply. That vmware.log exposes tech details such as mac address, ethernet etc.. I would not be so comfortable to use that VM again after sharing those data on a forum.

That's the reason I cut the log.  Any workaround to make that vmware.loog useful but protecting sensitive data?

[continuum]

Find the error message - and ignore the part at the beginning about missing *.ini-files - thats just nornak background noise.
Please also include the part that lists the vmx-file.

Ulli

[a_p_]

What you can do yourself, without exposing any data, is to verify the all the .vmdk files that are listed in

Windows 10 LTSB 2016 x86 Crystal.vmdk

exist in the VM's folder.

André

[ascreek]

Effectively segment #28 is present in '

Windows 10 LTSB 2016 x86 Crystal.vmdk

but it is missing in the 'list files' I attached above.

# Extent description
RW 8323072 SPARSE "Windows 10 LTSB 2016 x86 Crystal-s001.vmdk"
RW 8323072 SPARSE "Windows 10 LTSB 2016 x86 Crystal-s002.vmdk"
RW 8323072 SPARSE "Windows 10 LTSB 2016 x86 Crystal-s003.vmdk"
RW 8323072 SPARSE "Windows 10 LTSB 2016 x86 Crystal-s004.vmdk"
RW 4456448 SPARSE "Windows 10 LTSB 2016 x86 Crystal-s005.vmdk"
RW 1048576 SPARSE "Windows 10 LTSB 2016 x86 Crystal-s006.vmdk"
RW 2097152 SPARSE "Windows 10 LTSB 2016 x86 Crystal-s007.vmdk"
RW 2097152 SPARSE "Windows 10 LTSB 2016 x86 Crystal-s008.vmdk"
RW 2097152 SPARSE "Windows 10 LTSB 2016 x86 Crystal-s009.vmdk"
RW 2097152 SPARSE "Windows 10 LTSB 2016 x86 Crystal-s010.vmdk"
RW 2097152 SPARSE "Windows 10 LTSB 2016 x86 Crystal-s011.vmdk"
RW 2097152 SPARSE "Windows 10 LTSB 2016 x86 Crystal-s012.vmdk"
RW 2097152 SPARSE "Windows 10 LTSB 2016 x86 Crystal-s013.vmdk"
RW 2097152 SPARSE "Windows 10 LTSB 2016 x86 Crystal-s014.vmdk"
RW 2097152 SPARSE "Windows 10 LTSB 2016 x86 Crystal-s015.vmdk"
RW 2097152 SPARSE "Windows 10 LTSB 2016 x86 Crystal-s016.vmdk"
RW 2097152 SPARSE "Windows 10 LTSB 2016 x86 Crystal-s017.vmdk"
RW 1257472 SPARSE "Windows 10 LTSB 2016 x86 Crystal-s018.vmdk"
RW 1048576 SPARSE "Windows 10 LTSB 2016 x86 Crystal-s019.vmdk"
RW 2097152 SPARSE "Windows 10 LTSB 2016 x86 Crystal-s020.vmdk"
RW 1048576 SPARSE "Windows 10 LTSB 2016 x86 Crystal-s021.vmdk"
RW 2306048 SPARSE "Windows 10 LTSB 2016 x86 Crystal-s022.vmdk"
RW 1048576 SPARSE "Windows 10 LTSB 2016 x86 Crystal-s023.vmdk"
RW 1048576 SPARSE "Windows 10 LTSB 2016 x86 Crystal-s024.vmdk"
RW 1048576 SPARSE "Windows 10 LTSB 2016 x86 Crystal-s025.vmdk"
RW 1048576 SPARSE "Windows 10 LTSB 2016 x86 Crystal-s026.vmdk"
RW 2097152 SPARSE "Windows 10 LTSB 2016 x86 Crystal-s027.vmdk"
RW 839680 SPARSE "Windows 10 LTSB 2016 x86 Crystal-s028.vmdk"

# The Disk Data Base
#DDB

[continuum]

Check the quarantine directory of your Antivirus-tool - maybe it is a bit overeager and thinks it gets paid for ruined VMs.
Also make sure that OneDrive does not see your vmdks ....

If you cant restore the missing file - recreate it with a dummy VM of same size. Then just replace last slice and either fix the partitiontable or use a s028.vmdk from a fresh new install of Win10.

[a_p_]

Please follow @continuum's advice to search for the file.
If you cannot find it, try to replace it by the stub file that I've attached in the .zip archive.

Please make sure that you have a backup of the current folder/files, in case it's needed.

André

[ascreek]

Thank you guys @continuum @a_p_

for your reply. (Strangely a couple of attempts to post some relevent extract of the requested vmware.logs have been deleted).

Anyway the file #28 is  not available in Windows Defender quarantine.

Using your dummy #28 63KB file caused repeated restarts and endless KMODE Exception Not Handles or Unexpected Kernet Mode Trap errors.

So I managed to restore an old #28 backup (Windows 10 LTSB 2016 x86 Crystal-s028.vmdk) dated April 2022; it is about 433Mb.  I was given the chance to restore using a restore point dated May 27th. Unfortunately it did no work and caused only subsequent endless Page Fault in Nonpaged Area (win32kfull.sys) errors at the next reboots. Subsequent repeated reboots, automatic restores did not help and the error is the same. All these experiments were done using a backup of the original Crystal VM, as suggested. So the first 27 files are still untouched for further attempts, eventually.

- Other ideas, please, or I have no other chances than to restore fully that VM old full April backup?

[continuum]

Attach the vmdk to another, working Windows VM or use a Windows LiveCD / Installation media and run checkdisk /f /x /r against the broken partition.

Ulli

[ascreek]

Thank you for your reply but what's the point, please of 'Attach[ing] the vmdk to another, working Windows VM'?

 I need to restore that Crystal VM, not getting the access to another working VM with 27 segments (and attaching the 28th vmdk).

About running checkdisk /f /x /r , sure I will try it. I thought the embedded process in Windows restore ran that kind of commands.

[continuum]

> what's the point, please of 'Attach[ing] the vmdk to another, working Windows VM'?

The idea is to repair the filesystem - in case the existing Windows is not healthy enough to run a checkdisk or fix a damaged partitiontable or repair the GPT at the end of the disk.
To repair the registry it often helps to load the registry hives from another Windows.

[ascreek]

Sure -- reparing the file system of another (already working) VM with 27 segments plus the restored Crystal #28 - 413 Mb from the backup.

And the net result will be?....  surely not the original Crystal VM and its contents but the new VM that actually does not any fixes.

Sorry but... am I missing something?  As for comparison, simply restoring the full Crystal VM from backup dated April 4th would produces more data to be rescued than a new, empty VM with 27 segments plus restored/dummy Crystal #28.

What I agree and makes sense is trying those chkdsk commands against the broken partition even if I never tried to mount a Vmware VM from another Windows Live CD. Is there any tutorial about that task, please?

[continuum]

> simply restoring the full Crystal VM from backup dated April 4th would produces more data to be rescued than a new, empty VM with 27 segments plus restored/dummy Crystal #28.

Sure - thats expected .... what did you expect from a "new, empty VM ???
Slice 28 is a small one and often has just the end of the GPT-table.

> Is there any tutorial about that task, please?
You simply configure the VM to use a LiveCD or a Windows-installation-iso. Then you adjust BIOS to boot from CD.
After that you google for the error message you received without LiveCD and then follow the instruction from a Microsoft Knowlegebase.