Does the vmware.log contain any related entries about the start/resume process?
André
I don't see any related entries, but it also looks like the vmware.log has not been updated with the recent issue.
Anyway, what I see is that the file contains binary data, which is quite unusual, and could be caused by a file system issue on the host. What I'd suggest is that - after doing a backup - you run chkdsk d: /f to verify the file system, and to fix possible issues.
If this still doesn't solve the issue, extract the two scripts from the attached .zip archive to an empty directory, then drag&drop the VM's folder onto the .cmd file. The scripts will extract the metadata from each .vmdk file. Once done, compress/zip all the newly created Metadata-... files, and attach the .zip archive to your next reply, so that I can do a quick health check on them.
André
The metadata seems to be ok.
What you may do is to reset the VM, i.e. not wake up from the suspended state.
To do this, delete
Windows 7 x64 new-aacaa6b5.vmem
Windows 7 x64 new-aacaa6b5.vmss
If VMware Workstation complaints about the missing files when you try to start the VM, you may need to remove them (the corresponding lines) from the VM's configuration (.vmx) file.
I assume that you already made a backup!
André
Did not help. Didn't complain on anything too. Only the same error.
Should I restore those files for new testings?
Please compress/zip Windows 7 x64 new.vmdk and Windows 7 x64 new-000001.vmdk, and attach them to your next reply. Maybe there's something wrong with these two descriptor files.
André
That will take time, if there is any other options to try?
Maybe there is way to get files from this VM? That would be good solution too.
>>> That will take time, if there is any other options to try?
Just to ensure we're talking about the same files. The 2 mentioned files are small text files, with each of them being only a few hundred bytes in size.
André
Replaced it with file you attached, same error. Or you mean to create new VM and take those files from there?
That's strange, because it was a quite obvious issue.
Can you confirm that VMware Workstation Pro - or at least the VM's tab - was closed when you replaced the file? That's required for VMware Workstation to read the new file, rather than using cached content.
André