Total loss of Hard Drive FATs? (Findpart output included)

[Chris Bailiss]

Hello,

(Please reply to the group, as my email is currently broken).

I am unable to read any files from my primary slave drive, and would
be very grateful for any advice from those more experienced.

My primary master hard drive was partitioned into two partitions using
Partition Magic some time ago.

My OS is win2000 SP4, installed in the primary partition on primary
master, and has worked fine for a long time.

The primary slave drive is a 200GB Maxtor. I have installed MaxBlast
3. I was not sure if I needed to do so, since although I understand
that Win2000 + SP4 should support above the 137GB limit, my BIOS
reports the drive as being 137GB. Anyway, this has also worked fine
for several months.

Yesterday I installed Windows XP into the second partition on my
primary master. This made win2000 unbootable. Ran the repair option
for win2000 from the win2000 CD. Repaired and booted fine. Primary
slave still working fine.

Today I attempted to boot the XP install. This is where it went
really wrong. I received a "Unable to boot Windows 2000" error. (Why
it was trying to boot win2000 I have no idea, boot.ini appeared fine).
In any case, this seems to have catastrophically affected the primary
slave (again, since this is a totally separate drive I have no idea
why it should have affected this).

In win2000 the drive appears, but attempts to open it from "My
Computer" give a 'Drive Not Formatted - Do you wish to format?'
message.

I want to retrieve the data on the drive as much as possible.
Needless to say, I have not selected to format the drive!

I have run the findpart utility (many thanks for this, Svend, if you
are reading):

C:\data\findpart>findpart 2

Findpart, version 4.43 - for Windows 95/98/ME/NT/2000/XP.
Copyright Svend Olaf Mikkelsen, 1999-2004.

OS: Windows 5.0.2195 Service Pack 4

Disk: 2 Cylinders: 16709 Heads: 255 Sectors: 63 MB: 131069

None found.

No FATs found.

Partitions according to partition tables on second harddisk:

--PCyl N ID -----Rel -----Num ---MB --Start CHS- ---End CHS-- BS CHS
0 1 07 63398283417194474 0 1 1 24791*254 63 NB OK?

I am worried by the lack of FATs, and also by the CHS OK?.

So, could anyone recommend the best next step?

Also, did I need to install MaxBlast 3 in the first place? I did have
less than 137GB on the drive - will this make retrieving the data any
easier? Is my data totally beyond restoration?

Thanks for any help anyone can offer.

Chris.

 

[Svend Olaf Mikkelsen]

Hello,

(Please reply to the group, as my email is currently broken).

I am unable to read any files from my primary slave drive, and would
be very grateful for any advice from those more experienced.

My primary master hard drive was partitioned into two partitions using
Partition Magic some time ago.

My OS is win2000 SP4, installed in the primary partition on primary
master, and has worked fine for a long time.

The primary slave drive is a 200GB Maxtor. I have installed MaxBlast
3. I was not sure if I needed to do so, since although I understand
that Win2000 + SP4 should support above the 137GB limit, my BIOS
reports the drive as being 137GB. Anyway, this has also worked fine
for several months.

Yesterday I installed Windows XP into the second partition on my
primary master. This made win2000 unbootable. Ran the repair option
for win2000 from the win2000 CD. Repaired and booted fine. Primary
slave still working fine.

Today I attempted to boot the XP install. This is where it went
really wrong. I received a "Unable to boot Windows 2000" error. (Why
it was trying to boot win2000 I have no idea, boot.ini appeared fine).
In any case, this seems to have catastrophically affected the primary
slave (again, since this is a totally separate drive I have no idea
why it should have affected this).

In win2000 the drive appears, but attempts to open it from "My
Computer" give a 'Drive Not Formatted - Do you wish to format?'
message.

I want to retrieve the data on the drive as much as possible.
Needless to say, I have not selected to format the drive!

I have run the findpart utility (many thanks for this, Svend, if you
are reading):

C:\data\findpart>findpart 2

Findpart, version 4.43 - for Windows 95/98/ME/NT/2000/XP.
Copyright Svend Olaf Mikkelsen, 1999-2004.

OS: Windows 5.0.2195 Service Pack 4

Disk: 2 Cylinders: 16709 Heads: 255 Sectors: 63 MB: 131069

None found.

No FATs found.

Partitions according to partition tables on second harddisk:

