'Error While Powering On: The file specified is not a virtual disk'

[dag0970]

The problem I'm suddenly having seems to be recapped to some extent in other questions/discussions. In any case, if this question with similar dimensions/parameters has already been resolved with sufficient clarity that I can fix the problem myself, kindly redirect me the extant discussion/resolution.

Having said that, the precise answer(s) to what the solution(s) might be seem relatively unique to each user/vm environment. If a forensic review could clarify whatever caused my particular problem, I would be happy to upload dump files, mem files, etc. from the relevant directory.

I'll go ahead and upload as much as I can here to get started on this.

The problem started this morning after the VM ('Zero') had been suspended yesterday and the host machine was shut down normally last night.

The problem I'm having is that my VM won't bootstrap from the .vmx file, which to my knowledge was not altered/corrupted, but may have been without my knowledge. The only AV program running (apart from Windows Defender) on the host machine is CCleaner--neither of which have caused any problems like this to date--this is the first/only time this has happened yet and I've been running this very same VM image of Windows 7 for 2-3 years quite stably. The VM image is called 'Zero' (will be evident from image appended of the VM directory in User/docs). All of the .vmdk files are present and accounted for (#'s 001-042)--no vmdk's missing. The .vmx/config file is still present.

I can say that ~ 2 weeks ago Microsoft pushed out a rather large 'update' for Windows 10, which runs as the sole OS (no dual boot) on the same physical hard drive that also runs Workstation and on which is stored all VM files relevant for the functioning of Zero. There were the usual product updates for Edge/IE, etc. (and maybe some other stuff wedged in there by MS), but there were no immediate concerns/problems discernable in the functioning of Workstation (I think I was running 12.x, no windows server and no pro version, just the freeware Workstation). This evening, I downloaded and installed v14 of workstation thinking that it might help to resolve the problem, but no dice. If I had to guess the .vmx got corrupted somehow, by the otherwise 'normal' functioning of some other process, hidden conventionally within windows or (I would give it less probability), the 'ordinary' functioning of CCleaner or Windows defender.

I'd take a guess that if I could assess/test and repair the .vmx file (assuming it has been corrupted), that would solve the problem. Incidentally, the .vmss file is ~ 200mg, too large for upload w/ conventional means.
Anyway, I'm really hoping to get some guidance/reflection from the users here in this forum--really any useful/helpful reflections/insight would be most appreciated. Thank-you in advance, I'm really in a pickle.

Revised 03/19: I have a hunch that the culprit here was the Microsoft Update 2-3 weeks ago--various/itinerant manifestations of strange/unexplainable behavior with the host OS since then--apparently unrelated but may not be correlated. Similar thing happened w/ host machine OS Office Outlook functioning; Outlook unable to load/interpret native.pst/.ost files in its extant file hierarchy w/some files being duplicated. I could try restoring the host OS back to pre-update state but my sense is that would not resolve the problem here. I can't get product support from VMware without buying 10 ore more licenses, although I could upgrade to Workstation v15 Pro if that would offer additional tools for resolving this.

[wila]

Hi,

Attach a vmware.log file from the VM.

--

Wil

[dag0970]

HI Wila,

Here's the most recent one (there were a few).

[wila]

Hi,

Ok, it looks like that the vmware.log file is only has lines from before the issue occurred.

You will need the help of either Andre or Ulli here at the forums in order to see if the virtual disk can be recovered.

Meanwhile you can already try to provide the information they need in order to be able to help you.

To check whether the issue can be resolved, please attach the "zero.vmdk" (this should be a small text file) to a reply post and provide a list of all the zero files (e.g. the output of dir zero*.* /one) with names, sizes, ...

--

Wil

[dag0970]

The malfunction/issue was first observed when the host machine was booted from cold and VM was initiated (from suspended state) on the morning of Tuesday 03/19/19.

There are (by my count) 3 different VMware.log files named VMware-0, VMware-1 and VMware-2. It appears the one I had uploaded originally was the VMware-0. '1' and '2' in the series may offer a different perspective, so I will upload those to this post.

