FAT partitions & data lost?

[GHB]

Hi,

Just to add to the list of data recovery posts, I have the following
situation:

Dad's PC failed to boot up over the weekend, and subsequently ended up with
a 'missing operating system' hang and an inaccessible C: drive on a 20Gb
partition of a 40Gb IDE disk.

After investigating a little, it seems that the MBR and FAT have been
corrupted and the boot partition is now undefined and inaccessible.

Is it possible to retrieve the data from the disk by some method of
rebuilding the MBR / FAT or low-level data search tool?

And could you provide simple step-by-step instructions of how to do it?

I'm not a complete novice with PC's, having built, maintained and
trouble-shooted them for about a decade, but disk failures like this are
beyond my previous experience and I need some assistance.

I know I need to clone the disk and work on the copy, but what do I use to
do it? Ghost? does the target for the clone need to be the same size as the
failed disk?

What do I do from there to recover the data?

All help gratefully received!!

Thanks,

GHB.

 

[Joep]

Hi,

Just to add to the list of data recovery posts, I have the following
situation:

Dad's PC failed to boot up over the weekend, and subsequently ended up with
a 'missing operating system' hang and an inaccessible C: drive on a 20Gb
partition of a 40Gb IDE disk.

After investigating a little, it seems that the MBR and FAT have been
corrupted and the boot partition is now undefined and inaccessible.

How was this determined?

Is it possible to retrieve the data from the disk by some method of
rebuilding the MBR / FAT or low-level data search tool?

Maybe, no one can tell without actually (or virtually) looking at the disk.
Rebuilding the MBR and partition tables and boot sectors is often do-able
and safe. I'd not use software that does 'automatically' fix the FAT
(basically the unformat type tool, in 50% of the cases they will do more
harm than good).

And could you provide simple step-by-step instructions of how to do it?

No, it depends on the situation.

I know I need to clone the disk and work on the copy, but what do I use to
do it? Ghost? does the target for the clone need to be the same size as the
failed disk?

Cloning is wise, yes. Or at least some safety net so you're able to undo
your repairs.

What do I do from there to recover the data?

You could download a DiskPatch demo version from www.diydatarecovery.nl.
With that make a logfile and post that in the DIY DataRecovery Support
forum.

Or you can wait and see if some people in this newsgroup can help. A warning
though, it appears some of those people wil use other people's disks for
target practice.

 

[GHB]

How was this determined?

PC Inspector / Patch Disk / Partition Table Doctor. I may be reading the
results / error messages wrong, but they all seemed to say that the
partition table and MBR was corrupted / gone.

Maybe, no one can tell without actually (or virtually) looking at the disk.
Rebuilding the MBR and partition tables and boot sectors is often do-able
and safe. I'd not use software that does 'automatically' fix the FAT
(basically the unformat type tool, in 50% of the cases they will do more
harm than good).

So what do I need to do to figure out exactly what the problem is and
whether the data is recoverable?

No, it depends on the situation.

Ok, so the first step would be?

Cloning is wise, yes. Or at least some safety net so you're able to undo
your repairs.

Do I use Ghost or some other low-level cloning app?

You could download a DiskPatch demo version from www.diydatarecovery.nl.
With that make a logfile and post that in the DIY DataRecovery Support
forum.

I'm not at home with the disk right now, but I will do that later.

Or you can wait and see if some people in this newsgroup can help. A warning
though, it appears some of those people wil use other people's disks for
target practice.

Thanks so far.

GHB.

 

[GHB]

Ok, so the first step would be?


I'm not at home with the disk right now, but I will do that later.

Text below from the findpart search.

I'm a little confused by the first line - the top of the disk says it is
CHS - 16383/16/63 with logical heads/sectors 255/63 and total sectors
80418239. The report doesn't seem to tie up with the hardware label?
Should the CH settings be different?
------------------------------------------------------------------
Disk: 1 Cylinders: 5318 Heads: 240 Sectors: 63 MB: 39262