--PCyl N ID -----Rel -----Num ---MB --Start CHS- ---End CHS-- BS CHS
0 1 07 63398283417194474 0 1 1 24791*254 63 NB OK?

I am worried by the lack of FATs, and also by the CHS OK?.

So, could anyone recommend the best next step?

Also, did I need to install MaxBlast 3 in the first place? I did have
less than 137GB on the drive - will this make retrieving the data any
easier? Is my data totally beyond restoration?

Thanks for any help anyone can offer.

Chris.

First the partition should be hidden, so it cannot be accidently
formatted. One way is to delete the entry in the partition tables, and
not enter any partitioning tools afterwards.

Next it should be obtained that the full disk size is shown by
Findpart.

If this was the 128 GB problem, and data were written to the Master
File Table area, it can be a difficult case, in which actual file
content must be found without use of file system structures.

If the disk is seen as full size, Findpart may see the backup boot
sector in the last sector of the used partition area, and different
Findpart FindNTFS searches can be run.

 

[Svend Olaf Mikkelsen]

Disk: 2 Cylinders: 16709 Heads: 255 Sectors: 63 MB: 131069

None found.

No FATs found.

I am worried by the lack of FATs, and also by the CHS OK?.

PS. Do not worry about the FAT. FAT is not expected in an NTFS
partition. The "?" indicates that the partition ends after reported
disk size.

 

[Svend Olaf Mikkelsen]

Hello,

Reply no. 3.

But of course it will be possible to just run recovery programs now,
which copies data to another disk, and get what can be found below 128
GB. There still is a chance that only the boot sector is damaged.

About the disk size:

It can be a Windows problem, or the disk can be set to 128 GB using
jumpers or the Set Max Address command. One way to begin is to do from
boot directly to a DOS floppy:

findpart ide fp-a.txt
findpart tables fp-b.txt

 

[Alexander Grigoriev]

Remember, if you want to install or repair Windows 2000 or XP on a partition

137 GB, you'll need to use a CD with the corresponding SP slipstreamed

(merged into the installation set).
You seem to use original CDs, this is why your partitions are screwed up.

 

[Arno Wagner]

Remember, if you want to install or repair Windows 2000 or XP on a partition
(merged into the installation set).
You seem to use original CDs, this is why your partitions are screwed up.

Sad but true. Another example for incredibly bad
software-engineering. They neither prepared nor tested
for it. You find out when your data is gone.

Arno

 

[Chris Bailiss]

Hi Svend

Thanks very much for your replies.

I have run the findpart commands as you suggested (from a DOS 6
bootdisk):


findpart ide

Findpart, version 4.42.
Copyright Svend Olaf Mikkelsen, 1999-2004.

IDE disks:

Primary Master Model: QUANTUM FIREBALLP AS60.0 Revision:
A1Y.1300
Disk: PM Cylinders: 7299 Heads: 255 Sectors: 63 MB: 57255
IDE CHS: 16383/16/63 CTM: 4047/16/255 IDE MB: 57259
User sectors: 117266688
Sector 0: OK Sector 1000: OK

Primary Slave Model: Maxtor 6Y200P0 Revision: YAR41BW0
Disk: PS Cylinders: 24792 Heads: 255 Sectors: 63 MB: 194474
IDE CHS: 16383/16/63 CTM: 16383/16/63 IDE MB: 194481
User sectors: 398297088
Sector 0: OK Sector 1000: OK

BIOS: 0x80: 57255 MB



findpart tables


Findpart, version 4.42.
Copyright Svend Olaf Mikkelsen, 1999-2004.

OS: DOS 6.22 Partition tables:

Disk: 1 Cylinders: 7299 Heads: 255 Sectors: 63 MB: 57255

-PCyl N ID -----Rel -----Num ---MB -Start CHS- --End CHS-- BS CHS
0 1*07 63117258372 57255 0 1 1 7298*254 63 OK OK


I am slightly reassured that the primary slave is reported as the
correct size (200GB). Does this mean my BIOS supports the full drive
size? (I am still a bit confused about this...)

After seeing this, does anyone have any suggestions on how best to
proceed?

Many thanks for all of your time with this.

Chris

 

[Chris Bailiss]

Alex,

Just to clarify, it was my primary slave (with no OS on) that is
causing the problem.

I had win2000 SP4 on my primary master which was and is working fine,
though had to run the repair option from the CD.

