Cloned XP system disk to identical disk, rebooted with both in, always BSOD 7B now
I have XP SP3 machine with 2 x WD5000AAKS (500GB) drives, ASUS P5QL PRO mobo. Drives were bought with machine so should be identical. Both were configured as 1 partition each, so C: and D: (they get swapped around shortly so I'll call them WD#1 and WD#2 respectively).
Drives were getting full so I bought a Seagate 3TB disk two days ago. Mobo has only two SATAII connectors so I unplugged WD#2 and connected SG (Seagate). Configured SG as two partitions, 2000GB and 743GB (the 743 is from memory, might be slightly awry). Cut data off WD#1 and pasted onto SG, everything worked great. BIOS was a little confused about the size of the SG but that was as expected for a >2.2TB disk. Rebooting worked fine.
To get WD#2's data onto the SG I started by unplugged SG, reattached WD#2, rebooted. Cut data off WD#2 and pasted onto WD#1 (in preparation for replacing WD#2 with SG and moving the data to it). Moving the data to WD#1 left WD#2 completely empty so I had the 'clever' idea of cloning WD#1 onto WD#2.
I googled around and read at Acronis True Image. Some posts recommended getting the version from the disk manufacturer so I downloaded Western Digital's version. I cloned WD#1 onto WD#2. If I remember correctly I did it sector by sector.
Once cloning finished I had another 'clever' idea, of testing it by rebooting machine. Got BSOD 7B a few seconds after Windows XP started loading. Unplugged WD#2, rebooted, still got BSOD. Unplugged WD#1 and plugged in WD#2, still got BSOD. Safe Mode (including its various options) all BSOD a few seconds in. All combinations BSOD.
Full BSOD error was: "A problem has been detected ..." 0x0000007B 0xBA4C3524 0xC000034 then just zeroes.
With WD#1 attached, I booted from Windows XP CD (which is SP2) and tried Repair Install, but after deleting and loading drivers, the repair's mid-point reboot BSOD.
Going into DOS from Windows XP CD gave so little functionality that I couldn't find out what was going wrong. CHKDSK /r did not fix the problem. FIXMBR and FIXBOOT did not either.
After all day googling on a friend's laptop I have learned that I should not have booted my machine with the just-cloned WD#1 and WD#2 in it. Dmitry and GroverH (on these boards) have stated that several times, but in all the posts I have read no one has said what to do to fix that mistake.
I have created a Hirens BootCD from my friend's laptop and am now poised ready to do something, as soon as I find out what. I will keep googling, but I am REALLY hoping that someone here can easily tell me what to do -- PLEASE?
For very much appreciated bonus karma, I would love to know the following:
After I find out how to fix WD#1, and it proves successful, I will plug in SG and copy the WD#2 data across to it, then unplug SG. That will leave me with all my data (yay!) but my system disk will be semi-messed up. WD#1 will be messed because it had Windows SP2 Repair Install tried on it, and WD#2 will be (I guess) messed up by whatever the cloning did wrong. I would much prefer not to have to Clean Install Windows XP SP2 then go through all the work of getting it back to SP3 and all my programs installed. So, can I plug in WD#1 as my C Drive and will it autoupdate to SP3 without any problems? Or should I plug in WD#2 as my C Drive? If so, should I clone it to WD#1 (without rebooting afterward!) in case the other WD disk ever fails in the future? Any other advice you can give me would be greatly appreciated.
Thanks,
Martyn
Colin, thanks for replying.
I did try a Repair Install from the XP CD as you suggest. I mentioned it in the middle of my missive but XP's software foolishly uses "R" in two different places so you probably thought I had used it only in the first-appearing place. I tried both the first "R" that appears, and also tried the second "R" (accessed by pressing ENTER, then F8 to accept license agreement, then "R" for Repair -- and BTW, I didn't need to reenter my product key). Neither approach solved the problem.
Martyn
Small update: I should mention that when booting from a Live CD, MD#1's file system seems intact. I haven't looked at the structure of the operating system yet. I don't have enough knowledge to be poking around in there so I am being very cautious about that, and I'm hoping someone on this board can tell me exactly what to do.
Martyn,
I am afraid there is no fix to your situation. The registry of each cloned/source system is corrupted because you booted with both disks after the clone. You would be better off reinstalling XP from scratch.
I managed to fully recover my system without losing anything. In case others have the same trouble (something that seems all too likely given that neither Microsoft's nor Acronis's software warns against booting with a cloned system disk attached)...
I disconnected the cloned disk and spent a couple of days browsing around the 'net and trying things. Nothing worked but I learned quite a lot, including that it's impossible to know exactly what damage Windows would have done.
I replaced the (by now) very experimented-upon system disk with the clone and tried my two favorite possibilities:
* sectedit the mbr (see below). Rebooting didn't work so I sectedit the mbr back to its previous value.
* Booted off Hirens 15.2 BootCD > Mini-XP > HBCD Menu Programs > Registry > Registry Restore Wizard. Selected a system restore point from the day before the cloning operation. Booting the system worked perfectly! All data, program settings, etc., intact.
MBR or Registry damage are the two most likely results of booting with a cloned system disk attached, but neither solution worked when I tried them on my first disk, almost certainly because once either of them was mangled then continuing to use Windows resulted in it doing even more damage. That I kept the clone disconnected was important. Either that or I was just lucky that Windows mangled the second disk less when I booted the machine with both attached.
Even though it wasn't the case with my cloned disk, MBR damage seemed to be the most likely consequence of booting with the clone attached so I'll quote a long description of that, including how to fix it:
From http://www.goodells.net/multiboot/partsigs.shtml
=======================================
Fixing Windows 2000/XP Drive Letters
Windows NT, 2000, and XP remember drive letters previously assigned to partitions. This can create problems when cloning, duplicating, or moving these OS's.
For example, suppose you have XP installed as C: in partition-1, and partition-2 has been formatted and designated D: by XP. These assignments will be recorded in the registry. If you subsequently clone XP-1 to partition-2, of course the registry goes with it. The new copy of XP is supposed to be a clone of XP-1, so is supposed to see partition-2 as C:. But when XP-2 boots, its registry recognizes the partition it's on was previously designated D:, and keeps that letter (and partition-1 keeps the letter C:). But the letter C: is embedded in countless XP-2 registry entries and configuration files, so when XP-2 starts drawing information from partition-1, you end up with a "schizophrenic" system, with XP-2 confusing which partition it's supposed to using.
Here's another example of a common cloning mistake: suppose XP-1 is C: on disk-1, and F: is a partition on disk-2. Then XP-1 is subsequently cloned to XP-2 on disk-2, and disk-1 is removed. Again, XP-2 will recognize its partition was previously given a drive letter and will keep it. The boot process may hang (usually at the login or blue "Welcome" screen) while XP-2 searches in vain for "drive C:".
The above examples concerned a destination partition that had already been assigned an undesirable letter, but you can run into trouble even if no drive letter had been previously assigned. If partition-2 did not have a previous drive letter, XP-2 will discover partition-2 the first time it boots and will assign a new drive letter. But if the previous C: partition still exists, it will keep that letter and partition-2 will have to get something else. (This is true whether or not you try to hide partition-1. Remember, common techniques for hiding a partition don't make it invisible--Windows will still know some kind of partition is there, and if it had previously been assigned a drive letter, it will keep that.)
These examples illustrate two general rules for successful cloning of NT-family OS's:
do not let old-XP see the new partition before cloning.
Doing so would give XP a chance to assign a drive letter, it will be remembered by the registry when it is cloned, and the clone will adopt the wrong drive letter for itself.
do not let new-XP see the old-XP partition the first time it boots.
If new-XP sees old-XP, it won't reuse the original drive letter when it assigns a drive letter to itself. (Once XP-2 has booted and reallocated new drive letters, the old-XP partition can be reintroduced into the system, if desired.)
Although these examples use XP, they apply just as well to NT and 2000.
How does Windows XP remember drive letters?
Windows NT, 2000 and XP keep a list of partitions, identifying each by a signature. The list is maintained in the registry key [HKEY_LOCAL_MACHINE\System\MountedDevices]. Drive letters are also recorded in this registry key and matched to the corresponding partition signatures. In this way, the OS can remember the drive letters assigned to each partition from one boot to the next. Win2000 records the signature of every partition in the registry, even those it cannot read (such as linux partitions). In contrast, XP only records "visible" partitions, so hidden and linux partitions are not listed in the XP registry.
The partition signature is derived from the DiskID and the partition's starting sector number. The DiskID (sometimes called the "NT serial number") is a group of four bytes in the master boot sector (LBA 0) at location 01B8h. Each partition's starting sector number is doubled and combined with the DiskID to form a unique signature for that partition. For example, consider a disk with the serial number 3D173D16h (hexadecimal) and a partition starting at LBA 44933868 (decimal). Double the sector number (89867736) and convert to hexadecimal (055B45D8h). If this partition were designated E:, the corresponding registry values would be:
[HKEY_LOCAL_MACHINE\System\MountedDevices]
\??\Volume{...} = 16 3d 17 3d 00 d8 45 5b 05 00 00 00
\DosDevices\E: = 16 3d 17 3d 00 d8 45 5b 05 00 00 00
(Programmers will note the "little-endian" nature, in which the bytes are stored in reverse order.)
Purists may wish to know the signature appears actually to be derived from the partition's starting byte number rather than starting sector number. Sectors universally contain 512 bytes, so LBA 44933868 starts with byte 23006140416, or 055B45D800h in hexadecimal terms. Mathematically, we arrive at the same result by doubling the sector number and offsetting the result by 100h--hence the 00 byte between the DiskID and sector location in the example above. Since we work in sector units with ptedit, I find it easier to work from the starting sector instead of starting byte number.
Every time Windows boots it calculates signatures for all partitions and adds any new signatures to the [MountedDevices] registry key. If the partition's file system is recognizable to Windows (i.e., unhidden FAT/FAT32 or NTFS), a drive letter is also assigned. Drive letters previously assigned are remembered and skipped when Windows assigns letters to newly discovered partitions. The 2000/XP sequence of assigning new drive letters follows the same manner as done by DOS and Win95/98/ME.
Note that if a partition no longer exists in the system, any drive letter previously assigned to that partition may be available for reallocation to new partitions. "No longer exists" means the partition tables no longer show any partition beginning at the same sector location. Remember that hiding a partition doesn't make it invisible, but really just disguises it. That means that using a boot or partition manager to hide a partition won't necessarily result in Windows forgetting that partition had previously been assigned a drive letter, whether or not XP can access files on it.
2000/XP's Disk Management snap-in permits the user to change the drive letters assigned to each partition, with the exception that a boot or system partition cannot be changed. Thus, it's easy to rearrange drive letters of data partitions by using built-in 2000/XP tools, but other methods are needed to manipulate drive letters of the boot/system partition(s).
How to Manage System and Boot Drive Letters
When moving or cloning 2000/XP, you may need to control the drive letter assignments remembered in the registry. It is vital that the new copy see itself by the same drive letter as the original. There are three basic approaches you can take:
directly edit the assignments in the clone's registry (difficult);
- or -
delete the previous assignments so they are not remembered (easier);
- or -
force XP to think the previous assignments are invalid (easiest).
The latter two are relatively easy, but leave it to Windows to assign new drive letters the first time the clone boots. Therefore, these methods only work if the new drive letter 2000/XP assigns to itself will be the same as the original system had used. In practice, this is easy to recreate if Windows is supposed to be C:, but difficult for any other drive letter.
Method #1:
One way to correct an erroneous drive letter is to directly edit the [MountedDevices] registry key. Microsoft provides instructions how to do this, but that only works if you can still boot into Windows. If Windows won't boot, you need a method that works from outside Windows.
In that case, use Savepart, a freeware program. This utility's main function is imaging and restoring partitions (like Ghost, DriveImage, et al), but one of its extra features is the ability to deliberately specify drive letters in the 2000/XP registry. Start Savepart, point to the clone's partition, and tell it what drive letter you want that partition to be assigned when it boots.
The following two methods are actually easier if you want the partition to be designated C:, but if the original partition was not designated C:, then Savepart should be able to set the correct drive letter.
Method #2:
If you plan ahead, you can clear the registry's drive letter table before cloning the partition, then let 2000/XP rebuild it the next time it boots. To clear the table of partitions and drive letter assignments, use regedit to navigate to [HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices]. This key will contain a bunch of values like "\??\Volume{...}" and "\DosDevices\C:", etc. (See illustration above.) Deleting all values will force Windows to regenerate all signatures and assign fresh drive letters the next time it boots. Thus, you first clear the registry values, make the clone, and then the clone will rebuild the table the first time it boots.
(Technically, you only need to clear the [MountedDevices] entries related to the drive letters you want the registry to forget, but if you're not confident you can identify the exact entries, there is no harm in deleting all entries. At worst, you would just need to use the DiskMgmt snap-in to reset your custom drive letters for other devices such as CD drives, etc.)
Method #3 ("Kawecki's Trick"):
If the clone has already been made and you don't want to start over (using Method #2 and recloning), you can fool Windows into thinking the previously assigned drive letters belong to partitions that no longer exist. Drive letters are remembered by partition signature, so by invalidating the previous signatures you can induce 2000/XP into releasing previously used drive letters for reassignment.
One way of doing this is to delete or alter the DiskID in the MBR. Since the DiskID is part of the partition signatures, this forces a change in the signatures and previously remembered drive letters can be reassigned because they no longer match valid partition signatures. The easiest way to delete the DiskID is to use a Win98 boot floppy or CD (aka, "Windows 98 Startup Disk"). Boot the computer from the floppy/CD, run the command "fdisk /mbr", and reboot into 2000/XP.
The Win98 fdisk /mbr command is similar to the 2000/XP fixmbr command (used from the 2000/XP recovery console). The intended purpose of both commands is to restore the MBR boot code, and both commands do replace the boot code without altering the partition table at the end of the master boot sector. The two commands are not exactly identical, however. As detailed by Michal Kawecki, the NT/2000/XP boot code is 440 bytes, while the Win98 boot code is 446 bytes (271 bytes of executable code, 80 bytes in error messages, and 95 bytes filled with zeroes). The NT/2000/XP fixmbr command replaces the MBR boot code but stops short of overwriting the four bytes of the DiskID that sits between the boot code and the partition table. The Win98 fdisk /mbr command will replace the boot code and zero the DiskID--albeit, unintentionally. As Kawecki points out, we can take advantage of that "mistake" because it has the effect of invalidating the partition signatures--since the signature is derived from the DiskID and Windows has to regenerate a new DiskID, it has to recalculate the signatures and assign new drive letters, abandoning any previous assignments.
Method #3B (My variation on it)
I found it much easier to use a sector editor (Roadkil's free SecEdit, from www.roadkil.net). I selected the faulty physical disk and edited its sector 0, row 1B0, column 08 (any column from 08 to 0B would do equally well), and changed it to anything else (it's effectively a random number anyway).
===============================
Given that Acronis's software knew it was cloning a system disk, I'm disgusted that it did not pop-up a warning about the absolute necessity to disconnect one of the drives before rebooting.
Very nice write up. Thank you for sharing.
I am glad to finally understand exactly when the OS gets confused when you boot with the clone and the original.
What about more recent OS'es like Vista, 7 and 8? Did you find anything about them?
I wasn't paying specific attention to other OS's but I'm sure I never read anything about Microsoft fixing the problem. Given that people often make a competition out of how fast OS's boot I can't imagine Microsoft putting in some "check before mangling" code. I'm damned sure I'm never going to put it to the test again!
Or perhaps not until after the Year of the Linux Destop.