-PCyl N ID -----Rel -----Num ---MB -Start CHS- --End CHS-- BS CHS
Fdisk F6 sector 1094 0 1
Fdisk F6 sector 1094 1 1
Fdisk F6 sector 1095 1 1
Fdisk F6 sector 1097 0 1
Fdisk F6 sector 1097 1 1
Fdisk F6 sector 1099 0 1
Fdisk F6 sector 1099 1 1
Fdisk F6 sector 1100 0 1
Fdisk F6 sector 1100 1 1
2660 1 0B 63 40188897 19623 2660* 1 1 197 254 63 R0 NB
0 - 0B 40219263 40188897 19623 2660 1 1 5317 239 63 B OK

-----FAT CHS -Size Cl --Root -Good -Rep. Maybe --Bad YYMMDD DataMB
155 0 2 7 1 0 0 6 040731
2660 1 33 9810 16 2 9810 0 0 0 010612 12800

Partitions according to partition tables on first harddisk:

-PCyl N ID -----Rel -----Num ---MB -Start CHS- --End CHS-- BS CHS
0 1?F6 --- ----74017 1014 246 54 1014 246 54 NB
0 2?F6 --- ----74017 1014 246 54 1014 246 54 NB
0 3?F6 --- ----74017 1014 246 54 1014 246 54 NB
0 4?F6 --- 63222 30 1014 246 54 1014 246 54 NB
------------------------------------------------------------------------

There should be 2 partitions on the disk. The first, a FAT32 of 19638Mb and
the second, FAT32 of 19623Mb.

Where do I go from here?

GHB.

 

[Zvi Netiv]

Just to add to the list of data recovery posts, I have the following
situation:

Dad's PC failed to boot up over the weekend, and subsequently ended up with
a 'missing operating system' hang and an inaccessible C: drive on a 20Gb
partition of a 40Gb IDE disk.

Does it mean that the D: drive (partition) is accessible (from external boot),
or anything past C: disappeared?

After investigating a little, it seems that the MBR and FAT have been
corrupted and the boot partition is now undefined and inaccessible.

"Usually", it's only the partition table that gets corrupted. Corrupted /
blanked FAT is in most cases collateral damage, induced by the application of
the wrong tools or methods to rectify the problem.

Is it possible to retrieve the data from the disk by some method of
rebuilding the MBR / FAT or low-level data search tool?

If the problem is just a corrupted partition table in the MBR, or even boot
sector, then the entire drive can be restored to functional state. If OTOH you
managed to mess with the FAT and/or the directories area, then chances to
recover data decrease rapidly. The presence of F6 sectors (you may have been
playing with FDISK?), as reported in one of your follow-up posts isn't good
news.

And could you provide simple step-by-step instructions of how to do it?

I'm not a complete novice with PC's, having built, maintained and
trouble-shooted them for about a decade, but disk failures like this are
beyond my previous experience and I need some assistance.

I know I need to clone the disk and work on the copy, but what do I use to
do it? Ghost? does the target for the clone need to be the same size as the
failed disk?

I suspect that cloning may fail in your case, regardless of the software used (I
use our own, CloneDisk, but Ghost can do it too, with the correct switches). In
a follow-up post I read something about "240 heads". If the drive was
configured with 255 heads in the BIOS, and is now set as 240 heads, then it
would explain the disappearing of the partitions, and the collateral damage to
system areas, if you attempted to fix things with the wrong geometry
configuration.

Cloning with the wrong CHS parameters in the BIOS will produce a majestically
worthless clone, no matter what software you use.

What do I do from there to recover the data?

Download RESQ from www.resq.co.il/resq.php, prepare a work floppy as instructed
on the program's welcome screen, boot of the floppy (leave it write enabled),
and from the A: prompt run RESQDISK /ASSESS A text file report will be
created on the floppy, named ResQdisk.rpt. Post it here.

Regards, Zvi

 

[Folkert Rienstra]

Does it mean that the D: drive (partition) is accessible (from external boot),
or anything past C: disappeared?

What, you don't understand Svend's Findpart or a PartInfo report?

"Usually", it's only the partition table that gets corrupted.

Corrupted / blanked FAT is in most cases collateral damage, induced by
the application of the wrong tools or methods to rectify the problem.

Or just the rest of the transfer that also wiped out the MBR, which is far
more likely.

If the problem is just a corrupted partition table in the MBR, or even boot
sector, then the entire drive can be restored to functional state. If OTOH you
managed to mess with the FAT and/or the directories area, then chances to
recover data decrease rapidly.

