XP not booting after cloning HD

I'm hoping someone can help me get my new hard drive working.

I should mention this is about my P4 PC, not my PhenomII (which has got an annoying delay when booting windows but that's a different story).

I've just got a WD6400AAKS and so I've been trying to clone the partitions across from my WD5000AAKS. I've done this a few times before with other drives and had to sort out problems with drive letters and so on, but this time it's not working at all.

I've tried with Ghost8, True Image Home 2009 and EASEUS Todo Backup (selecting the MBR/Track0 option with the last two) but nothings working.

I of course have been disconnecting the WD5000AAKS after cloning it and I've also booted from the WD5000, loaded in the SYSTEM hive from the WD6400, deleted the reference to C: in MountedDevices (and made sure there's no references to partitions on the WD6400AAKS), and rebooted again with only the WD6400 but still I just get the black screen.

I've got a dual XP boot and I've put an extra line in each boot.ini, so that I'll see if it's got that far.

The first XP (cloned with Easeus) locks up on the grub4dos screen, where it says "Filesystem type is fat, partition type 0x0B" and the second XP (cloned with TI) makes it to the boot.ini menu, but then mostly says "system32\config\SYSTEM is missing or corrupt" although once it got to the XP Boot screen before BSOD with a Page_Fault message and another time I got a "Fatal System Error" blue screen.

I've connected the OPT1 jumper shown here
http://wdc.custhelp....created=#jumper
as my board (Gigabyte 8I848) doesn't support SATA2 and my WD5000 already had that jumper connected. As an experiment though, I disconnected the jumper on the WD5000 and it booted into XP just fine, so it seems it's not necessary.

When I boot from the WD5000 I can see the partitions on the WD6400 in XP just fine. I've just run a WD Data Lifeguard Test on the drive though (from grub4dos) and that reports no errors.

.... but still I just get the black screen.

Which tells us NOTHING.

I've got a dual XP boot and I've put an extra line in each boot.ini, so that I'll see if it's got that far.

Good.

The first XP (cloned with Easeus) locks up on the grub4dos screen, where it says "Filesystem type is fat, partition type 0x0B" and the second XP (cloned with TI) makes it to the boot.ini menu, but then mostly says "system32\config\SYSTEM is missing or corrupt" although once it got to the XP Boot screen before BSOD with a Page_Fault message and another time I got a "Fatal System Error" blue screen.

This appears like an "intermittent" kind of problem.
If there is a problem in a procedure, it will normally result ALWAYS in the SAME error, not a different one each time you attempt it.


Let me understand, are you cloning the dirve AND keeping BOTH connected?

You cannot "completely" clone a drive and have BOTH old and new drive on the same system.

See here:
http://www.boot-land...?showtopic=8233

Check signatures of disks.

Make up your mind and choose one and one only program (all three should be capable to do the cloning) and post details on the specific way you used the chosen one.

Post the data detailed in post #8 there and I'll see what I can find out.


Wonko

Hi Wonko

Let me understand, are you cloning the dirve AND keeping BOTH connected?

You cannot "completely" clone a drive and have BOTH old and new drive on the same system.

No, as I said "I of course have been disconnecting the WD5000AAKS after cloning it and I've also booted from the WD5000, loaded in the SYSTEM hive from the WD6400, deleted the reference to C: in MountedDevices (and made sure there's no references to partitions on the WD6400AAKS), and rebooted again with only the WD6400 but still I just get the black screen."

From further testing, booting from partition 2 on the WD6400 consistently gives the "System32\Config\SYSTEM" is missing or corrupt error. Booting from partition 1 occasionally gets to the XP boot screen before blue screening with some error, or otherwise just hangs at the screen showing the Grub4Dos commands. I'll stick to testing partition 2 for now I think though, as that's my main XP that I'm using and it will save me having to keep checking/amending the MountedDevices for both installations

I've checked the disk signatures and they're:
WD5000 7AF47AF4
WD6400 EF82B7B1

