Tiger wins this round. For the second time in two months, a Windows image in Parallels was corrupted, leading this blogger down a winding path of frequent visits to the friendly tech-stop at the Google NYC offices. Unlike the last time when the entire machine was corrupted (score +1 for Windows) this time the damage was limited to the Windows XP side, with the host OS-X showing no signs of malfunction. (score +1 for Mac, previous corruption avenged.)
Meanwhile Windows started to blue-screen very early on in the boot process, while loading the mup.sys driver, complaining about missing registry hive. Since that is a fairly vital piece of the system, booting into safe-mode or last known-good configuration wouldn’t help. It took some time to track down an XP image to launch into recovery console– first sign that one is no longer working at MSFT where there are copies of every SKU of Windows imaginable floating around, just in case you needed to boot Server 2003 R2 Enterprise edition on x64 out of curiosity. But recovery console required the local administrator password, and not just any user in the admins group. (Since AD domain logon is not available in the limited recovery environment.) Neither the blogger nor tech-stop folks could track that down. No problem, since many live Linux CDs allow mounting NTFS and scrambling the SAM to blank-out admin password. That didn’t work either when the first one tried complained about file-system corruption and mounting in read-only mode only.
At this point, re-installing the OS was starting to become the path of least resistance when considering that Parallels ships with an application that can mount the Windows image offline as a drive and recovery any files. (This is similar to vhdmount utility from Virtual Server R2 pack.) One problem there– the BIOS emulated by Parallels can not do PXE boot. This is a Parallels limitation since the MSFT offerings Virtual PC and Virtual Server installed on a desktop had no problem starting with a blank image and booting into a PE environment used at Google for network installs. The missing piece of the puzzle had to be provided by tech-stop folks, a floppy image to bootstrap the PXE process. (Virtualization has its ironies– remember how Apple was skewered for not including floppy drives with the iMac in 1998?)
After that the installation more or less proceeded on automatic pilot, although host integration was missing until installing Parallel tools later.
Time wasted: Roughly four hours, spread across two days.
Current standings: Macintosh evens up the score against Windows, tied game. It is time to reconsider that “snapshot” feature in Parallels. Comparison point: in 2+ years of using MSFT virtualization platforms, not a single image has been corrupted or hosting machines inexplicably toast in the process.