Using Windows Tools

The first and very natural thing to do is to try out what Windows Boot Manager had suggested. It’s quite easy to attach a disc to the virtual machine and change the boot order from the Settings dialog for the virtual machine in Fusion. There is no surprise that the Windows booted up successfully from the disc. But after running the “Repair Your Computer” and reverting back to hard drive boot, we got the exactly the same result as before: 0xc0000225 error.

After searching for solution for the status code 0xc0000225, I found it’s mainly caused by missing or corrupted BCD (Boot Configuration Data). Here is a Microsoft KB coming to help. The basic idea is to use the bootrec.exe from the command line, and fix BCD. Running the commands as suggested was successful, but rebooting the Windows 7 from hard drive (VMDK) again got the same error.

Back to VMware Fusion

Because of no luck with Windows, I had to come back to the Fusion for further diagnosis. The error message suggested that “a required device is inaccessible.” That explained well why it could not boot. The question is what the device is. Almost all the devices like mouse, NIC can be missing for booting, except that the device the Windows boots from like hard drive, CD, etc. The inaccessible device must be the partition to load Windows.

After randomly hitting Enter and ESC keys, I got into BIOS windows and sometimes red screen of Grub4Dos (more later). Initially, the primary disk cannot be discovered in BIOS. It shows none there. After going back to the vmx file of the virtual machine, and modifying the disc from SCSI to IDE, the BIOS started to show the disk correctly. A good progress there! Looking back, I still don’t understand why the Windows Boot Manager could run without the disk being correctly recognized by the BIOS earlier.

Occasionally, the console got into the red screen of Grub4Dos – another factor that complicated the issue. The virtual machine has a Grub4Dos for multiple booting, but really only one OS is installed. Because you can run multiple operating systems easily with multiple virtual machines, and even better you can run multiple operating systems at the same time, I don’t see why Grub4Dos was used. Using the Grub command line can list the files on the disk and I could see win7ldr there with a few others files.

Anyway, there is still no luck with various BIOS settings. It’s a job that needs lot of patience and disciplines to try and track various combinations, and a strong heart to accept that it didn’t work in the end. :)

Bootable ISOs

There is a tool called “boot repair disk” from sourceforge site. It’s bootable CD image that helps to repair boot issues. It’s not Windows at all, but from the comment, I could see it works for Windows as well.

Downloading the iso is easy, so is to point virtual machine to boot from the CD. It’s fairly easy to use. After running the repair, the original disk could not boot still.

Then, I got a link to Microsoft liveCD kind of image which was released as fix to the KB2840165. Somehow it could boot but failed in the middle so I had not got a chance to see what had been on the screen. Maybe the virtual machine did not have the same issue as the KB intends to solve.

Running out of options, I started to try a commercial version tool that claims to guarantee recovery of the 0xc0000225 problem. This is a tool very similar to the boot repair CD but built on top of FreeBSD instead of Ubuntu. Maybe because the problem was very unique, the tool did not repair the problem in the end.

Direction Change

The original goal was to recover the Windows 7. It did not seem to be doable after quite some time and trials of many tools. Even if doable in theory, it may not worth the time and efforts in practice. The really important part is the data in the virtual machine disk, so we changed the direction from recovering the virtual machine to moving out the data out of the corrupted VMDK file.

With that in mind, I came across a great article. The article is very well written with clear logic and easy to follow steps, so I don’t need to repeat it here. I highly recommend you to bookmark the site as well. I don’t know the author at all but recommend purely based on the great content.

With a little hope, I tried the testdata utility from cgsecurity.org as suggested to see if I could recover the partitions, but with no good luck there. As last resort, I had to try the photorec by the same organization, which can scan the disk blocks without meta data.

And it worked!

While the idea is simple, but the implementation is not. First, you have to allocate enough space for storing recovered files and then moving them out the virtual machine. For that, I created a new VMDK and mounted it to the file system. Then, you need to move the recovered data out of the virtual machine. All has to be done in a less performant (virtual) machine than a physical machine. Make sure you turn off the sleep timeout for this. Otherwise, you think the machine will continue to work hard as you go to sleep but only find later it goes to sleep too.

Because there is no meta data about the file system hierarchy, the recovered files were flattened out. For better organization, files were saved to recup_dir.x folders where x could be different integers. Most of the files are named as fxxxxxxxx.y with a few exceptions in which valid file names do show up.

Luckily, the file extensions are mostly correct. For example, a JPEG image file is named as f12345678.jpg. Although you don’t know the exact names, we can open them and see what are there. You can also find and copy all the jpg, doc, and other files out to any directory using a simple Linux command.

$ find /olddir -name “*.doc” –exec cp {} newdir \;

Not a perfect ending, but still a good one. In different cases, you may be luckier to get the virtual machine repaired, so you don’t need to read to the very end.

Reference: http://www.doublecloud.org/2015/03/how-to-recover-corrupted-virtual-machine-in-vmware-fusion/