Windows Stop 0x7B On Boot After Restore?

Hello,

I have an older dual boot 2K / XP dual hard drive system that I use as an emergency backup. It also has hardware peripherals that are no longer supported on newer PCs. The existing drives were starting to grow SMART errors so I decided to replace the drives with some newer ones. The old ones were 120Gb and the new ones 320Gb.

I used Paragon to backup the old drives on a different machine and then restore them to the new drives on the same machine and then transfer the drives to the old PC. Since the new drives were larger I increased partition sizes on the new drives so ended restoring each partition individually and not the entire drive at once. The XP drive will boot fine. However, the 2K drive will start to boot but always BSOD with a Stop 0x7b.

The good news to this saga is that I still have the original 2K drive and it boots just fine when installed in the old PC. This immediately rules out any PC hardware issues. While swapping drives I noticed something odd on the Boot.ini / bootloader screen. On the new restored 2K drive the boot screen only shows option lines for XP or 2K. When I put the original properly functioning drive back in I also see additional option lines for:

Microsoft Windows Recovery Console
do not select this [debugger enabled]

So apparently something significant has changed in the backup/restore process that is preventing booting. Do any of you have a any ideas as to what is going on to cause this or better yet how to further diagnose and fix this issue?

Thanks,
Steve

... Another step backwards and perhaps another clue. This project was shelved a while back and I don't remember how I partitioned the new drive. I probably used Paragon but not sure. Thinking that the MBR might be the issue I had Paragon perform an "update MBR".

Now all I get is a "NTLDR Not found" error. Next, I restored partition 0 again without an MBR update and the NTLDR Not Found persists.

I think that the NTLDR was a fluke cause by BIOS boot issues and non-optimum Boot.ini settings based on drive swapping, etc. I am now overriding BIOS boot settings via F8 and catching the Boot.ini menu to force the intended boot device.

I did another experiment and put the old/working drive is slot 0 and the cloned drive in slot 1. Booted 2K from slot 1. After 2k booted (and found and installed new hardware) I was able to access the cloned drive in slot 2 and ran CHKDSK on all partitions with no errors. This apparently shows that the 2K can read the other drive without issue. I would think that this would tend to rule out hardware incompatibility between 2K and the new drive.

Next I put the cloned drive back in slot 0 and booted from the Win 2K CD into the repair console. From here things went downhill in a hurry. The repair console found C: drive but that is about it. Attempting to run CHKDSK results in an AUTOCHK.EXE could not be found. Attempting to a simple DIR command yields "error occurred during directory enumeration".

Apparently there are some disk issues that the boot process AND recovery console can't handle...

Just for fun I ran DISKPART from the recovery console. It shows the HD as 131070MB which is wrong. However it lists all 3 partitions as the approximate correct size. However, it shows all partitions as "Unformatted or Damaged"

Apparently there are some disk issues that the boot process AND recovery console can't handle... I am beginning to think that even though 2KSP4 can handle drives bigger than 137GB that the boot process can't...

Does this jog anyone's memory?

To completely rule out hardware compatibility issues with the new drive I decided to try installing a W2K test installation from the CD. I first used DISKPART from the recovery console on the CD to ZAP all 3 partitions. I then proceeded to install a W2K instance from the CD onto the new drive. During the install I had it create and format a single 31GB partition for the new installation.

Guess what? The new installation boots just fine! This rules out any motherboard, BIOS, hard drive compatibility issues.

The bottom line appears that Backup/Restore has mis-handled either 1 or both processes.