The presence of F6 sectors (you may have been playing with FDISK?), as
reported in one of your follow-up posts isn't good news.

I have several F6 sectors and my partitions are fine. F6 sectors are remnants in
places that are not written to or in data areas that have not yet been overwritten.

I suspect that cloning may fail in your case, regardless of the software used
(I use our own, CloneDisk, but Ghost can do it too, with the correct switches).
In a follow-up post I read something about "240 heads". If the drive was
configured with 255 heads in the BIOS, and is now set as 240 heads,

then it would explain the disappearing of the partitions,

But they haven't, or at least not all, which rules that out.

and the collateral damage to system areas, if you attempted to fix things with
the wrong geometry configuration.

That would mean that the fixing app would read the info using LBA but would
write it using CHS. That isn't very plausible.

Cloning with the wrong CHS parameters in the BIOS will produce a majestically
worthless clone, no matter what software you use.

Rotflol. Cloning software using CHS. What next.

 

[Folkert Rienstra]

(e-mail address removed)>

but apparently not now

wrote in message news:[email protected]...

Text below from the findpart search.

I'm a little confused by the first line - the top of the disk says it is
CHS - 16383/16/63 with logical heads/sectors 255/63 and total sectors
80418239.

The report doesn't seem to tie up with the hardware label?

Should it?
CHS - 16383/16/63 is the default translation CHS for all drives over 8GB
on the physical side (=drive side). This will inform the bios of how to translate
this to a logical form suitable for BIOS input (Int13, program side of the bios).

255/63 is the preferred/necessary default logical geometry (program side
of the bios) for drives over 8GB to be able to access the full 8GB by CHS.
Findpart apparently is showing a logical translation.
Either that or the physical CHS is shown in logical format due to the fact that
the 8GB limit is in effect and the output should be invalid, but is nevertheless
used. I hope Svend can clear that up at one time or other.

Should the CHS settings be different?

Maybe. The line is invalid anyway for any value of C*H*S*512 over 8GB.
It may be a problem if the bios is configured for Large and you try boot
from it with the bios in Large mode.
For an extra (ie non-bootable) drive it will be ignored.
For LBA assist mode it won't likely matter either unless the partition
bootsector is after 239 63.

-PCyl N ID -----Rel -----Num ---MB -Start CHS- --End CHS-- BS CHS
Fdisk F6 sector 1094 0 1
Fdisk F6 sector 1094 1 1
Fdisk F6 sector 1095 1 1
Fdisk F6 sector 1097 0 1
Fdisk F6 sector 1097 1 1
Fdisk F6 sector 1099 0 1
Fdisk F6 sector 1099 1 1
Fdisk F6 sector 1100 0 1
Fdisk F6 sector 1100 1 1

Partition boot records:
-PCyl N ID -----Rel -----Num ---MB -Start CHS- --End CHS-- BS CHS

2660 1 0B 63 40188897 19623 2660* 1 1 197 254 63 R0 NB

Looks OK for your 2nd Fat32 partition but the "CHS NB" says not.
Presumably because of the false End CHS (End CHS before Start CHS).

In reality the 2660 is 1023. So should be the End CHS.

-PCyl N ID -----Rel -----Num ---MB -Start CHS- --End CHS-- BS CHS

0 - 0B 40219263 40188897 19623 2660 1 1 5317 239 63 B OK

Doesn't look OK but Svend apparently doesn't see a problem with it.
However, put a space in there and:

-PCyl N ID -----Rel -----Num ---MB -Start CHS- --End CHS-- BS CHS
0 - 0B 402192 63 40188897 19623 2660 1 1 5317 239 63 B OK

Program error? Or 'user trying to edit partition tables' error?

This, btw, looks like this could be your first partition (Partition at cyl 0)
except that Start/End appear to say otherwise.
God knows where it got the CHS numbers from.

Looking at it differently it could be your 2nd partition (extended partition lo-
gical) displayed as a 2nd primary partition, but again the numbers don't add up.
I would love to see Svend's explanation for that line.

-----FAT CHS -Size Cl --Root -Good -Rep. Maybe --Bad YYMMDD DataMB
155 0 2 7 1 0 0 6 040731

