STOP 0x7B error explanation?

[Andrew Aronoff]

I'm dealing with a Quantum Fireball lct15 (15 GB) hard disk that won't
boot into Windows XP but for which all diagnostic tools show normal
operation. I'd like to understand what might be wrong with the drive.

Windows XP Pro is installed into a 12 GB primary FAT32 partition.
There is also a 3 GB extended partition with one logical FAT32 drive.

I know that the WXP install worked for several years. Then, suddenly,
startup became impossible due to a cyclic reboot. No hardware or
software install preceded the startup fault.

The disk was removed and installed in a test bed. The drive was
alternatively booted [BOOT] or used as a secondary hard drive [2°]
under Windows 2000. The following tests were performed:

1. [BOOT] When automatic restart was disabled at system failure, the
error was identified as a STOP 0x7B (INACCESSIBLE_BOOT_DEVICE).

2. [2°] A virus check was performed -- no infection was found.

3. [2°] CHKDSK /F -- showed no errors.

4. Recovery Console was entered from an XP Pro install CD to run
FIXBOOT and FIXMBR -- no effect.

5. [BOOT] The STOP 0x7B error was avoided if FASTFAT.SYS, the FAT
driver, was not present, but Windows, of course, could not boot.

6. [BOOT] No boot log can be produced, which means that the FAT driver
never finishes loading so that data can be written. (When Safe Mode is
requested, the last driver that displays is MUP.SYS, but this is not
the culprit.)

7. [2°] Data can be read and written without error.

8. The partition data was backed up, the disk was erased,
repartitioned and reformatted, and the data was restored -- Windows XP
still rebooted with a STOP 0x7B error.

9. Norton Partition Magic 8.0 was used to create a new 6.0 GB primary
FAT32 partition at the beginning of the disk and a Windows XP install
was attempted on the empty partition -- the install terminated with a
STOP 0x7B error.

10. Maxtor PowerMax 4.23 was run from a diskette and all tests were
run -- no errors were found.

The drive shows no problem with any diagnostic tool, data can be read
and written to the drive without any apparent problem, but Windows XP
can't be installed to a FAT32 partition and an existing Windows XP
install won't boot due to a cyclic STOP 0x7B error.

What could be the problem with this drive?

regards, Andy
--
**********

Please send e-mail to: usenet (dot) post (at) aaronoff (dot) com

To identify everything that starts up with Windows, download
"Silent Runners.vbs" at www.silentrunners.org

**********

 

[Rod Speed]

I'm dealing with a Quantum Fireball lct15 (15 GB) hard disk that won't
boot into Windows XP but for which all diagnostic tools show normal
operation. I'd like to understand what might be wrong with the drive.

Windows XP Pro is installed into a 12 GB primary FAT32 partition.
There is also a 3 GB extended partition with one logical FAT32 drive.

I know that the WXP install worked for several years. Then,
suddenly, startup became impossible due to a cyclic reboot.

XP reboots on serious errors, and thats hardly ever a hard drive problem.

You'd normally disable the auto reboot, but it doesnt get far enough to allow that.

No hardware or software install preceded the startup fault.

The disk was removed and installed in a test bed. The drive was
alternatively booted [BOOT] or used as a secondary hard drive [2°]
under Windows 2000. The following tests were performed:

1. [BOOT] When automatic restart was disabled at system failure, the
error was identified as a STOP 0x7B (INACCESSIBLE_BOOT_DEVICE).

That is due to the fact that you cant normally boot a member of the NT/2K/XP
family drive in a different system, it doesnt have the correct chipset drivers.

2. [2°] A virus check was performed -- no infection was found.

3. [2°] CHKDSK /F -- showed no errors.

So there is no evidence that the hard drive has a
problem, particularly when the diagnostic is fine too.

4. Recovery Console was entered from an XP Pro
install CD to run FIXBOOT and FIXMBR -- no effect.

It wont be that, thats only useful if it whines about an inability to boot.

5. [BOOT] The STOP 0x7B error was avoided if FASTFAT.SYS, the
FAT driver, was not present, but Windows, of course, could not boot.

6. [BOOT] No boot log can be produced, which means that the FAT driver
never finishes loading so that data can be written. (When Safe Mode is
requested, the last driver that displays is MUP.SYS, but this is not the culprit.)

More evidence of memory thats gone bad or bad caps on the motherboard.
Might be a bad power supply, those can produce the weirdest symptoms.

7. [2°] Data can be read and written without error.

8. The partition data was backed up, the disk was erased,
repartitioned and reformatted, and the data was restored --
Windows XP still rebooted with a STOP 0x7B error.

9. Norton Partition Magic 8.0 was used to create a new 6.0 GB primary
FAT32 partition at the beginning of the disk and a Windows XP install
was attempted on the empty partition -- the install terminated with a
STOP 0x7B error.

10. Maxtor PowerMax 4.23 was run from a diskette and all tests were
run -- no errors were found.

The drive shows no problem with any diagnostic tool, data can be read
and written to the drive without any apparent problem, but Windows XP
can't be installed to a FAT32 partition and an existing Windows XP
install won't boot due to a cyclic STOP 0x7B error.

What could be the problem with this drive?

There's unlikely to be any problem with the drive. Most likely the motherboard
has bad caps, check for that first. These are the usually blue or black plastic
covered post like things that stick up vertically from the motherboard surface.
The tops should be flat. If any have bulged or have leaked, thats a bad cap.

Try booting a memtest86 CD and if it boots, do an overnight memory
test if it doesnt fail straight away. Less likely than the bad caps, since
that wont usually show up after running fine for years.

If neither of those helps, try booting a knoppix live CD. That completely
eliminates the hard drive from the equation and if the system wont boot
that, its pretty clear evidence of a fundamental problem elsewhere.

If all that fails, try another power supply. Excessive ripple on the
rails can produce the weirdest symptoms, particularly with an
older system thats not producing the Vcore from the 12V rail.

If all that fails, most likely its still bad caps, just not visibly bad yet,
but its worth trying the motherboard loose on the desktop before
replacing it or binning the system, a short to case can produce
the wierdest symptoms depending on whats got shorted and running
it loose on the desktop is the best way to eliminate shorts to case.

 

[Andrew Aronoff]

Hi, Rod.

Thanks for your reply.

That is due to the fact that you cant normally boot a member of the NT/2K/XP
family drive in a different system, it doesnt have the correct chipset drivers.

Yes, I know a full boot can't be performed, but one can usually get to
the boot logo or even the Welcome Screen. Also, the boot log, if
requested, most likely should be found. With this disk, FASTFAT.SYS
can't be loaded, which has nothing to do with the chipset. If
FASTFAT.SYS is not present, the boot hangs without the STOP 0x7B
error.

So there is no evidence that the hard drive has a
problem, particularly when the diagnostic is fine too.

Well, there is indeed such evidence. See item 9 in my original post
(or below).

More evidence of memory thats gone bad or bad caps on the motherboard.
Might be a bad power supply, those can produce the weirdest symptoms.

These tests were all being run on a test bed, on which there are no
hardware problems whatsoever.

KEY ITEM FOLLOWS:

If, in the test bed PC, XP can't be installed to an empty partition
due to a STOP 0x7B error, what's the problem with the drive?

There's unlikely to be any problem with the drive. Most likely the motherboard
has bad caps, check for that first.

Again, this is a perfectly fine test bed; other OS's are routinely
installed on other drives.

Try booting a memtest86 CD...

The test bed memory has no problems.

If neither of those helps, try booting a knoppix live CD.

The problem box boots fine with a BartPE CD, which rules out
everything except the drive itself and the Windows install. Since I
can't reinstall Windows in the test bed PC to an empty partition on
the problem drive, the existing install is not implicated. So what's
left?

... pretty clear evidence of a fundamental problem elsewhere.

Not at all clear where, given item 9 above.

If all that fails, try another power supply.

Definitely not a PS problem on the test bed.

If all that fails, most likely its still bad caps

Again, not on the test bed. So what can the problem be?

regards, Andy
--
**********

Please send e-mail to: usenet (dot) post (at) aaronoff (dot) com

To identify everything that starts up with Windows, download
"Silent Runners.vbs" at www.silentrunners.org

**********

 

[Rod Speed]

The disk was removed and installed in a test bed. The drive was
alternatively booted [BOOT] or used as a secondary hard drive [2°]
under Windows 2000. The following tests were performed:
1. [BOOT] When automatic restart was disabled at system failure, the
error was identified as a STOP 0x7B (INACCESSIBLE_BOOT_DEVICE).

That is due to the fact that you cant normally boot a
member of the NT/2K/XP family drive in a different
system, it doesnt have the correct chipset drivers.

Yes, I know a full boot can't be performed, but one can
usually get to the boot logo or even the Welcome Screen.

Nope, you often just get a black screen, no boot at all.

Also, the boot log, if requested, most likely should be found.

Nope, it obviously has to be able to write to the drive to do that.
If it cant even read the drive well enough to be able to find the
basics for the boot, as it clearly cant, it cant write to the log either.

With this disk, FASTFAT.SYS can't be loaded,
which has nothing to do with the chipset.

Has everything to do with being able to read the drive.

If FASTFAT.SYS is not present, the boot hangs without the STOP 0x7B error.

Because it cant get that error message text off the drive without FASTFAT.SYS

Well, there is indeed such evidence.
Nope.

See item 9 in my original post
(or below).

These tests were all being run on a test bed, on
which there are no hardware problems whatsoever.

Yeah, it wasnt clear that that was all done on the test system.

KEY ITEM FOLLOWS:

If, in the test bed PC, XP can't be installed to an empty partition
due to a STOP 0x7B error, what's the problem with the drive?

Where XP is installed partition wise is a separate issue to
where the early boot components are stored on that drive.
Presumably the early boot components are what are
producing the STOP 0x7B error and not the fresh XP install.

I bet if you wipe the drive, using something like clearhdd, then do a
clean install of XP on that drive in the test system, it will install fine.

The problem box boots fine with a BartPE CD, which rules
out everything except the drive itself and the Windows install.

No it doesnt, the other possibility is the early boot phase stuff
on that drive which doesnt get used when booting the knoppix CD.

Since I can't reinstall Windows in the test bed PC to an empty
partition on the problem drive, the existing install is not implicated.

Yes it is with the early boot phase stuff.

So what's left?

The early boot phase stuff. I'd try wiping the drive with something
like clearhdd in the test machine and try a clean install on that.
If that still produces the STOP 0x7B error, I'd ensure that the
same cable isnt being used with that drive in both systems.

If that still produces the STOP 0x7B error I'd check the jumpering, you
can see some drives work with wrong jumpering but not all the time.

If that still produces the STOP 0x7B error check for obvious
dry joints and cracked traces, tho it would be a very unusual
one of those that still passes the manufacturer's diag fine.
That might be because PowerMax trys to cover too many
drives tho, and its always been a pretty flakey diag. Try
some of the earlier versions, some are on some of the
ultimate boot CDs etc.

If that doesnt help, toss the hard drive in the bin, its
too small to be much use now anyway and its unlikely
that any diagnosis will allow you to fix it anyway.

 

[Andrew Aronoff]

Hi, Rod.

Where XP is installed partition wise is a separate issue to
where the early boot components are stored on that drive.

What do you mean by "early boot components"?

Presumably the early boot components are what are
producing the STOP 0x7B error and not the fresh XP install.

I bet if you wipe the drive, using something like clearhdd, then do a
clean install of XP on that drive in the test system, it will install fine.

The drive was effectively wiped already under W2K Disk Manager -- all
partitions were erased, the disk was repartitioned and reformatted.
The original data was copied back to the new partitions. Then,
Partition Magic was used to move and resize the main partition,
creating a new partition at the beginning of the drive. The XP install
attempt was made to the new partition.

Yes it is with the early boot phase stuff.

I'd really like to understand what you mean by "early boot phase
stuff."

The early boot phase stuff. I'd try wiping the drive with something
like clearhdd in the test machine and try a clean install on that.

It's not at all clear why clearhdd would work any better than W2K Disk
Manager.

IIUC, clearhdd is like the old IBM WIPE.COM utility, which zeros the
drive. (IBM's ZAP.COM removed the MBR.)

Disk Manager doesn't erase the drive, but, AFAICT, it certainly
removes all "early boot phase stuff." That is, after using Disk
Manager to remove all partitions, the drive is most definitely not
bootable.

If that still produces the STOP 0x7B error, I'd ensure that the
same cable isnt being used with that drive in both systems.

The same cable is not being used. My test bed uses dedicated equipment
except for the component being tested.

If that still produces the STOP 0x7B error I'd check the jumpering, you
can see some drives work with wrong jumpering but not all the time.

Jumpering was checked and is correct. IAC, the disk was a master in
the problem PC for years and is again a master on the secondary IDE
channel in the test bed. The jumpering was not changed, but the jumper
was removed and reinserted.

If that doesnt help, toss the hard drive in the bin, its
too small to be much use now anyway and its unlikely
that any diagnosis will allow you to fix it anyway.

The drive will most certainly be tossed, but I'd like to understand
the nature of the problem first.

BTW, thanks very much for your insights.

regards, Andy
--
**********

Please send e-mail to: usenet (dot) post (at) aaronoff (dot) com

To identify everything that starts up with Windows, download
"Silent Runners.vbs" at www.silentrunners.org

**********

 

[Rod Speed]

What do you mean by "early boot components"?

XP has some stuff thats used first when booting a drive, before
what is loaded out of the partition you have specified to boot from
in the boot.ini Most obviously the physical drive MBR and NTLDR.

The drive was effectively wiped already under W2K Disk Manager --
all partitions were erased, the disk was repartitioned and reformatted.

That doesnt replace the MBR or any shit that gets loaded
from the first physical track of the hard drive either.

The original data was copied back to the new partitions. Then,
Partition Magic was used to move and resize the main partition,
creating a new partition at the beginning of the drive.

The XP install attempt was made to the new partition.

Sure, but it reboots and if its using the stuff that it
didnt replace for the early part of the boot phase,
you'll still be using what crap is on that physical
drive that didnt get replaced by the XP install.

Particularly if you have antivirus protection enabled in
the bios, you wont necessarily get anything like as clean
a hard drive before the install as you will get when its
been wiped properly with something like clearhdd.

I'd really like to understand what you mean by "early boot phase stuff."

See above. The NT/2K/XP boot is surprisingly complex.

It's not at all clear why clearhdd would work any better than W2K Disk Manager.

Fraid so, nothing gets close to getting the drive right back to nothing on it at all
as a proper wipe that writes zeros thru the first few hundred physical tracks.

IIUC, clearhdd is like the old IBM WIPE.COM utility, which zeros the drive.
Correct.

(IBM's ZAP.COM removed the MBR.)

Not necessarily if you have anti virus enabled in the bios.

Disk Manager doesn't erase the drive, but, AFAICT,
it certainly removes all "early boot phase stuff."

No it doesnt, it doesnt touch the MBR or NTLDR or any crap
in the first physical track that gets loaded and shouldnt be.

That is, after using Disk Manager to remove all
partitions, the drive is most definitely not bootable.

All that means is that the later parts of the boot have gone,
particularly whats in the partition. Doesnt affect what is on
the physical drive thats loaded before the partition specified
in the boot.ini is booted later in the boot phase.

The same cable is not being used. My test bed uses
dedicated equipment except for the component being tested.

Jumpering was checked and is correct. IAC, the disk was a
master in the problem PC for years and is again a master on
the secondary IDE channel in the test bed. The jumpering was
not changed, but the jumper was removed and reinserted.

The drive will most certainly be tossed, but I'd like
to understand the nature of the problem first.

If a full wipe of the hard drive makes no difference,
I'd try to find the original Quantum diagnostic for that
drive and see if that still says that the drive is perfect.

BTW, thanks very much for your insights.

No problem, thats what these technical groups are for.

 

[Mike Tomlinson]

Yes, I know a full boot can't be performed, but one can usually get to
the boot logo or even the Welcome Screen.

Not if the IDE controller driver is the wrong one, you can't.

You're getting the STOP 0x7B error because the drive has been moved to a
system with a different IDE controller chip or chipset. If you are able
to return the drive to the original system and boot it, then use Device
Mangler to change the IDE controllers to the generic Microsoft ones, the
drive will then boot okay on the other computer.

 

[Rod Speed]

Not if the IDE controller driver is the wrong one, you can't.

You're getting the STOP 0x7B error because the drive has been
moved to a system with a different IDE controller chip or chipset.

Not with the clean install on the test machine.

If you are able to return the drive to the original system and boot it,
then use Device Mangler to change the IDE controllers to the generic
Microsoft ones, the drive will then boot okay on the other computer.

Thats effectively what he did with the clean install on the test machine in its own partition.

 

[Andrew Aronoff]

Hi, Rod.

I needed a few days to fully diagnose this problem. FOA, your help has
been very much appreciated.

XP has some stuff thats used first when booting a drive, before
what is loaded out of the partition you have specified to boot from
in the boot.ini Most obviously the physical drive MBR and NTLDR.

NT-type systems (NT 4.0, W2K, WXP) all boot same way: the MBR
identifies the active partition, the active partition boot sector is
read, the boot sector launches ntldr, ntldr parses BOOT.INI to
determine the Windows system directory, ntldr launches NTDETECT.COM to
detect basic hardware, and control is then passed to the Windows
kernel. See the W2K Resource Kit, pages 242-247 and page 41 of this
document:
http://i.i.com.com/cnwk.1d/i/tr/downloads/home/indtb_ch3.pdf

That doesnt replace the MBR or any shit that gets loaded
from the first physical track of the hard drive either.

It most likely does replace the MBR, since the active partition is
reset in that process and the MBR points to the active partition.

Particularly if you have antivirus protection enabled in
the bios, you wont necessarily get anything like as clean
a hard drive before the install as you will get when its
been wiped properly with something like clearhdd.

"clearhdd" or "wipe.com" is overkill. There is no need to zero a drive
to reset the MBR or partition boot sector.

It turns out the existing install *was* implicated because I *could*
reinstall Windows in the test bed PC to an empty partition. The reason
for my error is a long story that has to do with how my test bed is
configured. The disk, then, was *not* defective and the existing
install wasn't off the hook.

Fraid so, nothing gets close to getting the drive right back to nothing on it at all
as a proper wipe that writes zeros thru the first few hundred physical tracks.

Any drive will be reset by using Windows Disk Management
(diskmgmt.msc) to delete and recreate the partitions.

Not necessarily if you have anti virus enabled in the bios.

That's a good point. The BIOS may need to be configured to allow the
MBR to be rewritten, but that's likely true even if the MBR is
rewritten with clearhdd.

No it doesnt, it doesnt touch the MBR or NTLDR or any crap
in the first physical track that gets loaded and shouldnt be.

If the BIOS doesn't prevent the action, the Disk Management console
can be used to remove all the "early boot phase stuff". If the
partitions are deleted, ntldr, NTDETECT.COM, and BOOT.INI are gone and
the partition boot sector is rewritten. If there is no active
partition, the MBR has to be rewritten since it points to the active
partition and there isn't any.

If a full wipe of the hard drive makes no difference,
I'd try to find the original Quantum diagnostic for that
drive and see if that still says that the drive is perfect.

FWIW, I was able to find PowerMax 4.06 on the web and it, too,
diagnosed the disk as in good operating order after running the "Basic
Quick" and "Advanced Test".

After I found my test bed configuration error, I was able to install
XP to the hard disk with no problem. I saved the old install
directories (Documents and Settings, Program Files, System Volume
Information, Windows) by renaming them. I thus wound up with two
independent Windows installs on the drive. The new install worked
fine. The original install still had a STOP 0x7B error. As has been
suggested, that may well be due to the change of motherboard or IDE
controller chipset.

I then tried reinstalling the hard disk into the problem PC using the
original Windows install. The BIOS recognized the disk, but there was
an "NTLDR is missing" error message. The MBR was pointing to the
partition boot sector, but that boot sector could not launch ntldr
(which was indeed present in the root directory of the active
partition). Booting via a NT boot floppy had the same result.

For the same hard disk, ntldr could be read on a test bed PC but could
not be found on the problem PC. The problem PC has two CD drives on
the secondary IDE channel. Both work normally. I tried switching the
hard disk to the secondary channel and I tried using a different IDE
cable, but NTLDR is missing was the only result.

I don't understand what the exact problem is, but it appears to be
hardware, not software. I'll likely abandon the problem PC and recover
the hard disk for use elsewhere.

Thanks again for your help.

regards, Andy
--
**********

Please send e-mail to: usenet (dot) post (at) aaronoff (dot) com

To identify everything that starts up with Windows, download
"Silent Runners.vbs" at www.silentrunners.org

**********

 

[Andrew Aronoff]

Yes, I know a full boot can't be performed, but one can

Not with the clean install on the test machine.

As it turns out, the STOP 0x7B error *is* likely due to a change in
hardware, since the clean install on the test machine *did* succeed
after I corrected a configuration error on that machine.

FWIW, I added the natively supported IDE controllers to the registry
of the problem install by using the registry data in MSKB 822052. I
made sure the keys were present and the files intelide.sys,
pciide.sys, and pciidex.sys were present in the system32\drivers
directory. That did not remove the STOP 0x7B error.

Thats effectively what he did with the clean install on the test machine in its own partition.

I wasn't able to boot on the original system, which was why I was
trying to boot on the test bed PC.

Again, the clean install on the test machine _did_ work.

As I stated in a previous message, I believe the problem is hardware,
not software, on the original PC and the hard disk is not to blame.

Thanks for your comments.

regards, Andy
--
**********

Please send e-mail to: usenet (dot) post (at) aaronoff (dot) com

To identify everything that starts up with Windows, download
"Silent Runners.vbs" at www.silentrunners.org

**********

 

[Rod Speed]

I needed a few days to fully diagnose this problem.
FOA, your help has been very much appreciated.

NT-type systems (NT 4.0, W2K, WXP) all boot same way: the MBR
identifies the active partition, the active partition boot sector is read,
the boot sector launches ntldr, ntldr parses BOOT.INI to determine the
Windows system directory, ntldr launches NTDETECT.COM to detect
basic hardware, and control is then passed to the Windows kernel.

Correct, and that is what I said in different words.

See the W2K Resource Kit, pages 242-247 and page 41 of this document:
http://i.i.com.com/cnwk.1d/i/tr/downloads/home/indtb_ch3.pdf

It most likely does replace the MBR,

Nope, not the boot code thats in the MBR it doesnt.

since the active partition is reset in that process
and the MBR points to the active partition.

You're ignoring the code thats in the physical drive
MBR that is the earliest part of the boot code wise.

"clearhdd" or "wipe.com" is overkill.

Nope, its the only way to be completely sure that
nothing other than what is intended is being loaded
at boot time, particularly crap from the first physical
track thats a bios overlay, virus, etc etc etc.

There is no need to zero a drive to reset the MBR or partition boot sector.

There is a need to wipe a drive to ensure that nothing other
than the code in the MBR and ntldr is involved in the boot.

It turns out the existing install *was* implicated because I *could*
reinstall Windows in the test bed PC to an empty partition. The
reason for my error is a long story that has to do with how my
test bed is configured. The disk, then, was *not* defective and
the existing install wasn't off the hook.

And quite apart from that, the early boot components like the code
in the MBR and ntldr arent necessarily affected by the reinstall of
XP onto an empty partition. The easiest way to eliminate all those
possibilitys is to just wipe the drive and start over from scratch.

Any drive will be reset by using Windows Disk Management
(diskmgmt.msc) to delete and recreate the partitions.

Wrong. Most obviously with any crap that gets loaded from the first physical
track separately from that stuff you listed in your second para at the top.

That's a good point. The BIOS may need to be configured
to allow the MBR to be rewritten, but that's likely true even
if the MBR is rewritten with clearhdd.

Not necessarily, depends on how the wipe does its wiping.

If the BIOS doesn't prevent the action, the Disk Management
console can be used to remove all the "early boot phase stuff".

You presumably mean the recovery console, not the disk management console.

If the partitions are deleted, ntldr, NTDETECT.COM, and BOOT.INI
are gone and the partition boot sector is rewritten. If there is no active
partition, the MBR has to be rewritten since it points to the active
partition and there isn't any.

You're comprehensively mangling the partition table and the tiny bit of code
thats in the MBR. That code isnt rewritten just because partitions are deleted.

And ignoring crap from the first physical track that may be being loaded by that code too.

FWIW, I was able to find PowerMax 4.06 on the web and it, too,
diagnosed the disk as in good operating order after running the "Basic
Quick" and "Advanced Test".

After I found my test bed configuration error, I was able to install XP
to the hard disk with no problem. I saved the old install directories
(Documents and Settings, Program Files, System Volume
Information, Windows) by renaming them. I thus wound up with two
independent Windows installs on the drive. The new install worked
fine. The original install still had a STOP 0x7B error. As has been
suggested, that may well be due to the change of motherboard
or IDE controller chipset.

No may about it, thats the usual cause of that particular stop error in that situation.

I then tried reinstalling the hard disk into the problem PC using the
original Windows install. The BIOS recognized the disk, but there was
an "NTLDR is missing" error message. The MBR was pointing to the
partition boot sector, but that boot sector could not launch ntldr
(which was indeed present in the root directory of the active
partition). Booting via a NT boot floppy had the same result.

And if you had wiped the drive with something
like clearhdd, you would not have got that mess.

For the same hard disk, ntldr could be read on a test bed PC but could
not be found on the problem PC. The problem PC has two CD drives on
the secondary IDE channel. Both work normally. I tried switching the
hard disk to the secondary channel and I tried using a different IDE
cable, but NTLDR is missing was the only result.

Thats usually due to some problem with the controller.

I don't understand what the exact problem is,
but it appears to be hardware, not software.
Correct.

I'll likely abandon the problem PC and recover the hard disk for use elsewhere.

Thanks again for your help.

Thanks for the washup, too rare in my opinion.

 

[Rod Speed]

As it turns out, the STOP 0x7B error *is* likely due to a change in
hardware, since the clean install on the test machine *did* succeed
after I corrected a configuration error on that machine.

In fact you didnt actually have a clean install on the test machine.

FWIW, I added the natively supported IDE controllers to the registry
of the problem install by using the registry data in MSKB 822052. I
made sure the keys were present and the files intelide.sys,
pciide.sys, and pciidex.sys were present in the system32\drivers
directory. That did not remove the STOP 0x7B error.

I wasn't able to boot on the original system, which
was why I was trying to boot on the test bed PC.

Again, the clean install on the test machine _did_ work.

Yes, you didnt actually have a clean install when you claimed you did.

 

[Mike Tomlinson]

FWIW, I added the natively supported IDE controllers to the registry
of the problem install by using the registry data in MSKB 822052. I
made sure the keys were present and the files intelide.sys,
pciide.sys, and pciidex.sys were present in the system32\drivers
directory. That did not remove the STOP 0x7B error.

Did you follow the instructions under "A "Stop 0x0000007B" error message
occurs after you move the system disk to another computer" in KB822502?
You need the "Standard IDE/ESDI Hard Disk Controller" configured using
atapi.sys. Patching the registry as described should work.

You could also boot the disk in a third machine with the same IDE
controller as the original, failed one, and use that to run Device
Manager and reset the hard disk controllers to "Standard IDE/ESDI Hard
Disk Controller". The disk will then boot in the machine you want to
use it in.