Driveinfo is:

C:\Utils\MBRFIX>mbrfix /drive 0 driveinfo
Drive 0
Cylinders = 60801
Tracks per cylinder = 255
Sectors per track = 63
Bytes per sector = 512
Disk size = 500105249280 (Bytes) = 465 (Gb)

C:\Utils\MBRFIX>mbrfix /drive 1 driveinfo
Drive 1
Cylinders = 77825
Tracks per cylinder = 255
Sectors per track = 63
Bytes per sector = 512
Disk size = 640132416000 (Bytes) = 596 (Gb)

I can boot from partition 2 on the WD5000, which has this entry in MountedDevices:
"\\DosDevices\\C:"=hex:f4,7a,f4,7a,00,80,39,40,06,00,00,00

but not from partition 2 on the WD6400, which has this entry:
"\\DosDevices\\C:"=hex:b1,b7,82,ef,00,7e,00,00,00,00,00,00

I'll stick with Ghost8 for the cloning, because True Image doesn't seem to allow me to clone one partition, unless I make an image of it first and then restore from that image.

With Ghost8, I use Partition to Partition to clone partitons 1 and 2 (which are both XP boot Primary partitons). I've also copied across the Extended partition, which contains a couple of Logical partitons for my data.

I've noticed a strange quirk with Ghost, in that even though P1 and P2 on both drives have the same label in XP and if I select the WD6400 as the source drive for cloning it shows the correct labels (XPMP and MP-Backup), when I select the WD5000 as the source drive, select partition 1 and then select the WD6400 as the destination drive, it shows the labels for P1 and P2 as NONAME and XP2. I guess these are just DOS labels that Ghost doesn't copy over and it's probably not relevant to my problem, but I thought I'd better mention it as it's strange and might mean something!

I've made a zip containing my MBRs and bootsectors and the driveinfo, in case that helps you to help me.

http://rapidshare.co...D_info.zip.html

Cheers

Got the files, I'll have a look at them.

At first sight, this however:

but not from partition 2 on the WD6400, which has this entry:
"\\DosDevices\\C:"=hex:b1,b7,82,ef,00,7e,00,00,00,00,00,00

sounds not "right".
This:

00,7e,00,00,00,00,00,00

means that the partition starts at offset 0x7e00=32,256 ->32,256/63= 63 sectors before
on disk with signature

b1,b7,82,ef

http://www.911cd.net...showtopic=19663

In other words, that Registry entry is for FIRST partition on the WD6400, which is also the one marked as Active in the MBR.

I don't know HOW you managed to do it , but FIRST partition on the WD6400 is marked as 0B (CHS FAT32), being it at offset 32,256 and 26,847,281,664 bytes in size (i.e bigger than CHS limit), this is INCORRECT and should be corrected to type 0C (LBA FAT32).
You can use beeblebrox or any hex/disk editor to correct this.


Wonko

Sounds like you might be on to something

I don't think it matters which partition is marked Active, as on the WD5000 the first partition is also marked Active but Grub4Dos can boot from the second partition just fine.

If I delete all entries for the drive with signature "b1,b7,82,ef", I think XP will automatically assign C: to the boot partition on the next boot (although I guess it might assign it to the Active partition rather than the boot partition, not sure about that).

Then again, in my past experience, even when MountedDevices is wrong, XP still boots to the logon screen (or just before) before it gets confused

If I delete all entries for the drive with signature "b1,b7,82,ef", I think XP will automatically assign C: to the boot partition on the next boot (although I guess it might assign it to the Active partition rather than the boot partition, not sure about that).

The second you said.
Remember that the MS MBR can only boot from an active partition.
Then remember how drive letters are assigned:
http://www.dewassoc....riveletters.htm
XP behaves same as 2K - we die-hard 2K users love to say how XP is a bettered 2K, only worse.