Likely a false positive since it isn't at an xxxx 1 33 offset.

2660 1 33 9810 16 2 9810 0 0 0 010612 12800

The FAT belonging to that partition at PCyl 2660

Partitions according to partition tables on first harddisk:

-PCyl N ID -----Rel -----Num ---MB -Start CHS- --End CHS-- BS CHS
0 1?F6 --- ----74017 1014 246 54 1014 246 54 NB
0 2?F6 --- ----74017 1014 246 54 1014 246 54 NB
0 3?F6 --- ----74017 1014 246 54 1014 246 54 NB
0 4?F6 --- 63222 30 1014 246 54 1014 246 54 NB

Your partition table is completely overwritten.

The first, a FAT32 of 19638Mb

Is a goner.

and the second, FAT32 of 19623Mb.

May be reintroduced.

 

[Eric Gisin]

Your partition table is completely overwritten.

Everyone missed this: The partition table is entirely F6.

Fdisk doesn't do that. An interrupted LLF? A virus?

 

[Zvi Netiv]

What, you don't understand Svend's Findpart or a PartInfo report?

Do you?

[...]

I have several F6 sectors and my partitions are fine. F6 sectors are remnants in
places that are not written to or in data areas that have not yet been overwritten.

It's common knowledge what F6 sectors are. My comment was about finding them
where they aren't expected or supposed to be.

[...]

But they haven't, or at least not all, which rules that out.

We don't know that and the OP didn't provide that information. The presence of
a partition in the Findpart listing doesn't tell if the partition is accessible,
from external booting, for example. Which is what I was referring to.

That would mean that the fixing app would read the info using LBA but would
write it using CHS. That isn't very plausible.


Rotflol. Cloning software using CHS. What next.

Obviously, you haven't seen everything yet in data recovery. Cloning software
uses whatever the drive uses, extended interrupt 13 in this case, which is LBA.
The point is that LBA yields different drive mapping, depending on the BIOS
settings.

Regards, Zvi

 

[wemaole]

Is it possible to retrieve the data from the disk by some method of

rebuilding the MBR / FAT or low-level data search tool?

partition table doctor can fix. It provides very useful functions:
Backup partition table, Restore partition table, Rebuild partition
table, undelete partition,Fixboot.

rebuild partition is most quickly method to find data back!
if you have any question,please look:
How to Recover Lost or Deleted Partition
http://www.ptdd.com/recoverylostpartition.htm

 

[Folkert Rienstra]

Everyone missed this:

No, I did spot it but is wasn't entirely F6'es so I left it at "is overwritten".

The partition table is entirely F6.

Not entirely if Findpart is to believed.
Rel and Num should both read 4,143,380,214 if it was.
At least the Rel value "---" in N4 is '0' (or 06F6h) and 63222 (or 61440)
sectors make around 30MB. No idea where it gets the 74017 MB from.
It may actually be royally confused.

Fdisk doesn't do that.

