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

[Chris Bailiss]

In you initial message you stated that the slave drive was fine after
you repaired the Windows 2000 installation. Did you run chkdsk to
determine this?

I have just read the documentation, and found that chkdsk runs in read
only mode by default.

So, ran it:

chkdsk f:
The type of the file system is RAW.
CHKDSK is not available for RAW drives.

Any ideas?

Thanks again,

Chris.

 

[Folkert Rienstra]

Several people have said this today. All very useful.

One question I am still working through:

Does LBA use the BIOS/IDE?

Sorry, that question makes no sense.

 

[Chris Bailiss]

Sorry, that question makes no sense.

Having read that back, fair point.

Rephrased:

I have read that Windows can access beyond 128/137GB even on a
computer without 48-bit LBA support, and that the limitation only
applies to DOS access to the drive. So, LBA seems to bypass the DOS
(and presumably hence the standard BIOS) access to the drive. Is this
true?

Hope that makes more sense.

Chris

 

[Chris Bailiss]

Does LBA use the BIOS/IDE?

Answered my own question.

Windows does bypass the BIOS. See:
http://www.pcguide.com/ref/hdd/bios/biosDirect-c.html

 

[Svend Olaf Mikkelsen]

Having read that back, fair point.

Rephrased:

I have read that Windows can access beyond 128/137GB even on a
computer without 48-bit LBA support, and that the limitation only
applies to DOS access to the drive. So, LBA seems to bypass the DOS
(and presumably hence the standard BIOS) access to the drive. Is this
true?

Hope that makes more sense.

Chris

LBA (logical block address) is just a word for the sector numbering
used: from 0 (the MBR - the first sector of the disk) to the number of
sectors on the disk minus 1. A sector is 512 bytes.

The BIOS does in your case not support LBA numbers larger than 2^28
minus 1.

Windows 2000 does not use the BIOS for disk access, except during
boot. In Windows, drivers that support more than 128 GB are needed,
and the access to areas after 128 GB may have to be enabled in Windows
settings.

 

[Folkert Rienstra]

Answered my own question.

That is doubtful.

 

[Folkert Rienstra]

Having read that back, fair point.

Rephrased:

I have read that Windows can access beyond 128/137GB even on a
computer without 48-bit LBA support,

Yes, Windows uses drivers, not the BIOS.

and that the limitation only applies to DOS access to the drive.

Yes, DOS uses the BIOS.

So, LBA seems to bypass the DOS (and presumably,
hence the standard BIOS) access to the drive.
Is this true?

Nope. BIOS (DOS) and drivers (Windows) both use LBA.
Drivers, like the BIOS, needed upgrading when 48-bit LBA-addressing
came along.

 

[Svend Olaf Mikkelsen]

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

OS: Windows 5.0.2195 Service Pack 4

Disk: 2 Cylinders: 24792 Heads: 255 Sectors: 63 MB: 194474

CHS 0/1/1 LBA: 63

Directories: 281
Files: 1976
Trees: 3
Exe/dll files: 144
Exe/dll files signature: 139
Not referenced files: 9
Cluster KB: 4
MFT cluster no: 4
MFT size: 184010752
MFT cluster bytes: 4096
Listed files MB: 18658

For file recovery, the main question now is if Findpart FindNTFS did
locate all file records, of if more file records are present. I cannot
say exactly what the possibilities of that are, but as mentioned this
search, which will take some time, will show the file records present
on the disk:

findpart findfile 2 filenames fp-d.txt

The output file is for your own use. Another search is:


findpart findntfs 2 0 1 1 alt backupboot 398283417 summary fp-e.txt

For files without file records, the file content must be located
without file system structure usage.

It confuses me that the output does not say that the mirror MFT file
record was used, while in the first output no MFT file record was
found.

Ideally the partition should be made hidden, but you can remove the
drive letter assignment, to protect it from accidently access.

 

[Svend Olaf Mikkelsen]

You will remember in my original post that FindPart reported my OS as
2000 SP4. This is correct, as in Windows itself reports SP4, however,
the Windows repair overwrites new files with older versions. The
windows Atapi driver, Atapi.sys, located at:
WinNt\System32\drivers\Atapi.sys
is one of the files that is overwritten by a pre-SP3 version.

Repaired version: 5.0.2195.1207
SP4 version: 5.0.2195.6699

