Corrupted Disk; XP Recovery useless

[Me]

I have a month or so of work at stake here...

Windows XP SP1, AMD on an ABit NF7, IBM GXP IDE.

I was playing a movie file when at one point it froze and started repeating
the last second or so of sound over and over. After killing the process,
thinking it was just a bad mpeg, I tried moving the file elsewhere but the
move froze too. In fact it caused a serious error in XP which shut itself
down and flagged the partition J:, that held the file, for a scandisk on
next reboot.

The reboot did the scandisk which reported an error with the movie file and,
strangely, that it could not write a log. Windows proceeded to load but just
before the log on screen the harddisk made the read-activity noise lasting
for about one second, but repeatedly over and over, causing the system to
freeze. This lasted a while, then windows loaded but it soon froze in the
manner described, again and again - I assume it froze everytime Windows
tried to access J:. This partition was inaccessible through My Computer.

Here are some points to note:
J: is on Disk 2 which is a non-system disk. It is the second partition on
the disk (out of 3 total).

Unplugging Disk 2's IDE cable results in a good-working Windows XP, of
course without the data that's on J:

The other partitions on Disk 2 seem fine (when plugged in although there are
frequent freezes, the other partitions are indeed accessible, not sure if
there's a way to just disable J: only for now)

Using some trial software it determined that the boot sector on the
partition J: was corrupt.

Using Recovery XP I tried fixboot, which had to determine the format of the
partition. A 'map' prior to this showed an unknown (blank) format. It
decided the format was FAT16, however I know it was a FAT32

After using Recovery a chkdsk still did not work saying something about
unrecoverable errors on the partition. A surface scan seemed to work and was
doing fine until I stopped it because it was taking forever.

Most recovery software go on about MBR recovery and boot sectors for the
system disk. This is not a system disk, just a data partition, and yet it
cannot even be accessed by many of the recovery/disk softwares (e.g.
Norton).

PMagic's info on J: did indeed show a very messed up boot sector, the format
is a garbled mess, not saying FAT32 like the other partitions.

---------

Most advice seems to recommend reformatting etc. but I would like to
restore/save the data or at least as much as possible. Is there a way?
Perhaps editing the boot sector manually to let XP know it's FAT32 (does the
boot sector even have a purpose on a non-system disk?)

Thanks for taking your time to read this.

 

[Mark]

i dont know if this would help, but i had something happen to me when i
finished a defrag on XP. It was an FAT32 partition. Defragmenter crashed and
stayed there for 30 minutes or so, so i closed it (forced) then when i
restarted the partition was corrupt. I didnt want to do much since all my
data was on that partition. So after a few things, i went into DOS with a
boot ME cd i made a few years ago, and i got to see my partition in full and
perfectly working. so i converting another partition to fat32 and booted off
the cd, moved all the files from the "corrupt" partition to the good one,
and everything is back.

I dont know if this would be useful to you, but just thought id post it
nevertheless.

 

[Joep]

I tried the demo of that,

DiskPatch or iRecover?

 

[Me]

DiskPatch or iRecover?

DiskPatch. I shall look into iRecover too.

 

[Ragnhild]

I'm looking at GetDataBack (seems a bit simpler to use) which is actually
showing surviving files that were on the partition, most the time it's going
into that freeze/repeated-read mode so it's taking a long time. I will
probably use that first to salvage what I can then try to see if the disk
can be saved by looking at the "riskier" software like DiskPatch.

Hi,

If GetDataBack seems to freeze during the scan of your drive, this
could be due to a large number of bad sectors on your drive. If this
is the case you probably should make an image of the whole drive
first, and then let the software scan this image for your lost files.
You can create an image with GetDataBack in the 2. Step of the
recovery process. Creating an image is usually much faster than the
scan, because the software is reading every sector only once. It's
also saver, because this way you won't work with the problematic drive
any longer than you have to. However, you would need another drive
that has enough space so you can save the image to it.

Ragnhild
Runtime Software
http://www.runtime.org

 

[Joep]

Hi,

You may want to make sure the disk is not physically bad. You can use the
DiskPatch demo to do a surfece scan that will reveal read errors. In case
read errors are reported, your next step should be to make a clone of the
entire disk as soon as possible (this the DiskPatch demo will not do, you'd
need to register it). Attempt repair or recovery on the clone.

If things can be repaired depends upon which file system area's were using
the bad sectors. If it was the boot sector and some FAT sectors for example,
repairing the logical damage may very well be possible. If large areas
containing file system information were 'hit' this may become more
difficult.

