jim said:
I have a situation where I need to replace the directory hives on two data
disks (IOW, not current boot disks) from a currently bootable disk of
Win XP Pro SP3.
By selective disconnections from the IDE ribbon cable I observe repetitive
problems with the two data disks and I am told that the most likely
problem is a corrupted directory. The problem with both data disks when
used as boot disks:
1. POST is normal
2. BIOS verifies.
3. First windows screen displays for several seconds. (the black one with
a Windows logo.)
4. BSOD that appears and then disappear before any information can be
retrieved.
- return to restart.
(If i did not use all the right words, sorry.)
The current boot disk is showing signs of flakiness -- it had an uncalled
for in-session reboot yesterday. That tells me that its life is now on
loan. So i want the others to be ready to go when it fails.
All three disks have Windows XP pro installations and updates as follows:
hdd0 SP2, plus updates until SP3
hdd1 SP3 < -- currently booting disk
hdd2 SP2, plus updates until SP3
If Google search has details on this operation, I have not found them.
jim
Have you run disk diagnostics on these three disks ?
For example, Seagate has Seatools, and Western Digital has diagnostics
available for download as well. If the disks pass, it could be
some portion of the file system is corrupted.
You can use HDTune "Health" tab, to examine the SMART data on the
three disks. You can also do a read-only bad block scan, using the
right-most tab in the interface.
http://www.hdtune.com/files/hdtune_255.exe
The CHKDSK utility when run, can attempt to repair file system damage.
Up to a point. Because it is a "repair in place" utility, it can
also ruin things. Which is where "backups" come in. You should
have full backups. And a fourth disk would provide a safe place
for them, if there isn't room on the other disks.
You can "repair" a file system, by copying the files off, reformatting
the partition, then copying the files back. The FAT (file allocation table)
or MFT (master file table) or whatever, would be refreshed, by starting
from scratch, and copying back the files.
What I would do (as a non-IT guy):
1) Review test results of the three disks. Did any fail ?
You want to back up the failed disk right away.
If the damage is severe, you do a sector by sector backup.
If the damage is light, a file by file backup is sufficient,
since your expectation is, all the files are intact. The sector
by sector is used, when you fear losing the whole thing.
2) Do a bad block scan, to check whether any sectors are unreadable.
If there are unreadable sectors, which are not cordoned off in
a bad cluster, then things associated with those sectors would be
broken. If the bad block scan is clean, it means maintenance
will be easier.
In this example, a badly damaged disk is copied off sector by sector.
Later, you'd copy this image back, to the new disk you bought. And
then, do further repair work, in the knowledge that any further writes
won't get corrupted.
http://www.cgsecurity.org/wiki/Damaged_Hard_Disk
# first, grab most of the error-free areas in a hurry:
./ddrescue -n /dev/old_disk /dev/new_disk rescued.log
# then try to recover as much of the dicy areas as possible:
./ddrescue -r 1 /dev/old_disk /dev/new_disk rescued.log
3) If all disks were healthy, and this was only a file system level
issue, I'd
a) boot hdd2 SP2
b) Create a partition the size of hdd1 SP3, with matching file system type,
in spare area on hdd2 or hdd0.
c) Copy the contents of hdd1 SP3 to the new partition just created.
http://en.wikipedia.org/wiki/Robocopy
# Download site
http://technet.microsoft.com/en-us/magazine/2006.11.utilityspotlight.aspx
If I wanted to copy all the files off a partition with letter "J:" to
a *completely empty* partition "E:", I'd do it like this.
robocopy J:\ E:\ /mir /copy:datso /dcopy:t /r:3 /w:2 /zb /np /tee /v /log:robocopy_J_to_E.log
d) Once the copy is complete (could take 20 minutes, so relax), next
I'd go into Disk Management and reformat the partition I just copied off.
If the source partition was J:, I'd be reformatting it, to the same
file system standard as it had before. If it was an oversized FAT32
partition, and Windows refused to format it, I'd club it into submission
with the fat32formatter, as in fat32formatter.exe J:
http://www.ridgecrop.demon.co.uk/download/fat32format.zip
The Disk Management NTFS format capability, by comparision, doesn't have
issued, so no third-party would be needed in that case.
e) Now, I can put the files back on the clean J: like this.
robocopy E:\ J:\ /mir /copy:datso /dcopy:t /r:3 /w:2 /zb /np /tee /v /log:robocopy_E_to_J.log
f) Copying off the files like that, does not copy the "partition boot sector".
To fix that, you would shut down, disconnect the good disks HDD0 and HDD2,
(to avoid confusion), boot with the WinXP installer CD, so you could
access the Recovery Console. And run a "fixboot c:" from there. That
will put back the partition boot sector on hdd1's new WinXP partition.
g) (You could reconnect the other two disks at this point if you want.)
h) For extra points, you could use "VolumeID" to put back the original
volume ID that HDD1 had. But perhaps this is too much nit-picking.
I get the VolumeID with Everest (free) Home Edition, then restore
it later.
http://technet.microsoft.com/en-us/sysinternals/bb897436
i) At this point, the idea would be, the HDD1 WinXP partition has a
fresh file system, with minty fresh FAT or MFT, and all the files
copied back. This does not preclude damage happening along the
way, and a disaster awaiting when you boot the system with that disk.
Now, you adjust the BIOS boot order, so that HDD1 is again selected
to boot.
j) If any step fails along the way, you'd have that copy on E: to
save you. And you wouldn't erase J:, until you'd satisfied yourself
the copy on E: was complete.
Anyway, I doubt you're going to do all that, but there are tools
around, command line and otherwise, that allow repair attempts.
In the above, I've made no mention of "directory specific" repairs,
or "copying a registry file" or the like. Because at this point,
I don't really know what's broken. There are undoubtedly other
issues there.
And if you want to run CHKDSK on that drive, you'd boot from
HDD0 or HDD2 and run it from there, on the now "non-busy" HDD1
WinXP partition. Otherwise, CHKDSK on a busy partition, can only
run during the boot process. Since you have multiple OS partitions,
you can boot one of those, and then CHKDSK can run at an arbitrary
time. But I would not be using CHKDSK at all, until I had my
backup in place. A backup done with "ddrescue" method, if the
disk is really in a mess. Or, using some other $39.95 type utility
(Acronis) if it is in relatively good shape.
Summary:
1) Do backups, before using "in-place" repair tools such as CHKDSK.
Do backups, "before it is too late". If the drive is "clicking",
backup now! If you hear clicking, you might also want to backup
without powering off or rebooting, in case the drive is going to
die in the next ten minutes.
2) You can repair a file system, by copying the files off while the
partition is not busy.
3) There are a ton of half-baked utilities around, for fixing this
and that.
Paul
I