But maybe Fdisk in combination with Svend's 32GB Windows foldback bug
(that isn't really about 32GB) but is triggered by less than 255 heads may
have done it. But then it should be entirely F6.

 

[Folkert Rienstra]

Svend, your comments please.

Should it?
CHS - 16383/16/63 is the default translation CHS for all drives over 8GB
on the physical side (=drive side). This will inform the bios of how to translate
this to a logical form suitable for BIOS input (Int13, program side of the bios).

255/63 is the preferred/necessary default logical geometry (program side
of the bios) for drives over 8GB to be able to access the full 8GB by CHS.
Findpart apparently is showing a logical translation.
Either that or the physical CHS is shown in logical format due to the fact that
the 8GB limit is in effect and the output should be invalid, but is nevertheless
used. I hope Svend can clear that up at one time or other.


Maybe. The line is invalid anyway for any value of C*H*S*512 over 8GB.
It may be a problem if the bios is configured for Large and you try boot
from it with the bios in Large mode.
For an extra (ie non-bootable) drive it will be ignored.
For LBA assist mode it won't likely matter either unless the partition
bootsector is after 239 63.


Partition boot records:
-PCyl N ID -----Rel -----Num ---MB -Start CHS- --End CHS-- BS CHS

Looks OK for your 2nd Fat32 partition but the "CHS NB" says not.
Presumably because of the false End CHS (End CHS before Start CHS).

In reality the 2660 is 1023. So should be the End CHS.

-PCyl N ID -----Rel -----Num ---MB -Start CHS- --End CHS-- BS CHS

Doesn't look OK but Svend apparently doesn't see a problem with it.
However, put a space in there and:

-PCyl N ID -----Rel -----Num ---MB -Start CHS- --End CHS-- BS CHS
0 - 0B 402192 63 40188897 19623 2660 1 1 5317 239 63 B OK

Program error? Or 'user trying to edit partition tables' error?

This, btw, looks like this could be your first partition (Partition at cyl 0)
except that Start/End appear to say otherwise.
God knows where it got the CHS numbers from.

Looking at it differently it could be your 2nd partition (extended partition lo-
gical) displayed as a 2nd primary partition, but again the numbers don't add up.
I would love to see Svend's explanation for that line.


Likely a false positive since it isn't at an xxxx 1 33 offset.


The FAT belonging to that partition at PCyl 2660


Your partition table is completely overwritten.


Is a goner.


May be reintroduced.

 

[Folkert Rienstra]

Do you?

Less and less, I'm afraid :-(

[...]

I have several F6 sectors and my partitions are fine. F6 sectors are remnants in
places that are not written to or in data areas that have not yet been overwritten.

It's common knowledge what F6 sectors are.

Is it?

My comment was about finding them where they aren't expected or supposed to be.

Which is a bit difficult without the first FAT to tell us how much of the primary
partition was used. The (very few) F6 are clustered thightly at around 9GB.

[...]

But they haven't, or at least not all, which rules that out.

We don't know that and the OP didn't provide that information.

Findpart did.

The presence of a partition in the Findpart listing doesn't tell if the partition
is accessible,

That is not the point. It is there. It is not accessable because the MBR is gone.
*If* the CHS was different *and* the bios in (CHS) translation mode *and*
Findpart in CHS mode *then* Findpart would be looking in all the wrong pla-
ces and not find any partitions unless by sheer coincidence. And it wouldn't
be because of the addressing mode itself but because of the values themselfs
that Findpart would use to define what it considers places to look in.

from external booting, for example.

Without the MBR nothing will be seen by any OS.
That has nothing to do with Int13 CHS settings.

Which is what I was referring to.

Can't be. You were referring to 240 heads vs 255 heads settings.
Since the 2nd partition itself is far beyond 8GB and not addressed
using CHS and the 240 heads vs 255 heads is only a problem after
~7MB, that can't possibly obscure the partitions defining data.

Btw, Svend and your good friend Joepie appear to disagree with you
too when they say that the CHS doesn't matter (i.e. ignored) at all.

Obviously, you haven't seen everything yet in data recovery. Cloning software
uses whatever the drive uses, extended interrupt 13 in this case, which is LBA.

Right, so obviously not using CHS at all.

The point is that LBA yields different drive mapping, depending on the BIOS
settings.

Nope, it does *not*.
LBA is LBA. LBA assist is CHS and of a different (bios internal) matter.
BIOS settings only affects the (old) Int13/AH=0x calls, not the (new) Int13/AH=4x
ones.

The only time CHS goes wrong is when the software (program/driver/bios) uses a
different CHS internally than the hardware does (or the next stage that is passing
the data (driver/bios)).

 

[Zvi Netiv]

"Zvi Netiv" <support@replace_with_domain.com> wrote in message

You are wrong, but it's pointless to explain to you why.

Regards, Zvi

 

[Folkert Rienstra]

You are wrong, but it's pointless to explain to you why.

Then I dare you to explain it for the benefit of this group.

 

[Joep]

Then I dare you to explain it for the benefit of this group.

I dare you to go and never come back for the benifit of the group.

 

[Joep]

There is no benefit to the group in explaining when you are wrong, e.g. type
zero partitions, etc.

yes, those type zero partitions are his best invention ;-)
Yep, the "free space partitions", brilliant.

 

[Zvi Netiv]

Then I dare you to explain it for the benefit of this group.

There is no benefit to the group in explaining when you are wrong, e.g. type
zero partitions, etc.

Regards