You might want to check your hardware before doing that.
This issue started with a bad exit that may have been related to bad
power or some sort of hardware failure. Either way, there's already
reason to worry about hardware damage.
It's hard to make accurate sense of the post - for example, did the PC
"lose power" because it was unplugged from the mains or the user
switched it off, or because the power supply or other hardware failed,
or because the mains supply went out (possibly after spikes)?
Also, it's not clear whether the next reboot went straight into
Recovery Console, or something else happened. It reads as if it did,
unless the user accessed the F8 boot menu.
That suggests two interesting possibilities:
1) The PC is booting off the CD, not HD
Even in this situation, the CD would be unlikely to boot into Recovery
Console. A standard XP CD boots into a stub that falls through to HD
boot (even if HD isn't set as a boot device in CMOS) unless a key is
pressed. If a key is pressed, it boots into the installation process;
the user has to make a deliberate move to access Recovery Console.
Non-standard (i.e. big-brand OEM) CDs generally lack Recovery Console
alltogether, and are more likely to boot into a "Recovery" mode that
splats the hard drive with the original installation.
2) The PC is booting Recovery Console off the HD
Recovery Console can be installed to hard drive as an alternate
bootable OS choice, as mediated by BOOT.INI, which is interpreted by
NTLDR. It's a non-default choice, and loads via an alternate
partition boot sector image that is stored within its subtree.
For the PC to boot directly into Recovery Console, the Boot.ini would
have had to have been altered to set it as the default OS. This could
be done by the user (e.g. via MSConfig) but it is hard to see how it
could happen naturally via a bad exit. For one thing, the whole of
Boot.ini resides in one cluster (even one sector), so truncating a
write-back of Boot.ini would be unlikely to have this effect.
Doing a "repair install" involves writing a large number of core code
files to the hard drive, and has significant detrimental side-effects
even if nothing is wrong with the hardware or file system.
When something IS wrong with the hardware or file system, as may well
be the case here, the results may be irreversably distasterous...
Before trying to boot XP again, I'd want to:
- verify RAM is OK (overnight MemTest86)
- verify HD is physically OK (any bad sectors = bad news!)
- verify the file system is OK
I'd start with the RAM test, swapping the MemTest86 boot disk for some
other boot disk after it starts running. That way, if (say) a flaky
PSU or mains strip causes the PC to reboot, it won't reboot the memory
test and appear as if everything was workinhg fine.
--------------- ----- ---- --- -- - - -
Never turn your back on an installer program