Joep

--
D I Y D a t a R e c o v e r y . N L - Data & Disaster Recovery Tools

http://www.diydatarecovery.nl
http://www.diydatarecovery.com

Please include previous correspondence!

DiskPatch - MBR, Partition, boot sector repair and recovery.
iRecover - FAT, FAT32 and NTFS data recovery.
MBRtool - Freeware MBR backup and restore.

 

[Folkert Rienstra]

Thanks for the idea, I just tried it. Using a Win98SE 'boot disk' used for
Windows setup,

it showed the unharmed partitions fine as it should.

You appear to contradict that below.

When I tried J: it managed to change the prompt to J: fine, but started
that freezing with repetitive trying-to-read-the-same-sector noise again

Bad sectors.

(even for something as simple as this!)

Which may be less simple as you think. It reads the drive to see if you can.

and ended up failing a dir show.

In fact it couldn't read other partitions on that disk properly giving
garbled, odd-sized files,

So what happened to: "it showed the unharmed partitions fine as it should"

whereas XP could (albeit with the freezing); find this last
bit strange - perhaps it means the MBR for the entire disk could be the
culprit too, might trying fixmbr after all else fails.

That won't change anything to the partition tables

 

[Me]

You appear to contradict that below.

Yes, I have no idea why I said the above . Perhaps I meant my system disk
showed up fine, been a long day.

 

[Folkert Rienstra]

Hi,

If GetDataBack seems to freeze during the scan of your drive, this
could be due to a large number of bad sectors on your drive. If this
is the case you probably should make an image of the whole drive
first, and then let the software scan this image for your lost files.
You can create an image with GetDataBack in the 2. Step of the
recovery process.

Creating an image is usually much faster than the scan,
because the software is reading every sector only once.

Well, the software might but the drive will still exhaust it's retries
unless the cloning software uses special instructions to avoid that.

 

[Folkert Rienstra]

Hi,

You may want to make sure the disk is not physically bad.

You can use the DiskPatch demo to do a surfece scan that will reveal read errors.

In case the drive is physically bad that is what you want to avoid.

In case read errors are reported,

In which case the surface scan is already one scan too many.

your next step should be to make a clone
of the entire disk as soon as possible

If that is so urgent then that surface scan
was the equivalent of murderous torture.

(this the DiskPatch demo will not do, you'd need to register it).
Attempt repair or recovery on the clone.

So make a clone without further ado. If it doesn't give you read
errors you can decide on which drive you want to do the recovery.

 

[Joep]

Hi,



Well, the software might but the drive will still exhaust it's retries
unless the cloning software uses special instructions to avoid that.

Isn't that what he said: each sector is only read once - where during normal
operation retries occur.

Joep

 

[Joep]

It's polite to say hi or hello. So: Hello,

read errors.

In case the drive is physically bad that is what you want to avoid.

Well, it is *always* safer to clone anyway before doing anything else, yep.

In which case the surface scan is already one scan too many.

There is a *slight* chance that it is one to many. DiskPatch has helped
hundreds in similar scenarios and never caused scanning the disk (even
several times) more read errors to occur. However *it may* do more damage
than good theoretically, IRL we have never witnessed that, so it's not by
definition - which you make it sound like - that every scan is one to many.
Anyway DiskPatch will stop scanning if too many read errors occur to protect
the drive and pop up a message suggesting to clone the drive asap.

One factor that may be relevant though - from contacts I have with a company
that does in-lab recoveries I have learned that there may be a correlation
between the warm weather and the number of disks that are offered to them.
So, the warmer it is the more disks are offered. This isn't a scientific
fact but it seems important enough to consider anyway.

Intensive r/w actions will make that the disk temperature increases, so
before doing so make sure it is properly cooled. I don't know where OP is,
but temperatures may be a factor to be aware of.


Joep

 

[Folkert Rienstra]

To avoid that, you would use the Read Long command and check
the ECCs yourself. Or use the streaming command set.

Isn't that what he said: each sector is only read once -

Not when the drive retries.

where during normal operation retries occur.

Retries by the software after the drive posts an error.
The drive already will have retried the individual sector
several times (to the retry limit) before that.

 

[Joep]

To avoid that, you would use the Read Long command and check
the ECCs yourself. Or use the streaming command set.

Can you do that using extended int13h commands? Ralph Browns list suggests
this is only possible with int13h commands which would limit access to only
the first 1024 cylinders.

Can't find anything practical on the 'streaming command set', do have URL's?

Not when the drive retries.

Okay, fair enough.