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.
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!
>>> 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.
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.