Technical Writings
- C++ Concurrency Book
- Articles and Publications
- Conference Presentations
- Recent Blog Entries
- Multithreading Blog Entries
- C++ Blog Entries
Subscribe to Blog
Blog Archives
Importing an Existing Windows XP Installation into VirtualBox
Wednesday, 03 June 2009
On Monday morning one of the laptops I use for developing software died. Not a complete "nothing happens when I turn it on" kind of death — it still runs the POST checks OK — but it won't rebooted of its own accord whilst compiling some code and now no longer boots into Windows (no boot device, apparently). Now, I really didn't fancy having to install everything from scratch, and I've become quite a big fan of VirtualBox recently, so I thought I'd import it into VirtualBox. How hard could it be? The answer, I discovered, was "quite hard".
Since it seems that several other people have tried to import an existing Windows XP installation into VirtualBox and had problems doing so, I thought I'd document what I did for the benefits of anyone who is foolish enough to try this in the future.
Step 1: Clone the Disk into VirtualBox
The first thing to do is clone the disk into VirtualBox. I have a handy laptop disk caddy lying around in my office which enables you to convert a laptop hard disk into an external USB drive, so I took the disk out of the laptop and put it in that. I connected the drive to my linux box, and mounted the partition. A quick look round seemed to indicate that the partition was in working order and the data intact. So far so good. I unmounted the partition again, in preparation for cloning the disk.
I started VirtualBox and created a new virtual machine with a virtual disk the same size as the physical disk. I then booted the VM with the System Rescue CD that I use for partitioning and disk backups. You might prefer to use another disk cloning tool.
Once the VM was up and running, I connected the USB drive to the VM using VirtualBox's USB support and cloned the physical disk onto the virtual one. This took a long time, considering it was only a 30Gb disk. Someone will probably tell me that there are quicker ways of doing this, but it worked, and I hope I don't have to do it again.
Step 2: Try (and fail) to boot Windows
Once the clone was complete, I disconnected the USB drive and unmapped the System Rescue CD and rebooted the VM. Windows started to boot, but would hang on the splash screen. If you're trying this and Windows now boots in your VM, be very glad.
Booting into safe mode showed that the hang occurred after loading "mup.sys". It seems lots of people have had this problem, and mup.sys is not the problem — the problem is that the hardware drivers configured for the existing Windows installation don't match the VirtualBox emulated hardware in some drastic fashion. This is not surprising if you think about it. Anyway, like I said, lots of people have had this problem, and there are lots of suggested ways of fixing it, like booting with the Windows Recovery Console and adjusting which drivers are loaded, using the "repair" version of the registry and so forth. I tried most of them, and none worked. However, there was one suggestion that seemed worth following through, and it was a variant of this that I finally got working.
Step 3: Install Windows into a new VM
The suggestion that I finally got working was to install Windows on a new VM and swipe the SYSTEM registry hive from there. This registry hive contains all the information about your hardware that Windows needs to boot, so if you can get Windows booting in a VM then you can use the corresponding SYSTEM registry hive to boot the recovered installation. At least that's the theory; in practice it needs a bit of hackery to make it work.
Anyway, I installed Windows into the new VM, closed it down rebooted it with the System Rescue CD to retrieve the SYSTEM registry hive: C:\Windows\System32\config\SYSTEM. You cannot access this file when the system is running. I then booted my original VM with the System Rescue CD and copied the registry hive over, making sure I had a backup of the original. If you're doing this yourself don't change the hive on your original VM yet.
The system now booted into Windows. Well, almost — it booted up, but then displayed an LSASS message about being unable to update the password and rebooted. This cycle repeats ad infinitum, even in Safe Mode. So far not so good.
Step 4: Patching the SYSKEY
In practice, Windows installations have what's called a SYSKEY in order to prevent unauthorized people logging on to the system. This is a checksum of some variety which is spread across the SAM registry hive (which contains the user details), the SYSTEM hive and the SECURITY hive. If the SYSKEY is wrong, the system will boot up, but then display the message I was getting about LSASS being unable to update the password and reboot. In theory, you should be able to update all three registry hives together, but then all your user accounts get replaced, and I didn't fancy trying to get everything set up right again. This is where the hackery comes in, and where I am thankful to two people: firstly Clark from http://www.beginningtoseethelight.org/ who wrote an informative article on the Windows Security Accounts Manager which explains how the SYSKEY is stored in the registry hives, and secondly Petter Nordahl-Hagen who provides a boot disk for offline Windows password and registry editing.
According to the article on the Windows Security Manager, the portion of the SYSKEY store in the SYSTEM hive is stored as class key values on a few registry keys. Class key values are hidden from normal registry accesses, but Petter Nordahl-Hagen's registry editor can show them to you. So, I restored the original SYSTEM hive (I was glad I made a backup) and booted the VM from Petter's boot disk and looked at the class key values on the ControlSet001\Control\Lsa\Data, ControlSet001\Control\Lsa\GBG, ControlSet001\Control\Lsa\JD and ControlSet001\Control\Lsa\Skew1 keys from the SYSTEM hive. I noted these down for later. The values are all 16 bytes long: the ASCII values for 8 hex digits with null bytes between.
This is where the hackery comes in — I loaded the new SYSTEM hive (from the working Windows VM) into a hex editor and searched for the GBG key. The text should appear in a few places — one for the subkey of ControlSet001, one for the subkey of ControlSet002, and so forth. A few bytes after one of the occurrences you should see a sequence of 16 bytes that looks similar to the codes you wrote down: ASCII values for hex digits separated by spaces. Make a note of the original sequence and replace it with the GBG class key value from the working VM. Do the same for the Data, JD and Skew1 values. Near the Data values you should also see the same hex digit sequence without the separating null bytes. Replace that too. Now look at the values in the file near to where the registry key names occur to see if there are any other occurrences of the original hex digit sequences and replace these with the new values as well.
Save the patched SYSTEM registry hive and copy it into the VM being recovered.
Now for the moment of truth: boot the VM. If you've patched all the values correctly then it will boot into Windows. If not, then you'll get the LSASS message again. In this case, try booting into the "Last Known Good Configuration". This might work if you missed one of the occurrences of the original values. If it still doesn't work, load the hive back into your hex editor and have another go.
Step 5: Activate Windows and Install VirtualBox Guest Additions
Once Windows has booted successfully, it will update the SYSKEY entries across the remaining ControlSetXXX entries, so you don't need to worry if you missed some values. You'll need to re-activate Windows XP due to the huge change in hardware, but this should be relatively painless — if you enable a network adapter in the VM configuration then Windows can access the internet through your host's connection seamlessly. Once that's done you can proceed with install the VirtualBox guest additions to make it easier to work with the VM — mouse pointer integration, sensible screen resolutions, shared folders and so forth.
Was it quicker than installing everything from scratch? Possibly: I had a lot of software installed. It was certainly a lot more touch-and-go, and it was a bit scary patching the registry hive in a hex editor. It was quite fun though, and it felt good to get it working.
Posted by Anthony Williams
[/ general /] permanent link
Tags: virtualbox
Stumble It! 
| Submit to Reddit 
| Submit to DZone 
If you liked this post, why not subscribe to the RSS feed 
or Follow me on Twitter? You can also subscribe to this blog by email using the form on the left.
Design and Content Copyright © 2005-2024 Just Software Solutions Ltd. All rights reserved. | Privacy Policy
14 Comments
Hi!
I had a HDD -soon to be removed from case- and wanted to "reincarnate" the existing semi-inactive windows xp installation in VBOX.As long as i had no usb drive, i followed the next procedure which worked like a charm.(more time consuming though, i think) REQUIRED SOFTWARE : a. Acronis True image boot CD, b. UltraISO
1) create a new VM and a new fixed Virtuall HDD a bit bigger than the image i was to restore 1a) create 2 optical drives.. in Vm settings
2) uninstalled all ide/vga/sound drivers from native installation ->shutdown (DO NOT boot after this point again to the native OS) 3) boot with "Acronis True Image Home 2010 boot cd" -> create backup of disk(max compression preferred) 4) make a UDF/DVD .iso file from the previous acronis image, with UltraISO 5) mount in 1st cdrom the Acronis Boot CD, and in 2nd the .iso you created b4 6) boot VM and restore disk form previous created image. 7) let the system configure its devices at 1st boot and voila.
after configuring the new devices, on the next reboot the system was like using the native one:) , hope helped.
forgot to add that at 7) you need to boot at safe mode 1st, and after devices instalation to reboot at normal boot
ok.... you can instal xp and software into VirtualBox etc
BUT if you have an XP host system, can you migrate a program from the virtualbox etc xp environment BACK into the XP host system
sounds daft.... DON'T ASK.... but I need to do it
Your post on migrating a Windows OS to VirtualBox was helpful. I went through the steps you did and also could not get past the "mup.sys" hang after many, many tries, but finally I did this: on the source machine, before capturing the disk image, go to the device manager and change the IDE driver from whatever it is to the "standard IDE driver". (Select update, don't have the OS search, tell it you have your own driver, then it will give you a dialog where you can select the standard IDE driver.) Save that, reboot, then reimage the drive, convert the image to a .vdi. It then worked on first boot in VirtualBox! I did not have to reinstall or even do a repair install, hooray.
using Ulitmate Boot CD can do Chris's method (it certainly uses the intelide.sys) go to start, programs, registry tools, FIX_hdc, Fix hard disk controller.
it works but now it asks to activate !
found this by "the sasquatch" Boot into "Safe Mode". To do this, turn the laptop on and press F8 as it is booting up. Go into "Safe Mode" by choosing the "Safe Mode" option. Once you are at the desktop in "Safe Mode", Click "Start" then click "Run". At the run command prompt type the following EXACTLY
rundll32.exe syssetup,SetupOobeBnk
*NOTE: The "Oo"'s in Oobe are "oh's" - not "zero's" There is one space after rundll32.exe. It is case sensitive as far as I know.
Click OK
Wait a few seconds - the screen may blip a few times or so.
This just reset Windows Activation for 30 days.
Reboot the PC into normal mode - log in - re-activate Windows
It should be noted that most of these problems have to do with problems moving windows to new hardware, not the cloning process itself. The same problems face those trying to move an existing physical windows disk to a new physical computer.
Good morning, I used to work for a college and was in charge of getting the same image to work across any system we could throw at it. Perhaps the most difficult operations where moving Windows Server 2003 installations from high end server-class hardware down to conventional desktop machines. There where quite significant hardware variances between them.
I have three options that come to mind as possibly less involved operations, depending on a reader's situation. I know using sysprep or similar tool was probably out for you since you couldn't boot into Windows, so I won't spend any time on that.
1) Install Windows fresh into your VM, connect your external USB disk, in Windows, and use NTBACKUP. Restore this back up on top of your fresh installation. There are two tricks - you can tell NTBACKUP which parts of the registry NOT to restore (http://windowsitpro.com/article/articleid/76145/jsi-tip-4839-how-do-i-move-windows-xp-to-different-hardware.html) in this case, you don't want to replace any of the driver/hardware information, as outlined in that article. There is an option in NTBACKUP when performing a restore that allows you to overwrite any existing files. You want to select that option. Boot up, worked a solid 9 out of 10 times for me.
2) "STOP 0x7B Fix" as we used to call it. Often times if you move a system to new hardware, the first and only error you get is a blue screen that may say "STOP 0x0000007B INACCESSIBLE_BOOT_DEVICE" This occurs often because the new system/virtualized system has a different disk controller (different flavor/brand of IDE or SATA controller for instance) and when Windows goes to take control of the hardware, it can't the necessary controller driver. You would perform the following onto your OLD installation (or your newly imported disk image):
As outlined in http://support.microsoft.com/kb/314082 essentially you create the registry patch in the article, apply it to the system, and copy of all of the generic disk controller drivers from the Windows CD, and put them into C:\Windows\System32\drivers. Again, of course you don't have access to the old Windows in a running state. You've got solid linux experience, so the following shouldn't be too scary: Mount your imported disk image using the loopback device, copy the driver files into it, then, mount the old SYSTEM hive temporarily into your new Windows installation, and apply the patch that way. You would need to search/replace all of the HKEY_LOCAL_MACHINE in the registry patch to HKEY_<wherever you've mounted the hive> to be sure they get applied to the mounted hive and not your fresh Windows system.
#2 really only works though if you're simply getting the STOP 0x7B error. And it is easier than it sounds!
3) If you've got the means I believe a product like Ghost or Acronis would be able to image your system from disk and such it into your new system. VMWare Converter might be able to do it too.
Also VirtualBox has a cool option where you can create a VMDK file that is simply a reference to your external disk, thus you could run it from your real external disk! It's always of course better to use or have backup, but the option is available.
I've never done the method you outlined, but I have had a couple instances where the top two options did NOT work and yours provides something I'll try if I'm in the situation again. Great post! -JJust an FYI:
I'm attempting to do a Windows to Linux howto and am scouring for ways for the average user to do this with their existing PC with a native WinXP installed..
Here's the link: http://grahams.free-online.co.uk/winxpvmconvert.html
I have a few "used" installations from where I work on which I am experimenting.
Very good post and thanks.
I'm going to see if I can make it work reliably and easily (for the average WinXP user).Why not clone the disk to virtual (will not boot), and run a normal XP repair installation? Should be a much quicker process.
My problem was that VBox adds the image file as a SATA-drive. Whatever I did (and whichever format I used), it wouldn't work (BSOD complaining of hardware failure).
However, once I added the drive as an IDE-drive instead, a current version of VirtualBox managed to start the OS even when I just copied the vhd (VPC-disk image) with only the following changes: I removed the integration software, I made sure it was properly shutdown, and had no unapplied undo disks.
Hope this helps...
/Erik
"It seems lots of people have had this problem, and mup.sys is not the problem"... Yes, it is - the mup.sys has something to do with the multi-processor kernel (on XP) and since people normally are moving to a virtual machine with just one processor the kernel fails to start. This can be fix with the latest VM software, in virtualbox I can now set the virtual machine for two processors and then the machine load's "fine" (after that is just a mather of proper drivers).
Hope this help someone else...This method also helps, try at www.sysprobs.com/physical-virtual-virtualbox-virtualbox-p2v
I was able to use Jeremy Strong's idea to fix the STOP 0x00007B error after cloning my laptop drive to a virtualbox machine. Here's a bit more detail on how it works: Install a fresh copy of XP as a virtual machine. Or you can probably use any virtual version of windows. In the working virtual windows installation, add the .vdi file of the machine that won’t boot as a slave drive. Make sure the IDE controller is set to "Intel PIIX4". I also checked the "IO APIC" option (not sure if it matters). Boot the working windows. Open Notepad and paste this in: Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\TEST\ControlSet001\Control\CriticalDeviceDatabase\pci#ven_8086&dev_7111] "ClassGUID"="{4D36E96A-E325-11CE-BFC1-08002BE10318}" "Service"="intelide"
;Add driver for intelide (requires intelide.sys in drivers directory)
[HKEY_LOCAL_MACHINE\TEST\ControlSet001\Services\IntelIde] "ErrorControl"=dword:00000001 "Group"="System Bus Extender" "Start"=dword:00000000 "Tag"=dword:00000004 "Type"=dword:00000001 "ImagePath"=hex(2):53,00,79,00,73,00,74,00,65,00,6d,00,33,00,32,00,5c,00,44,00,\ 52,00,49,00,56,00,45,00,52,00,53,00,5c,00,69,00,6e,00,74,00,65,00,6c,00,69,\ 00,64,00,65,00,2e,00,73,00,79,00,73,00,00,00
Save the above to your desktop as "Test.reg". Run "regedit" Click HKEY_LOCAL_MACHINE File > Load Hive… In the Load Hive... file dialog, browse to the slave drive (the one containing the windows installation that won't boot) and load from the slave drive "Windows\System32\config\system" Name the loaded hive “TEST” Double click the Test.reg file you saved to your desktop and tell it you want to add it to the registry. Back in regedit, click TEST, then choose File > Unload Hive… Copy C:\WINDOWS\system32\drivers\intelide.sys to the same location on the slave drive if it isn’t there already. Shut down the working windows (don't just hibernate it, shut it down). Boot the broken system and it should work.