[dag0970]

There is another VMware.log file sitting in the Virtual Machines directory above/outside of the container for Zero (please see appended screen capture). I'm appending it to this as well since it could be significant--entries are back from 2016, probably when I created Zero.

[dag0970]

Thank-you again btw.

Reviewing the contents of dir Zero's, I do not see any file named "zero.vmdk" present as a text file. All the vmdk's for Zero, numbering 001-042, seem to be accounted for in the screenshot I've appended to this post, with relevant file sizes, etc., showing in the list/details view.
If you go back to the appended docs I uploaded in my first/intro post to this thread, there is a screen capture taken of the dir zero contents (sans specific file info, just file names are showing), called VMware Zero folder contents. I'll upload another shot of the folder in similar view to this post--I don't see any text file named 'zero.vmdk', so unless I'm missing something the text file "zero.vmdk" you've requested is AWOL.

[wila]

Hi,

Screenshots are not always helpful for troubleshooting, it shows some parts, but not all.

Especially not if Windows Explorer is configured to hide the file extension as in your screenshots.

In that case you have to go by the icons.

So it looks to me like you have a "Zero.vmdk" file that is small and a text file.

This is btw also why I asked for the output of the command "dir \one" on the VM folder.

Output and attached as text file please, not as a screenshot.

--

Wil

[wila]

Hi,

Actually... I think I take that back about your screenshots..

As it turns out I do see something wrong in your screenshot that might indeed cause the problem you have.

File "Zero-s041.vmdk" is 0kB.. which is not correct.

Rename/delete that file and copy one of the 320kB files into its place.

Eg. make a copy of Zero-s036.vmdk and rename that copy into Zero-s041.vmdk

(Change your windows explorer to display file extensions if needed)

Then try booting again.

Oh and you did of course already make a complete copy of all the files in your VM to an external disk right?

Before you mess it up with making changes to the virtual disk like this one...

PS: Note that while patching Zero-s041.vmdk might allows you to boot again. Any data that previously might have been in that file is permanently lost.

--

Wil

[dag0970]

Sorry, thanks for your patience wila--I think this is what you were asking for. Also included is full dir/search run from VM folder (output pasted into notepad) from CLI.

[dag0970]

I'm working on this right now. Have to some data migration here to back up the entire contents of VM folder to another disk.

[dag0970]

Renaming and replacing the file "Zero-s041.vmdk" with "Zero-s036.vmdk" has resulted in a bootable VM Zero (problem solved Wil!). Cursory examination of the OS and data components suggests that nothing significant was lost. Of course, I'm left wondering what caused this to happen in the first place (not knowing for sure if it was the recent Microsoft update that caused Outlook to cease functioning).

I was thinking of replacing the current Zero altogether, after backing up important data from it, since it's a windows 7 image and I've been moving everything over to Windows 10 for the most part. That would probably make sense to do anyway, even without the issue you helped me resolve.

I can't thank you enough Wil. You saved me from disaster. 

I'm getting that your solution, Vimalin, is a great idea. I will need to upgrade from Player to Pro, however, in order to make use of it. However, I can say this is quite clearly on my mind now as a thing to accomplish this year (as soon as possible). I really need to do a complete hardware regrade/upgrade with more internal storage availability, with Workstation Pro and Vimalin then running on a more realistic storage/functional desktop than the one I'm using at present.

Thanks so much (…) for all your help Wil.

[wila]

Hi,

You're welcome.

I'm happy to hear it helped. It is a trick I learned from our local data recovery wizards Ulli and Andre, so as far as I'm concerned, the praise goes to them.

Re. what happened. Personally I do not think that the windows update is to blame. As you have more than just a VM failing, the usual suspect is the physical hard disk.

If OTOH there was a power loss then that also could have been a cause.

For the moment I suggest to be a bit careful with your data and keep a copy on an external disk.

--

Wil