However, until you have the WRONG 0B in the MBR you won't get anywhere.
Your next step is to change it to 0C.
Then test again.
Then delete again DosDevices in the 6400 Registry AND make SECOND partition Active.
Then test again.


Wonko

Remember that the MS MBR can only boot from an active partition.

I'm using Grub4Dos though, which seems quite happy to boot from a non-active partition. On my other PC (which I'm typing this on) I'm currently running from P2, even though P1 is Active.

Nonetheless, I've made P2 on the WD6400 Active now.

I've fixed the 0B as well. Just to prove it (this was before I made P2 Active!)

MBRWiz - Version 2.0 **beta** for Windows XP/2K3/PE April 30, 2006
Copyright © 2002-2006 Roger Layton http://mbr.bigr.net

Disk: 1 Size: 610G CHS: 77825 255 63
Pos MBRndx Type/Name Size Active Hide Start Sector Sectors DL Vol Label
--- ------ ---------- ---- ------ ---- ------------ ------------ -- ----------
0 0 0C-FAT32X 26G Yes No 63 52,436,097 K: XPMP
1 1 0C-FAT32X 26G No No 52,436,160 52,436,160 N: XP-BACKUP
2 2 0F-EXTEND 395G No No 104,872,320 809,884,845 -- <None>

I connected the WD6400 to my other PC, which gave the partitions letters and by checking MountedDevices, I could see that P2 on the WD6400 was

"hex:b1,b7,82,ef,00,80,39,40,06,00,00,00

so I edited MountedDevices for P2 on the WD6400 to read

"\\DosDevices\\C:"=hex:b1,b7,82,ef,00,80,39,40,06,00,00,00

and made sure that no other drive letter was assigned to that same string.