(NB: File versions are discussed in the MS Knowledge Base:
48-Bit LBA Support for ATAPI Disk Drives in Windows 2000 - Q305098
http://support.microsoft.com/default.aspx?scid=kb;EN-US;305098)

Hence, I have re-applied SP4, since it will happily install over
itself.

So far I have these observations:


For ATA disks, Windows 2000 will "and" sector numbers with FFFFFFFh
(2^28 - 1) before performing a read or write command, if these three
conditions are not met:

1. Disk driver version support disks larger than 128 GB.

2. Registry key
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\atapi\Parameters
contains the value "EnableBigLba"=dword:00000001

3. The disk is larger than 128 GB.

Windows 2000 does not check that partitions are within the disk size
reported by the operating system.

Windows 2000 puts the Master File Table in the beginning of an NTFS
partition, but if the MFT has grown, parts of the MFT can be elsewhere
in the partition.



It could be added that Windows 2000 may not directly "and" the sector
number, but just use the lowest 28 bits when sending the commands, and
send the commands supporting 28 bits, if the disk does not support the
48 bit commands.

One example is that it is possible to write to the MBR of a 40 GB disk
by sending a Win32 write command to a sector 148 GB into the 40 GB
disk.

 

[Svend Olaf Mikkelsen]

You will remember in my original post that FindPart reported my OS as
2000 SP4. This is correct, as in Windows itself reports SP4, however,
the Windows repair overwrites new files with older versions. The
windows Atapi driver, Atapi.sys, located at:
WinNt\System32\drivers\Atapi.sys
is one of the files that is overwritten by a pre-SP3 version.

Repaired version: 5.0.2195.1207
SP4 version: 5.0.2195.6699

(NB: File versions are discussed in the MS Knowledge Base:
48-Bit LBA Support for ATAPI Disk Drives in Windows 2000 - Q305098
http://support.microsoft.com/default.aspx?scid=kb;EN-US;305098)

Hence, I have re-applied SP4, since it will happily install over
itself.

So far I have these observations:


For ATA disks, Windows 2000 will "and" sector numbers with FFFFFFFh
(2^28 - 1) before performing a read or write command, if these three
conditions are not met:

1. Disk driver version support disks larger than 128 GB.

2. Registry key
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\atapi\Parameters
contains the value "EnableBigLba"=dword:00000001

3. The disk is larger than 128 GB.

Windows 2000 does not check that partitions are within the disk size
reported by the operating system.

Windows 2000 puts the Master File Table in the beginning of an NTFS
partition, but if the MFT has grown, parts of the MFT can be elsewhere
in the partition.



It could be added that Windows 2000 may not directly "and" the sector
number, but just use the lowest 28 bits when sending the commands, and
send the commands supporting 28 bits, if the disk does not support the
48 bit commands.

One example is that it is possible to write to the MBR of a 40 GB disk
by sending a Win32 write command to a sector 128 GB into the 40 GB
disk.

 

[Andy]

I have just read the documentation, and found that chkdsk runs in read
only mode by default.

So, ran it:

chkdsk f:
The type of the file system is RAW.
CHKDSK is not available for RAW drives.

Any ideas?

Actually I was only hinting that had you run chkdsk on the big drive
after repairing Windows 2000, it would have told you that the file
system was bad, when in fact the problem was that Windows 2000 was no
longer able to access past the 137GB boundary on the large drive. So
when you copied some files to the drive, it messed up the file system.

 

[Folkert Rienstra]

So far I have these observations:

For ATA disks, Windows 2000 will "AND" sector numbers with FFFFFFFh
(2^28 - 1) before performing a read or write command, if these three
conditions are *not* met:

1. Disk driver version support disks larger than 128 GB.

2. Registry key
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\atapi\Parameters
contains the value "EnableBigLba"=dword:00000001

3. The disk is larger than 128 GB.

That appears doubtful. Presumably you mean 'one of these three'.
And if it does that, that is criminally stupid. Someone should be shot for that.
It also takes several false decisions to arrive at that point.

Windows 2000 does not check that partitions are within the disk size
reported by the operating system.

A minor problem, if a problem at all. But accepting a few of this type
of minor problems may have lead to the big problem as described above.

Windows 2000 puts the Master File Table in the beginning of an NTFS
partition, but if the MFT has grown, parts of the MFT can be elsewhere
in the partition.


It could be added that Windows 2000 may not directly "AND" the sector
number, but just use the lowest 28 bits when sending the commands, and
send the commands supporting 28 bits, if the disk does not support the
48 bit commands.

That's just the same.

One example is that it is possible to write to the MBR of a 40 GB disk
by sending a Win32 write command to a sector 128 GB into the 40 GB disk.

The person who programmed that should be summarily executed.

 

[Folkert Rienstra]

Actually I was only hinting that had you run chkdsk on the big drive
after repairing Windows 2000, it would have told you that the file
system was bad, when in fact the problem was that Windows 2000 was
no longer able to access past the 137GB boundary on the large drive.

So when you copied some files to the drive, it messed up the file system.

Maybe so, but the alternative: repair, would also have messed it up. And if
it was already messed up, you cannot mess it up other than mess it up more.