I checked that the OS still reported version as SP4 (which it did).

The problem occurred after I tried to boot into XP in the second
partition on Primary Master (and it gave a "Unable to boot win2000"
error (no typo, win2000, not XP - I am confused about that since
boot.ini appeared fine)).

Thanks,

Chris.

 

[Svend Olaf Mikkelsen]

Hi Svend

Thanks very much for your replies.

I have run the findpart commands as you suggested (from a DOS 6
bootdisk):


findpart ide

Findpart, version 4.42.
Copyright Svend Olaf Mikkelsen, 1999-2004.

IDE disks:

Primary Master Model: QUANTUM FIREBALLP AS60.0 Revision:
A1Y.1300
Disk: PM Cylinders: 7299 Heads: 255 Sectors: 63 MB: 57255
IDE CHS: 16383/16/63 CTM: 4047/16/255 IDE MB: 57259
User sectors: 117266688
Sector 0: OK Sector 1000: OK

Primary Slave Model: Maxtor 6Y200P0 Revision: YAR41BW0
Disk: PS Cylinders: 24792 Heads: 255 Sectors: 63 MB: 194474
IDE CHS: 16383/16/63 CTM: 16383/16/63 IDE MB: 194481
User sectors: 398297088
Sector 0: OK Sector 1000: OK

BIOS: 0x80: 57255 MB



findpart tables


Findpart, version 4.42.
Copyright Svend Olaf Mikkelsen, 1999-2004.

OS: DOS 6.22 Partition tables:

Disk: 1 Cylinders: 7299 Heads: 255 Sectors: 63 MB: 57255

-PCyl N ID -----Rel -----Num ---MB -Start CHS- --End CHS-- BS CHS
0 1*07 63117258372 57255 0 1 1 7298*254 63 OK OK


I am slightly reassured that the primary slave is reported as the
correct size (200GB). Does this mean my BIOS supports the full drive
size? (I am still a bit confused about this...)

After seeing this, does anyone have any suggestions on how best to
proceed?

Many thanks for all of your time with this.

Chris

No, it does not mean that the BIOS reports the disk as full size. The
BIOS did not report the disk. This can be as it should be, since the
disk can be set to "none" in BIOS, and Windows 2000/XP should still
see the disk.

The output shows that the disk itself reports the full disk size. The
size is not set using jumpers or the Set Max Address command.

Meaning that as far as I can see, the issue with Windows 2000
reporting the disk as 131069 MB is a Windows problem. Note that the
Windows 2000 Disk Management disk size reporting is not reliable. In
this matter the Findpart for Windows output is reliable, in the sense
that it shows the disk size that Windows can access.

I do not know which service pack that solves the 128 GB problem, but
the Findpart output showed Windows 5.0.2195 Service Pack 4.

It would be possible that some disk manager loaded by MBR sets the
disk size temporarily to 128 GB during boot, but it does not seem
likely, and it should show some message on the screen. Doing DOS
"fdisk /mbr" from a clean floppy boot would solve that problem if
present.

What you should obtain is that

findpart tables

shows the full disk size in Windows 2000.


In addition to examining the disk size issue, you can do in Windows:

findpart findntfs 2 0 1 1 summary fp-c.txt

So far, do not make any conclusions from that output file.

 

[Folkert Rienstra]

On 10 May 2004 11:52:26 -0700, (e-mail address removed) (Chris Bailiss) wrote: []

findpart ide []

Primary Slave Model: Maxtor 6Y200P0 Revision: YAR41BW0
Disk: PS

Cylinders: 24792

Where does this value spring from?

Heads: 255 Sectors: 63

MB: 194474

Apparently these are binary megabytes (and the result of the above CHS).
Why binary?

This one I can actually understand ...

CTM: 16383/16/63

.... but what does this mean?
I am guessing 'current translation something'.

IDE MB: 194481

