See if you have this folder:
windows\ServicePackFiles\i386
copy/paste that file to the windows\system32\drivers folder. If not,
extract a fresh copy from your XP CD.
May be perilous/off-center advice, for two generic reasons:
1) Risk of irreversable data loss (peril)
The poster's mentioned a failing hard drive upfront, so IMO the first
thing you want to do is to avoid any writes to the at-risk hard drive.
If that hard drive is the one with Windows on it (unlikely) then I'd
not want to boot Windows at all, until I'd evacuated anything I wanted
to see again, because it is impossible for Windows to run without
writing to its own file system (page file, temp files, etc.)
The the sick hard drive isn't the one with Windows on it, I'd still
want to protect the hard drive first, by disabling System Restore on
it, and ensuring it's not targeted by page file writes, thumbnailers,
indexers and what-have-you.
Perhaps the poster has already made copies of everything that was on
the sick hard drive, but that hasn't been stated, so can't be assumed!
2) Last-reported is often NOT the point of failure (off-centered)
Often there are contexts where some per-step reporting is done, but
this is preceded and followed by large "silent" stages where no
progress indication is provided. Classic examples:
- ESCD Update (last visible output of BIOS POST)
- mups.sys or agp440.sys (last reported load in Safe Mode)
- reading boot log files in Win9x
I've yet to see a true failure in Mups.sys, or the AGP440.sys that
follows it in some systems, but I often see failures during the "dark"
period of startup that follows this reported stage and the appearance
of the desktop. A log seems to go wrong in that "dark" phase
Tell me more about this HD, e.g.
- what tells you that it is going bad?
- is it from the same PC?
- is it the boot HD?
Interesting you stipulate "with networking".
If Safe Mode without networking is OK, then make sure there are no LAN
drive letter mappings on the sick HD - if there are, then this could
initiate access to the sick HD (and bog down in retries) either
because the OS is fiddling with the HD, or because other systems are
trying to read the share. Remember the hidden LAN shares, if this is
XP Pro and you have a non-blank user password!
If Safe Mode without networking also fails, then I'd ask whether the
sick HD is from this PC or another, as mis-reading the geometry of the
HD has had this effect in my experience. I have also seen some
slightly-dented NTFS crash NTFS.SYS in all contexts, including Bart PE
CDR boot and booting Linux that shells NTFS.SYS to access NTFS.
Prolly not relevant to this scenario (unless failures are when you try
to boot the sick HD, and affect all Safe Mode variations as well), but
this is the failure pattern one sees if:
- you have Prescott or Pentium Extreme processor
- your BIOS does not push microcode revisions to the CPU
- you install XP SP2
See
http://cquirke.mvps.org/sp2intel.htm on that, if applicable
-------------------- ----- ---- --- -- - - - -
Tip Of The Day:
To disable the 'Tip of the Day' feature...
