Boot problem on cloned dual-boot SSD

[amblabs]

I have an MSI laptop originally equipped with a Western Digital WD3200BEVT 320GB SATA HDD, with Windows 7 Ultimate x64 and Windows XP Professional SP3 on different partitions set for dual boot (with EasyBCD). It was working perfectly and able to boot into either OS via a boot menu.


I used Acronis True Image WD Edition to clone that HDD to a new Western Digital WDS500G2B0A 500GB SATA SSD. The process went without a hitch and I installed the new SSD in place of the original HDD. The boot menu appears normally and I can boot Windows 7 with no problem, but it fails when I tried to boot Windows XP. The Windows XP startup splash screen appears, but then the computer simply resets itself and goes to BIOS POST again.

The Windows 7 partition is drive C, the Windows XP partition is drive D. I can see both partitions when booted on Windows 7 and the filesystems are OK.

I tried swapping back to the old HDD and it still boots both OSes successfully.

I also tried re-doing the clone with EaseUS Todo Backup, and the same thing happened.

Why can’t the new SSD boot Windows XP? I tried searching the web but I can’t find a solution to this yet.


[I realize this is a forum for Windows 7, not Windows XP, but there is no XP-specific forum here so I apologize and hope that someone would be able to assist anyway]

 

[iko22]

Hello amblabs, welcome to seven forums

1. Did you run a CHKDSK of the XP partition, before cloning the HDD?
2. If CHKDSK is clean, then check as many of following as you can, on the cloned disk: 10 things you can do when windows xp wont boot.
3. If still no luck, post your question on the Acronis or EaseUs forums.

 

[johnhoh]

I'm wondering if your new drive is GPT instead of MBR and your winXP is 32-bit. Cloning tools don't necessarily convert the target disk's partition type to match the source disk's. I suggest this because win7 will boot with either type but XP 32-bit requires MBR. You can fix this by converting the new disk to MBR. You may have to reclone after converting.

Convert GPT to MBR

 

[amblabs]

iko22
I did do a chkdsk on the D: drive before cloning, as well as after on the clone too. No problems found. Thanks for the link, I'll have a look at that site.

johnhoh
The SSD was brand new and uninitialized, so no MBR or GPT to start with. The original HDD was MBR (the laptop is an older model that doesn't support GPT), and the cloning process initialized the SSD to be MBR too. Since the SSD is 500B compared to the original HDD's 320GB, I did allow the cloning to increase the new partition sizes on the SSD to use the additional space. And yes, the Windows XP installed on there is 32-bit.


Anyone else with suggestions please feel free to chime in.

 

[johnhoh]

my only other idea is to clone with macrium reflect and see if it produces better results. I've tried them all and imo its the best.

 

[dg1261]

Those symptoms are not altogether surprising given that you are using Microsoft's half-baked method of pseudo dual-booting. (I can tell you used Microsoft's method because you mentioned setting it up with EasyBCD.) Truly independent partitions have fewer problems multi-booting.

But there's not enough information to tell if that's really your problem, so at this point that may just be the snark coming out. (I despise the Microsoft method.)

Perhaps you could provide additional information. Connect the new drive and boot into the 7 clone, which you said boots fine. Then:

1. Post a Disk Management screenshot. This should confirm that the partition layouts of the two disks are the same. Make sure we can tell which are the "Active", "System" and "Boot" partitions.
   
   
2. Post the contents of XP's boot.ini file. Open a cmd prompt window as admin, enter "type d:\boot.ini" and copy/paste the contents. (Don't forget to open as admin or you'll get "Access denied".)
   
   
3. Use regedit and expand the [HKLM\System\MountedDevices] key. Post the two lines "DosDevices\C:" and "DosDevices\D:" for review.
   
   
4. Open the XP partition's System hive as a branch under the Win7 registry. In regedit click to select the HKLM branch, then select "File>Load Hive" from the menu bar. Navigate and select the file "d:\windows\system32\config\system". Give the loaded hive a unique name, such as "XP-System". Expand the newly loaded [HKLM\XP-System\MountedDevices] key and post the lines "DosDevices\C:" and "DosDevices\D:" (if present).
   
   This allows us to compare the partition signatures that 7 and XP are considering the C: and D: drives.
   
   
5. Finally, disconnect the XP hive from the 7 registry. Click to select the [HKLM\XP-System] branch and on the regedit menu bar select "File>Unload Hive".

Attached are a few sample screenshots to give you an idea what you're looking for. (Note my C: and D: are on different disks, though yours will be on the same disk, I presume.)

 

[amblabs]

dg1261
Thanks for the reply. Here are what you requested. They are taken while booted on the cloned SSD under Win7.