.... and this? (Apparently the calculated result of 'user sectors', next).
(and again using binary megabytes)
(and it's slightly larger than that out of the blue 'MB: 194474')

Presumably the decimal presented value in Identify words 61,60

Sector 0: OK Sector 1000: OK

BIOS: 0x80: 57255 MB
[]


I am slightly reassured that the primary slave is reported as the
correct size (200GB). Does this mean my BIOS supports the full drive
size? (I am still a bit confused about this...)

After seeing this, does anyone have any suggestions on how best to
proceed?

Many thanks for all of your time with this.

Chris

No, it does not mean that the BIOS reports the disk as full size. The
BIOS did not report the disk. This can be as it should be, since the
disk can be set to "none" in BIOS, and Windows 2000/XP should still
see the disk.

The output shows that the disk itself reports the full disk size. The
size is not set using jumpers or the Set Max Address command.

[]

 

[Svend Olaf Mikkelsen]

Where does this value spring from?

Try to figure it out. Also as example (first) convince Phoenix/Award
not to report cylinders larger then 1023 (for another disk):

Info from interrupt 13h, ax = 4800h:
Buffer size: 30
Infoflag hex: 0002
Cylinders: 5005
Heads: 255
Sectors: 63
Total low: 80405325
Total high: 0
Bytes/sector: 512
Config hex: F000A820

... but what does this mean?
I am guessing 'current translation something'.

Current translation mode.

... and this? (Apparently the calculated result of 'user sectors', next).
(and again using binary megabytes)
(and it's slightly larger than that out of the blue 'MB: 194474')

With a 255 heads, 63 sectors translation only the lower number of MB
are used.

Presumably the decimal presented value in Identify words 61,60

I do not remember the words, but it is the size reported by the disk
using the usual get size procedure (not get native sectors), including
the procedure for disks larger than 128 GB.

 

[Folkert Rienstra]

Try to figure it out.

You better hadn't said that. When baiting, prepare to get bitten.

Also as example (first) convince Phoenix/Award
not to report cylinders larger then 1023 (for another disk):

Oh? Why should I make an ass out of myself?
The info on how to use Int13-AH=48h is quite clear.

Info from interrupt 13h, ax = 4800h:

offset 0:

Buffer size: 30

offset 2:

Infoflag hex: 00021

"bit 1 The geometry returned in bytes 4-15 shall be valid"
(A set bit indicates that the feature shall be available)

guess what: bit 1 is cleared.

offset 4:

Cylinders: 5005

offset 8:

Heads: 255

offset 12:

Sectors: 63
offset16:
Total low: 80,405,325
Total high: 0

"Number of sectors. This shall be 1 greater than the maximum sector number.
If this field is greater than 15,482,880 then word 2, bit 1 is cleared to 0."

guess what: bit 1 in 'infoflag' is indeed cleared.
The geometry returned in bytes 4-15 is therefor *invalid*.

Now, who needed to figure what out, again?
Any other ill-thought-through suppositions I can debunk for you?

Bytes/sector: 512
Config hex: F000A820


Current translation mode.

Current translation is not a 'mode', a 'mode' would be on or
off, enabled or disabled, one mode or another, CHS or LBA.
Current translation is just that, a geometry used in CHS translation (mode).
It is ignored in LBA translation (mode).

With a 255 heads, 63 sectors translation only the lower number of MB
are used.

That is a load of crap and I just proved it, above.

I do not remember the words, but it is the size reported by the disk
using the usual get size procedure (not get native sectors), including
the procedure for disks larger than 128 GB.

If not 'native' then what has this got to do with "Get Identification"?

 

[Svend Olaf Mikkelsen]

Current translation is not a 'mode', a 'mode' would be on or
off, enabled or disabled, one mode or another, CHS or LBA.
Current translation is just that, a geometry used in CHS translation (mode).
It is ignored in LBA translation (mode).

I guess the origin is a quote from the ATA 3 document. Anyway, people
who need this information will be able to get it.

 

[Chris Bailiss]

Hi Svend,

Thank you once again for your continuing help.

Ran findntfs as you suggested, summary as follows:

Directories: 281
Files: 1976
Trees: 3
Exe/dll files: 144
Exe/dll files signature: 138
Not referenced files: 9
Cluster KB: 4
MFT record used: None
MFT Offset MB: 0
Listed files MB: 18658

This is obviously only a fraction of the data.

Worrying that the tree is split into multiple parts.

I also ran the non-summary version. Interestingly, the list of files
returned was mostly a set of files I backed up to the drive during the
last session when it was working. Is it possible some of this data
overwrote a part of the file tables?

Given this, what might be the best way to proceed?

Regarding the Findpart tables output: I am presuming the ---MB=194474
value in the table is the size reported by the drive, and MB: 131069
is the size as the drive appears to Windows. Is this correct? If the
drive was set up correctly, should these sizes be the same?

Thanks again for any suggestions about how best to proceed.

Regards,

Chris.

 

[Chris Bailiss]

Hello,

Can I check my understanding of this is correct?

I should have done the following:

I should install an OS which supports the extended disk size (2000SP4
or XPSP1) on my primary master (60GB).

Once this is installed correctly, I can connect up the primary slave
(200GB), and it should support the full size.

When my BIOS reported the drive, it reported it as 137GB. Does this
mean I need ez-bios/equivalent, or not? (My BIOS is now set to the
'none' option for the primary slave).

Sorry for asking such basic questions, I have found some of the
documentation on the net a bit confusing around the BIOS issue.

Thanks,

Chris

 

[Svend Olaf Mikkelsen]

Hi Svend,

Thank you once again for your continuing help.

Ran findntfs as you suggested, summary as follows:

Directories: 281
Files: 1976
Trees: 3
Exe/dll files: 144
Exe/dll files signature: 138
Not referenced files: 9
Cluster KB: 4
MFT record used: None
MFT Offset MB: 0
Listed files MB: 18658

This is obviously only a fraction of the data.

Worrying that the tree is split into multiple parts.

I also ran the non-summary version. Interestingly, the list of files
returned was mostly a set of files I backed up to the drive during the
last session when it was working. Is it possible some of this data
overwrote a part of the file tables?

Possible, well maybe even likely, yes, but there is no reason to
assume anything, just examine.

Given this, what might be the best way to proceed?

Get the disk seen as full size in Windows. Must be possible. You can
try other recovery programs, since FindNTFS will not search the entire
visible disk space for file records. When the MFT file record was not
found so far, parts of the MFT can be in other parts of the disk.
Well.

If the backup boot sector in the last sector of the partition can be
accessed, more search information will be available.

Theoretically one could search in DOS, but still, it must be possible
to make Windows see the entire disk.

Regarding the Findpart tables output: I am presuming the ---MB=194474
value in the table is the size reported by the drive, and MB: 131069
is the size as the drive appears to Windows. Is this correct? If the
drive was set up correctly, should these sizes be the same?

Yes. Yes.

One search which will take some time is (output for your own use):

findntfs findfile 2 filenames fp-d.txt

This will show which file records are present, but it cannot be used
directly for file copying.

 

[Alexander Grigoriev]

IIRC, MS kludgebase article says that to enable BIG ATA, Windows also checks
if the BIOS supports BigATA. But I don't know if it is also true for disks
"hidden" from BIOS.

 

[Andy]

Hello,

Can I check my understanding of this is correct?

I should have done the following:

I should install an OS which supports the extended disk size (2000SP4
or XPSP1) on my primary master (60GB).

Once this is installed correctly, I can connect up the primary slave
(200GB), and it should support the full size.

When my BIOS reported the drive, it reported it as 137GB. Does this
mean I need ez-bios/equivalent, or not? (My BIOS is now set to the
'none' option for the primary slave).

Not. I used to run two 160GB drives on a socket 370 motherboard with a
BIOS that recognized only 137GB. The master drive contained several
small logical drives at the beginning of the drive for different OS
installations followed by a 128GB logical drive for data. The slave
drive had a single partition for data. Stuff to observe to prevent
things from going awry include:
1. When installing Windows 2000 (even when slipstreamed with SP3 or
SP4) the installation program will see only 137GB of the drive
regardless of whether the BIOS reports only 137GB or the entire drive.
2. During the installation process when the OS boots up and says that
it needs to check and fix a partition, do not let it do it, lest it
scrambles files in that partition. Typically this applies to a
partition that spans the 137GB boundary on the hard drive that the OS
is being installed on. Chkdsk the partition after the installation is
complete.
3. If you dual boot Windows 2000 and XP, Windows XP won't boot if the
versions of ntldr and ntdetect.com in C:\ are not from Windows XP.
This happens if you install Windows 2000 after XP, or if you repair
Windows 2000. Copy the versions from the Windows XP CD to C:\.

 

[Mark M]

You better hadn't said that. When baiting, prepare to get
bitten.

Sounds to me like you couldn't figure it out Folkert.

So Svend has had to walk you through it.

 

[Mark M]

Oh? Why should I make an ass out of myself?
The info on how to use Int13-AH=48h is quite clear.

It's quite clear to some people that you are an ass.
There is no need for you to make an effort to prove it.