I still got the "System32\Config\SYSTEM" is missing next time I tried to boot though. Then I tried Safe Mode and it loaded some drivers (asked me to press Enter to confirm SPTD.sys, which I didn't) but then it BSOD "IRQL_NOT_LESS_OR_EQUAL".

I'll try deleting all the \\DosDevices\\ entries from MountedDevices to see if it makes any difference, but I don't see why it should.

I checked MountedDevices for P1 while I was at it and that had the right entry:

"\\DosDevices\\C:"=hex:b1,b7,82,ef,00,7e,00,00,00,00,00,00

and P1 was Active before, but I still couldn't boot P1 at all, in fact it didn't even get as far as the boot.ini.

Maybe I need to wipe the MBR and partition table and restore the Ghost images to the drive. If you think that's a good idea, some tips on how to wipe them effectively would be cool.

The whole point is that you started with a wrong approach.

The change of partition type from 0C (right) to 0B (wrong) must have been caused by something.

Since you tried three different utilities and with unknown or unreported settings/sequence, there is no way to know which one caused the problem.

It is well possible that simply attempting booting with a wrong partition type, and with the wrong Active partition and/or deleted or invalid values in DosDevices may have triggered some changes in the filesystem or in the Registry or whatever that made the system unbootable.

You also started with a non-fully--described non-standard partitioning and dual-booting scheme, so the number of variables are simply too high.

This was the sense of this:

Make up your mind and choose one and one only program (all three should be capable to do the cloning) and post details on the specific way you used the chosen one.

You have chosen GHOST.

You need to re-start from scratch (for all I know you may have made "wrongly" the image, and thus you can restore it correctly all the times you want, but it won't work.

To re-start from scratch simply wipe the MBR of the target disk (WD6400) and the bootsector of the first partition and reboot, easier would be to wipe first (say) 100 sectors of the device:
http://www.boot-land...topic=3453&st=8

Recreate the image from the Source disk (the WD5000).

Detail the creation process/choices.

Try restoring it to the target.

DO NOT attempt booting from it.

Clear COMPLETELY the DosDevices of the offline hive.

Check the signature of the disk.

Make second partition Active.

Verify that type of both FAT32 partitions is 0C.

Try booting from the imaged target drive.

Report error(s) (if any) at first boot ONLY.

DO NOT attempt booting again from the imaged target drive if you have errors during first boot.




Wonko

Things just got a bit more complicated

The WD5000 from time to time has trouble spinning up (which is why I'm replacing it) and as as result, Windows gets corrupted. This recently happened when booting P2, and as a result the entire SYSTEM32 folder is now .CHK files in the FOUND folder (SYSTEM32 folder is gone).

I mainly mention this so that you understand when I say I can't make a new image of P2 now.

Anyway, this is what I've done.

I made a GHOST (boot to FreeDOS, run Ghost8.2, partion to image) of the WD5000 P1 (which I've verified still works), disconnected the WD5000 and then wiped the first and last 1,000,000 sectors of the WD6400 with WD Data Lifeguard.

GHOST wouldn't let me select the drive as a destination to restore to whilst it was unpartitioned, so I made a 25GB FAT32 partition using FDISK under FreeDOS. Then I did Partion Restore From Image and restored the image I just made to the new partiton.

Then I booted my LiveXP and checked the drive info (type was 0C and P1 was Active) and removed the DosDevices from the WD6400 P1 hive (on previous attempts I noticed that GHOST had assigned C: to the correct partition, but this time it was still pointing at the old drive signature).

Then I rebooted and it hung at POST, no "cannot find a bootable drive" error or anything. I realised it probably didn't have an MBR installed, so I sorted that out.

Voila! Next boot it loaded into XP.

However, I then got a message at the logon screen saying "One of the files containing the system's Registry data had to be recovered by use of a log or alternate copy. The recovery was successful." and it was all downhill from there as that message remained on the screen, the keyboard and mouse wouldn't work, Windows Explorer crashed before it even finished booting and the taskbar was just a solid blue block.

So we've made some progress, but it's not that encouraging. I'm wondering whether I should try testing the drive by connecting it to my other PC and installing XP on it in Qemu. If that doesn't work either, I guess the drive must be faulty and I'll have to return it.

I could also try changing the BIOS settings from SATA mode to IDE emulation. A couple of weeks ago I changed it the other way as the WD5000 was coming up in PIO mode in XP with it set to IDE (it hadn't always so maybe it was just that the drive is on it's way out) and after changing it to SATA it worked in UDMA5 as it should, but it might help to change it back.

Ok, that means:

• that you used GHOST in a "wrong" way to create the image ("wrong" in the sense that you took a copy of the partition without saving the MBR data, not a problem but you have to recreate the MBR)
• your source drive has problems that most probably are "reflected" in the image (GHOST is pretty much fast in the imaging and it is likely to be not "error free"

In other words my thought is that the problem is not in the procedure, nor in "target" but rather in the inconsistency of source. (intermittent errors)

Your best bet at this point is to do a R (Repair install) on the restored target drive (the one with the taskbar being a solid block)
http://michaelsteven...pairinstall.htm


Wonko

I am a visual person who enjoys diagrams or reading about ordering such as:

• Disk 1 - "FOO" - MBR sig blahblah
  
  • Partition 1 - Active - Windows XP A
  • Partition 2 - Windows 7 B
• Disk 2 - "BAR" - MBR sig blahblah
  
  • Partition 1 - Active - Windows XP A
  • Partition 2 - Windows 7 B

"I cloned 'foo' to 'bar', but cloned partitions so MBR sig is different. Windows A won't boot from 'bar' on computer Y, but it boots just fine from 'foo' on computer X."

That's just an example of something I would find easy to follow.

If you get a SYSTEM hive missing or corrupt, you can find out the truth of that by:

• Making a note of the boot sequence, such as MBR -> GRUB4DOS -> partition 1 -> NTLDR
• Examining the BOOT.INI being used, especially which disk and partition NTLDR is trying to boot from
• Connecting the disk to a known-good computer (or booting some other Windows or PE environment on the problem computer)
• Looking in the particular partition for the SYSTEM hive
• If it's there, load it with RegEdit and see if RegEdit tells you the file is ok or not
• Safely unload the hive from RegEdit before shutting down the computer

There is such a diversity of problem descriptions, it's hard to know exactly where to begin.
You can use a hash-checker such as MD5.EXE to verify that critical files have been cloned correctly.
If you're having spin-up problems, that's really too bad.
If you can choose Disable automatic restart on system failure from the F8 menu, then you can report which STOP error code is yielded on a Blue Screen of Death.
If your problems are random without you having made any changes in-between tests, that's definitely a problem that might suggest faulty hardware. If your tests have different results but you've changed a little bit here or there, there can be multiple problems compounding one another.
If the SYSTEM hive can't be loaded, changing a MountedDevices entry in that hive can't possibly make a difference. If you get STOP 7B, that might be a good time to re-evaluate the MountedDevices entry. I know you said as much, doveman.
If a particular driver is giving you a BSoD, you can check its hash to verify it against the source, or consider that it might be strongly incompatible with a different computer than it was installed on.
When you were prompted about SPTD.SYS, do you remember exactly what the message said, by any chance? I've recently been looking for something and your mention of this could possibly help me out. -EDIT- What I was looking for has nothing to do with SPTD.SYS, but I just looked it up and it looks like a virus which could potentially cause corruption in the Registry. Just FYI.

[*]that you used GHOST in a "wrong" way to create the image ("wrong" in the sense that you took a copy of the partition without saving the MBR data, not a problem but you have to recreate the MBR)

Whether Ghost failed to make a copy of the MBR or if it just failed to restore it, was hardly my fault as it doesn't give you any option in this regard.

[*]your source drive has problems that most probably are "reflected" in the image (GHOST is pretty much fast in the imaging and it is likely to be not "error free"
[/list]
In other words my thought is that the problem is not in the procedure, nor in "target" but rather in the inconsistency of source. (intermittent errors)

The source is fine and continues to work OK. The only problem with it is that it occasionally has trouble spinning up, which corrupts files but apart from that there's no file corruption.

To establish that the images are fine, I restored the TI of P2 that I'd made before the partition got corrupted to the WD5000 and that works fine. Restoring the same TI to the WD6400 results in the same old "SYSTEM32\CONFIG\SYSTEM" is corrupt or missing.

I've now tested the drive further on my other PC (to take the PC out of the equation). Trying to install XP, when I select to Quick Format the drive, it says "Setup was unable to format the partition. The disk may be damaged". If I do a Full Format, it gets to 100% before displaying the same error.

I also tried installing Win7. On the first try, it got stuck at 0% on "Expanding Files". When I restarted, it showed a 100M partition that I couldn't delete, so I installed into the space after that and whilst "Expanding Files", got errors about corrupt files.

I've done a Full Drive Check with WD Diagnostics and that completes without error, but there's obviously something wrong with the drive so I'll have to get WD to replace it.

Whether Ghost failed to make a copy of the MBR or if it just failed to restore it, was hardly my fault as it doesn't give you any option in this regard.

Sure, notoriously GHOST cannot copy the MBR.

Oww, comeon....
....we did not manage yet to know WHICH of the several versions of GHOST you attempted using, NOR with WHICH options, so I will make a "generic" statement:

To the best of my knowledge ALL versions of GHOST I ever tried/tested had a number of options INCLUDING that of taking an image of a whole hard disk (which includes the MBR) and/or an option to copy MBR to target disk.

To establish that the images are fine, I restored the TI of P2 that I'd made before the partition got corrupted to the WD5000 and that works fine. Restoring the same TI to the WD6400 results in the same old "SYSTEM32\CONFIG\SYSTEM" is corrupt or missing.

I guess that all that was "established" was that the TI (which I have to presume is an Acronis True Image file) is fine.
This says nothing about the GHOST one(s).
It also says that the restoring of the "TI" to the WD6400 failed, but "the same old "SYSTEM32\CONFIG\SYSTEM" is corrupt or missing" could well be due to a wrongly performed imaging/restoring on the "new" drive, including the \DosDevices editing and what not.

I've now tested the drive further on my other PC (to take the PC out of the equation). Trying to install XP, when I select to Quick Format the drive, it says "Setup was unable to format the partition. The disk may be damaged". If I do a Full Format, it gets to 100% before displaying the same error.

This is "strange" and it may be connected with a problematic hard disk drive.

I also tried installing Win7. On the first try, it got stuck at 0% on "Expanding Files". When I restarted, it showed a 100M partition that I couldn't delete, so I installed into the space after that and whilst "Expanding Files", got errors about corrupt files.

The creation of the 100 Mb partition is "normal" if the Win7 setup finds a non-partitioned drive.
The setup getting stuck is not, though.

However it would be, again a "generic" statement, the first time in my life I see or hear about a disk drive been reported 100% functional by it's manufacturer diagnostic software being found somehow "defective" by a Windows Setup.

Have you tried what was suggested?

(restoring "an" image AND run a Repair install?)

If NOT, WHY not?


Wonko

To the best of my knowledge ALL versions of GHOST I ever tried/tested had a number of options INCLUDING that of taking an image of a whole hard disk (which includes the MBR) and/or an option to copy MBR to target disk.

I'm not saying that GHOST can't copy the MBR, just that doing a partition to image and then restoring from that image didn't restore the MBR and at no point did it ask me about backing up/restoring the MBR. It might have an option to seperately backup/restore the MBR and of course it copies it when doing a full disk copy. In comparison, True Image asks me when restoring from a partition image if I also want to restore the MBR and/or Track0, so it must backup those as well when making a partition image.

I guess that all that was "established" was that the TI (which I have to presume is an Acronis True Image file) is fine.

Yeah, but that's enough to rule the image out as the problem.

This says nothing about the GHOST one(s).
It also says that the restoring of the "TI" to the WD6400 failed, but "the same old "SYSTEM32\CONFIG\SYSTEM" is corrupt or missing" could well be due to a wrongly performed imaging/restoring on the "new" drive, including the \DosDevices editing and what not.

That's why I used the True Image rather than the GHOST when testing. The restoring was done identically to both the WD5000 and the WD6400 and TI takes care of the disk signature and \DosDevices (I checked them of course).

Have you tried what was suggested?

(restoring "an" image AND run a Repair install?)

If NOT, WHY not?

No, because it seems pointless if the disk is corrupting/unable to read files. I also felt it would be more useful to test the drive on a different PC to rule that out as the problem.

If I can't install Windows to the drive or restore from a good image, then it's faulty and so I've passed it to WD to fix if possible or replace if not.

Thanks for trying to help diagnose the problem though.

Hey doveman, you're not happening to use any virtual machines for any of these image restoration processes, are you? If so, there are potentially disk geometry considerations.

By the way, MountedDevices doesn't matter at the point where NTLDR is telling you that SYSTEM is corrupt, since that hive is where MountedDevices actually lives. If Acronis TrueImage has an NTFS and/or Registry post-processing it does after restoring your image, perhaps this post-processing is a potential point of failure? Using RegEdit to load the SYSTEM hive could reveal integrity or lack thereof.

Hi Sha0

No, not using virtual machines, all real ones

Now you mentioned it, it's pretty obvious that MountedDevices couldn't be causing the problem as it's not even loaded at that point. As I recall, in the past when I've tried to boot with MountedDevices pointing to the wrong letter, it's got all the way to the logon screen before encountering problems.

I don't think True Image is causing any problems, as it's restores OK to another drive. I have been checking the SYSTEM hive though and it loads fine into RegEdit.

If you want to clone it onto a virtual machine you may need to enable IO APIC, otherwise it won't boot (it took me some time to figure that out)