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\hal*2*.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.