1. Disk Management screenshot (C: is the Win7 partition, D: is the WinXP partition, The 10GB partition in the beginning of the disk is a recovery partition with no drive letter assigned, and the 100MB is a "System" partition also with no drive letter assigned).

2. There is no boot.ini file on the XP (D partition, there is one on the Win7 (C partition (contents below). I checked and this is true on the original HDD as well as the new SSD.

3. regedit [HKLM\System\MountedDevices]:

4. regedit [HKLM\XP-System\MountedDevices] after "Load hive":

Looks like the DosDevices\C and DosDevices\D entries between the two are indeed different! Have we found the problem?



Finally, here is a screenshot of the EasyBCD "view" of the dual-boot configuration:

 

[SIW2]

4. regedit [HKLM\XP-System\MountedDevices] after "Load hive":

There is no screenshot attached

 

[amblabs]

Oops, it was a file permissions problem with the image. The post above shows the screenshot properly now.

 

[dg1261]

Looks like the DosDevices\C and DosDevices\D entries between the two are indeed different! Have we found the problem?

Yeah, I think we're zeroing in on it.

First, though, that Disk Mgmt screenshot contains an oddity. Both partitions 3 and 4 are marked "Active", which should normally be a fatal boot condition. There should only be one Active partition, and in your case that appears to be the third partition. Maybe Disk Mgmt is wrong, or maybe you really do have two Active partitions. I've never seen the latter condition before, but if it's booting I'll ignore it for now and we should just keep in mind that maybe there's more than one problem here.

Boot.ini is supposed to be on the Active partition, so if it's on C: that supports the interpretation that the third partition is your real Active partition.

The contents of boot.ini look fine. It's saying XP is on the fourth partition, which it is. It also has a comment at the top that EasyBCD edited it, which lends further credence that it's now adjusted correctly, so no need to tinker with boot.ini.

The two regedit screenshots reveal what may be the main problem. The values of C and D should be similar between the two registry hives (the 7 hive and the XP hive).

The values shown indicate the original HDD had a DiskID of "4f be a1 0f" while the new SSD's DiskID is "6c 73 52 e0". (The remaining 8 bytes of each entry are the starting sector number of the specified partition on that disk.) You'll note the XP registry hive is still looking for C and D on the original disk, not the SSD. It can't find itself, so it's failing to boot.

Before correcting, it's relevant to know which partition you want XP to see as C and which D. The fourth screenshot suggests the old XP system saw itself as D: rather the more typical C: when it was booted. Is that correct? (IOW, 7 and XP both saw the 3rd partition as C: and the 4th partition as D: regardless of which OS you booted.)

If XP is supposed to see itself as D: then DosDevices\C and DosDevices\D should be exactly identical between the two MountedDevices branches.

Load the XP hive again and carefully edit those two entries in XP-System so they're identical to what you see in Win7's MountedDevices. Then unload the hive and see if XP will now boot correctly.

 

[SIW2]

The fourth screenshot suggests the old XP system saw itself as D:

What makes you think that?

Does the XP registry store the drive letter in HKLM\Software\Microsoft\Windows NT\CurrentVersion /v PathName ?

 

[amblabs]

First, though, that Disk Mgmt screenshot contains an oddity. Both partitions 3 and 4 are marked "Active", which should normally be a fatal boot condition. There should only be one Active partition, and in your case that appears to be the third partition. Maybe Disk Mgmt is wrong, or maybe you really do have two Active partitions.

I manually made partition 4 active just to see if it made any difference, it didn't. My previous screenshot was in that state. I have since turned of the active state of that partition, it now looks like this:

The two regedit screenshots reveal what may be the main problem. The values of C and D should be similar between the two registry hives (the 7 hive and the XP hive).

The values shown indicate the original HDD had a DiskID of "4f be a1 0f" while the new SSD's DiskID is "6c 73 52 e0". (The remaining 8 bytes of each entry are the starting sector number of the specified partition on that disk.) You'll note the XP registry hive is still looking for C and D on the original disk, not the SSD. It can't find itself, so it's failing to boot.

Yup. that makes sense. The cloning process apparently did not touch the XP partition's registry, so it still has the old data from the HDD. It seems to have fixed Win7's registry to match the new DiskID.

Before correcting, it's relevant to know which partition you want XP to see as C and which D. The fourth screenshot suggests the old XP system saw itself as D: rather the more typical C: when it was booted. Is that correct? (IOW, 7 and XP both saw the 3rd partition as C: and the 4th partition as D: regardless of which OS you booted.)

Yes, both OSes saw partition 3 as C: and partition 4 as D:.

If XP is supposed to see itself as D: then DosDevices\C and DosDevices\D should be exactly identical between the two MountedDevices branches.

Load the XP hive again and carefully edit those two entries in XP-System so they're identical to what you see in Win7's MountedDevices. Then unload the hive and see if XP will now boot correctly.

I did this to make the DosDevices\C and DosDevices\D under the XP-System hive match those in HKLM\System\MountedDevices. Unfortunatey, that didn't fix the problem. The XP boot splash appears followed by a reset back to POST.

I noticed that there were other Volume entries under the XP-System hive that also had the old signature. In fact there were a couple that matched the old DosDevices\C and DosDevices\D entries exactly. So I edited those too. I left the others with the old DiskID signature alone, as they seem to pertain to other drive letters that aren't being used. This is what it looks like now:

But XP still doesn't boot -- same symptoms. What else should I look at?

 

[SIW2]

They are inverted in your XP hive. Should normally be

\DosDevices\C should have 4d 00 00 00 at the end

\DosDevices\D should have 02 00 00 00 at the end

 

[amblabs]

They are inverted in your XP hive.

\DosDevices\C should have 4d 00 00 00 at the end

\DosDevices\D should have 02 00 00 00 at the end

Really? Shouldn't these match those under Win7 exactly? The respective partitions' drive letter assignments are the same whether I boot Win7 or XP. I.e., C: is the Win7 partition and D: is the XP partition no matter which OS I boot.

 

[SIW2]

If XP os letter is D in the software hive, it looks ok.

 

[amblabs]

If XP os letter is D in the software hive, it looks ok.

It should be D:, but how do I check this? Where is the XP software hive that I could load from Win7?

 

[SIW2]

"d:\windows\system32\config\software".

 

[amblabs]

OK, it is indeed D:\WINDOWS

XP still doesn't boot. What else to look at?

 

[dg1261]

The fourth screenshot suggests the old XP system saw itself as D:

What makes you think that?

I went by the fact the partition signatures in the XP System hive showed D was behind C, further toward the end. (The format of the partition signatures is detailed on my webpage.) Presuming XP was also the 4th partition on the old HDD as it is now on the SSD, that implied XP must have seen its own Boot partition as D.

 

[dg1261]

I noticed that there were other Volume entries under the XP-System hive that also had the old signature. In fact there were a couple that matched the old DosDevices\C and DosDevices\D entries exactly. So I edited those too. I left the others with the old DiskID signature alone, as they seem to pertain to other drive letters that aren't being used.

No, the Volume entries should not be edited.

Those are a history of every partition or device the OS has ever seen attached, such as external drives, usb flash drives, other CD/DVD drives, etc. The Volume entries are some kind of conversion of device IDs to GUIDs, perhaps for use in the areas of the OS that reference devices by GUID. I'm not sure what those areas would be, but manually editing them might create GUID conflicts. The system generates the GUIDs as necessary, so don't try to edit them.

In fact, you can even completely delete the Volume entries and the OS will regenerate them as needed. I routinely delete all Volume entries (and all stale DosDevices entries) when I'm imaging an OS to move to another partition or hard disk. That way, there won't be detritus carried over when the OS is restored, and the restored OS will regenerate GUIDs for just the devices it sees in the new restoration. (Upon first boot you'll see some "Found new hardware" balloons.)

But your post does make me think of a possibility I had not considered before. Curiously, I noticed your 7 and XP hives don't share any of the same GUIDs. I presumed they would since some of the devices (like CD/DVD drives) weren't being changed. I don't sufficiently understand GUIDs or how they're generated, but I wonder if 7 and XP use different algorithms to generate GUIDs for the same devices. If so, the GUIDs you edited could be causing a problem.

We're getting to the limits of my knowledge here, but I think I would try deleting all entries from the XP [MountedDevices] hive except for DosDevices\C and DosDevices\D. Make a backup of the [MountedDevices] key first, just in case you need to put them back. Then reboot. XP should regenerate just the GUIDs it needs, and will associate drive letters based on the partition signatures.

Aside: the reason I normally recommend leaving the DosDevices entries for the OS's "System" and "Boot" partitions is because, when left to makes its own decisions, the OS will regenerate/reassign drive letters in a prescribed sequence, which depending on the system may or may not be what you want. In your case, if there were no DosDevices entries I would expect XP to assign C to partition 3 (because it's the Active partition), D and E to partitions 1 and 2, and F to partition 4. That's the default sequence for assigning drive letters, but it would create havoc for all the programs and parts of the system expecting partition 4 to be D. By predefining DosDevices\D you prevent the OS from giving away that drive letter to something else.