3

What i want to do:

I'm trying to virtualise 2 different physical Windows XP systems which reside on one hard drive each to VirtualBox under Windows 7.

What I did (once per drive):

From a Linux system:

dd if=/dev/sd(disk) of=d1.img conv=noerror,sync bs=64k

From the Windows 7 system

vboxmanage convertfromraw d1.img d1.vdi

Where I'm at:

During boot of either VM, Windows seems to hang (in safe mode) at loading mup.sys. In normal boot it's just a blank screen. I've not really got a whole lot to go on, so any points to get more debugging output would also be good.

I'm pretty sure I've used this method previously for Linux and similar systems, am I doing something dumb here? My knowledge of VirtualBox is pretty limited compared to Xen or KVM.

4 Answers 4

5

The repair option works but it is because you used a boulder for the nail instead of a faster hammer, the specific issue is with the hal.dll (hardware abstraction layer) which was designed for your original physical box and its inability to interpret the new VM.

Short version if you're in a hurry, copy a working hal.dll from a identical or as similar working VM to your non booter and you'll avoid the necessity of performing the Install / Repair process.

By trudging through the entire repair process you'll successfully install a working HAL but that is the longest and most time consuming method. The quickest method is leveraging other working VM's with as close as possible / identical similar SP and patch revisions since some Microsoft patches will replace key system dll's like HAL and copy a working HAL.dll into the malfunctioning VM's %systemrootn%\system32 after you've renamed the defective one to anything you want.

If you don't have a library of working VM's, you can still use the install CD you were using before for the full recovery method and save lots of time by booting into the (interactive) Recovery Console that is one of Microsoft's best attempts at SingleUserMode.

You should have a numbered list of detected OS folders, even a single boot system will still have one Windows directory labeled (1), select the damaged build and you'll be prompted for the passwords and dropped into a shell at the root of c:\windows or whatver your unique drive letter and directory (%systemroot%)

Archive up the damaged Hal.dll in case we need it again for the reasons we can't think of for the moment. ren system32\hal.dll hal.dllBROKE

From your install CD, find halacpi.dl_ (usually i386\halacpi.dl_) and use the expand command after renaming the malfunctioning HAL, the availability of environment variables will vary based on OS and revision and so be prepared to use explicit paths like:

expand halacpi.dl_ c:\windows\system32\hal.dll Or try environment variables if available for assurance expand halacpi.dl_ %systemroot%\system32\hal.dll

Some versions of XP, 2003 server /2003R2 also have a raw HAL.dl_ on the install media, while you're here go ahead and expand it for safety in case our halacpi.dll expansion fails:

expand hal.dl_ c:\windows\system32\hal2.dll

Exit the repair menu and reboot, more than likely you're boot process will succeed or at least proceed past the mup.sys / hang point in the past. However, since you've been repeatedly rebooting this VM don't be surprised if you have a dirty disk requiring a five stage chkdsk for NTFS volumes, fully three stages for Fat32/Fat16 volumes. Depending on how badly munged the disk is, it may not successfully repair itself and freeze at "Checking Disk C" default white text on black DOS window.

This is when you should decide whether to restore your original unaldutrated but non booting VHD and HAL it up or if you have to restore this problematic VM that is incapable of fixing itself, mount it as a data drive in a working VM or system and chkddsk as a data drive or using any countless repair BOOT CD's

You might also be well served to relax that boot.ini file on the defective VM that by now you've probably turned into a spiked avenger of debugging with bootlogging, no GUI and SOS flags and add just a default startup entry since improper modifications such as inadvertent word wrapping and smart quotes that invariably seem to invade boot.ini files that were constantly tampered and tested during your period of profane frustration.,

Microsoft Virtual PC, Virtual Server (early additions) admins were daunted by this issue for years since Microsoft wasn't forthcoming about the HAL issues despite their disk2vhd utility, the workarounds were as superstitious as time consuming such as forcibly resizing the physical partition to the hoped for VHD before converting to a VM along with the full repair method.

3

Just posting this up as an answer because it seems to have worked.

I tried doing a repair reinstall off the window xp disk. It seems to have fixed whatever was the issue, and it now boots through correctly.

0

You might want to uninstall all drivers that are in the "Add Remove Programs" menu in Control Panel.

Besides that, go to the device manager, Find the "Hard disk controllers" or "Storage controllers" or "IDE controllers" or similar category, right click on each of the controllers and click uninstall.

Only after you have done these steps, proceed to make an image.

Windows XP is not as flexible as Windows 7 when moving the existing OS to a new motherboard (or, in your case, a VM). If this fails, try the repair option @Sirex suggested.

4
  • Sirex is the one who asked the question in the first place :P
    – slhck
    Mar 7, 2012 at 10:33
  • Wow. I failed to notice that :D I will leave my answer here, though. My approach is less painful then repairing. I also wonder if he can mark his answer as checked... hmmm
    – Kaurin
    Mar 7, 2012 at 11:15
  • i'll try this. oddly, the recovery idea it worked for one of the images, but the other once it seems to have not gone so well :-( its sitting on "windows is starting up" for ages, then reboots
    – Sirex
    Mar 7, 2012 at 11:44
  • Give us a shout if it works. It does not always work, but it's worth a try. I will edit my answer in a minute to suggest one more thing!
    – Kaurin
    Mar 7, 2012 at 12:25
0

Check the APIC setting of the VM, it must match the APIC presence or absence of the times when Windows was installed.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .