Original poster wrote...
It really disturbs me that so far, not one poster has considered WHY
the NTLDR file "just disappeared", nor considered the possibility of
hardware damage from the spike, such as a damaged HD, or significant
corruption of the file system. It's all been taking the request at
face value, advocating recovery-unsafe steps that write to disk.
A "no NTLDR" message implies that an NT boot loader is not finding
C:\NTLDR, and that can happen if:
1) HD boots OK, MBR OK, PBR OK, file system not OK
To see that message from a HD boot, would imply successful passing
through MBR, partition table and PBR logic - so that steps to write a
new MBR or PBR are unlikely to be relevant.
Why would \NTLDR vanish? It's hardly ever written to, so a simple
"bad exit" doesn't explain this. If the HD is booting at all, then
you HAVE to consider the likelyhood of significant file system damage,
if not physical HD damage.
Under those circumstances, the first priority is not getting Windows
to boot, as Windows *always* writes to the file system and is thus
fundamentally unsafe when the file system or HD is at risk.
The first priority is to evacuate the data from the HD, then attempt
to preserve the installation, then verify RAM, physical HD, and file
system quality (in that order) and only then, bother with Windows.
2) PC is booting from an NT-formatted diskette
Even though it's impossible to boot the whole of NT off a 1.44M
diskette, nonetheless NT creates "find NTLDR and boot it" boot code on
diskettes that it formats.
If such a diskette is left in the system at boot, and CMOS boot order
boots diskette before HD (as is usually the duhfault) you see this.
Surges and lumpy power often reset CMOS settings and NVRAM, so the
only "happy ending" I'd count on here is that:
- the PC normally boots HD before diskette
- an NT-formatted diskette has been forgotten in the drive
- the surge or whatever blew CMOS back to duhfaults
- now the PC attempts to boot the diskette, and fails as above
3) PC is booting the wrong HD
If there's a HD left in the system that has an NT/XP etc. installation
ftrom another PC, then this would typically present as follows:
- the NT/XP/etc. installation attempts to boot
- the boot process fails with a STOP (BSoD) error
- if duuuuhfault settings, will auto-reboot endlessly
However, if an old NT/XP/etc. installation was deleted from a HD,
leaving the original PBR (Partition Boot Record) in place, then you
will get exactly this scenario; the attempt to boot NT/XP/etc. fails
long before any OS code "big enough" to STOP/BSoD is found.
Once again, loss of CMOS settings from a power glitch can cause this
pattern, especially where the new HD is S-ATA and the old HD is IDE.
The duhfault BIOS boot order is usually IDE before S-ATA.
Note a scenario not listed here, is CMOS corruption such that the HD
is not found and thus not booted. This would not give rise to the
decribed failure pattern because BIOS has no awareness of OSs and
files such as NTLDR.
------------ ----- ---- --- -- - - - -
The most accurate diagnostic instrument
in medicine is the Retrospectoscope
