lost partion table help with findpart, please!!

[Thomas Hartmann]

Hello,

i have problems with my harddisk. some weeks ago i placed a new hdd in
my system: PIII 350 MHz, Win98, fat32,
for no reason one day i shut down the system as usual and the next i
switched on and couldn´t boot.
Well i thought the boot files would be concerned and executed a "fdisk
/mbr" and "sys c:", after that my system
was able to boot again but...no gui.
Now i was concerned and had a closer look at it and realized that my
partition table was the cause.


Originally i had one primary partition with about 3.8 GB and the rest
was a logical drive in an extended partition.
i searched the web for tools for a repair trial and found findpart.
Thanks to Svend Olaf Mikkelsen i got an output from the tool but i am
not sure about the meaning.
Is there anybody able to help to interprete this:


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

OS: Windows 4.10.2222

Disk: 2 Cylinders: 9702 Heads: 128 Sectors: 63 MB: 38202

-PCyl N ID -----Rel -----Num ---MB -Start CHS- --End CHS-- BS CHS
0 - 0B 63 7055937 3445 0 1 1 874 127 63 B OK
8192 1*0B 63 7055937 3445 8192 1 1 9066 127 63 OK OK

-----FAT CHS -Size Cl --Root -Good -Rep. Maybe --Bad YYMMDD DataMB
0 1 33 16363 4# 2#16330 0 8 25 011224 4146
8192 1 33 16363 4# 2#16330 0 8 25 011224 4146

Partitions according to partition tables on second harddisk:

-PCyl N ID -----Rel -----Num ---MB -Start CHS- --End CHS-- BS CHS
0 1*0B 63 7055937 3445 0 1 1 874 127 63 OK OK

by the way: it is a samsung drive, model SV0411N
the bios information: Cylinders 1024, Heads 128, Sectors 63,
CHS-Capacity 4227, LBA-Capacity 40060

 

[Svend Olaf Mikkelsen]

Hello,

i have problems with my harddisk. some weeks ago i placed a new hdd in
my system: PIII 350 MHz, Win98, fat32,
for no reason one day i shut down the system as usual and the next i
switched on and couldn´t boot.
Well i thought the boot files would be concerned and executed a "fdisk
/mbr" and "sys c:", after that my system
was able to boot again but...no gui.
Now i was concerned and had a closer look at it and realized that my
partition table was the cause.


Originally i had one primary partition with about 3.8 GB and the rest
was a logical drive in an extended partition.
i searched the web for tools for a repair trial and found findpart.
Thanks to Svend Olaf Mikkelsen i got an output from the tool but i am
not sure about the meaning.
Is there anybody able to help to interprete this:


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

OS: Windows 4.10.2222

Disk: 2 Cylinders: 9702 Heads: 128 Sectors: 63 MB: 38202

-PCyl N ID -----Rel -----Num ---MB -Start CHS- --End CHS-- BS CHS
0 - 0B 63 7055937 3445 0 1 1 874 127 63 B OK
8192 1*0B 63 7055937 3445 8192 1 1 9066 127 63 OK OK

-----FAT CHS -Size Cl --Root -Good -Rep. Maybe --Bad YYMMDD DataMB
0 1 33 16363 4# 2#16330 0 8 25 011224 4146
8192 1 33 16363 4# 2#16330 0 8 25 011224 4146

Partitions according to partition tables on second harddisk:

-PCyl N ID -----Rel -----Num ---MB -Start CHS- --End CHS-- BS CHS
0 1*0B 63 7055937 3445 0 1 1 874 127 63 OK OK

by the way: it is a samsung drive, model SV0411N
the bios information: Cylinders 1024, Heads 128, Sectors 63,
CHS-Capacity 4227, LBA-Capacity 40060

It is the 32 GB problem. I see that on the repeated finding at
cylinder 8192.

For some reason the FAT findings were not confirmed in the boot
sector. I cannot explain why without more examination.

If important data are lost, you must stop writing to this disk, and
stop booting to Windows.

After that, the disk can be examined as disk number 2 in a known good
environment without 32 GB problems.

It should be avoided that Scandisk is run on the current visible
partition.

 

[Folkert Rienstra]

That is a bit odd. That is info 'constructed' from the MBR.
Is that supposed to be?
Then the problem appears to be in the number of heads.

It is the 32 GB problem.

What is *the* 32GB problem?

I see that on the repeated finding at cylinder 8192.

So it is not the 32GB (foldback, i.e. modulo 32GB) problem.
More like a 32GB fold-forward problem.

For some reason the FAT findings were not confirmed in the boot
sector.

What do you mean with 'confirmed' and what with 'bootsector'?
Presumably you mean master boot record?

 

[Svend Olaf Mikkelsen]

What is *the* 32GB problem?

Well, it is a discovery of mine, which I hesitate to explain in
details each time, since it is really not my job. It is Microsofts job
to get these problems fixed in Security Updates, and described in
details in Knowledge Base articles.

So it is not the 32GB (foldback, i.e. modulo 32GB) problem.
More like a 32GB fold-forward problem.

It is the modulo problem. I did not calculate yet if the case matches
one of the modulus checked with my GB32 tool, but I guess so. Findpart
read the disk using operating system calls.

What do you mean with 'confirmed' and what with 'bootsector'?
Presumably you mean master boot record?

The line with FAT findings includes the cluster size and the root
cluster number. If the findings by search are not the same as in the
partition boot sector (FAT size and cluster size fields), the FAT
finding is marked "#".

The distance is 8192 * 128 * 63 sectors. One of the distances checked
with the GB32 tool is 65536 * 16 * 63 sectors. It is the same.

 

[Thomas Hartmann]

Hello Svend Olaf,

thank you for your immediate response.

as you recommended i took the drive into another system and booted
from floppy and examined it with the dos version of findpart:



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

OS: DOS 7.10

Disk: 2 Cylinders: 9702 Heads: 128 Sectors: 63 MB: 38202

-PCyl N ID -----Rel -----Num ---MB -Start CHS- --End CHS-- BS CHS
0 - 0B 63 7055937 3445 0 1 1 874 127 63 B OK

-----FAT CHS -Size Cl --Root -Good -Rep. Maybe --Bad YYMMDD DataMB
0 1 33 16363 4# 2#16330 0 8 25 011224 4146

Partitions according to partition tables on second harddisk:

-PCyl N ID -----Rel -----Num ---MB -Start CHS- --End CHS-- BS CHS
0 1*0B 63 7055937 3445 0 1 1 874 127 63 OK OK


the bios drive recognition changed to:
Cylinders 1024, Heads 255, Sectors 63, CHS-Capacity 8422, LBA-Capacity
40060

 

[Folkert Rienstra]

Well, it is a discovery of mine, which I hesitate to explain in
details each time, since it is really not my job. It is Microsofts job
to get these problems fixed in Security Updates, and described in
details in Knowledge Base articles.


It is the modulo problem. I did not calculate yet if the case matches
one of the modulus checked with my GB32 tool, but I guess so. Findpart
read the disk using operating system calls.

On an earlier case you wrote:
"Note that from the description the 32 GB problem can be present on
your sons computer too. It is only seen if data are more than 32 GB into
the disk, in which case it will be written 32 GB lower than it should be."

The " It is only seen... " is not entirely true then. Or rather false.
You can see it immediately after formatting when reading the area over
8GB actually reads the area starting from zero again and the FATS and
bootsectors and directories residing there are read again as if they were
in the over 8GB area, as is the case here.
The fact that they are completely the same is the dead giveaway.

Simple really.
I can't understand why you are so hesitant to explain what
the symtoms are and why it is that you see what you see.
(is a Fata Morgana, as it isn't really there)

The line with FAT findings includes the cluster size and the root
cluster number. If the findings by search are not the same as in the
partition boot sector (FAT size and cluster size fields), the FAT
finding is marked "#".

Sorry, that one was explained already in the partiton notes.
I forgot that you use several ways of saying 'Nota Bene'.

 

[Svend Olaf Mikkelsen]

On an earlier case you wrote:
"Note that from the description the 32 GB problem can be present on
your sons computer too. It is only seen if data are more than 32 GB into
the disk, in which case it will be written 32 GB lower than it should be."

The " It is only seen... " is not entirely true then. Or rather false.
You can see it immediately after formatting when reading the area over
8GB actually reads the area starting from zero again and the FATS and
bootsectors and directories residing there are read again as if they were
in the over 8GB area, as is the case here.
The fact that they are completely the same is the dead giveaway.

It is 32 GB, but I know you know. Yes the problem can be detected as
soon as something unique is written to the disk. What I meant by
saying "seen" is that the son would not see the problem until more
than 32 GB of data were on the disk. Please understand.

Simple really.
I can't understand why you are so hesitant to explain what
the symtoms are and why it is that you see what you see.
(is a Fata Morgana, as it isn't really there)

I will do what I can in the time available.

 

[Svend Olaf Mikkelsen]

Hello Svend Olaf,

thank you for your immediate response.

as you recommended i took the drive into another system and booted
from floppy and examined it with the dos version of findpart:

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

OS: DOS 7.10

Disk: 2 Cylinders: 9702 Heads: 128 Sectors: 63 MB: 38202

Partitions according to partition tables on second harddisk:

-PCyl N ID -----Rel -----Num ---MB -Start CHS- --End CHS-- BS CHS
0 1*0B 63 7055937 3445 0 1 1 874 127 63 OK OK

Use a DOS boot floppy with as much free space as possible. Can be made
in Windows 98 using the command:

sys a:

on a newly formatted floppy. A DOS Startup Disk made in Windows XP can
also be used.

Then you can do with findpart.exe on the floppy:

findpart finddir 2 0 5000 fp-a.txt

and mail me the file fp-a.txt.


If you have a Windows operating system on disk 1, you should avoid
booting that, or the current partition should be made hidden and it
should be examined that no disk size related problems are present in
Windows. For Windows 95/98/ME 32 GB problems the GB32 tool can be
used.

When you have a safe environment, you also can try other recovery
programs that copy files to another disk.

 

[Folkert Rienstra]

That is a bit odd. That is info 'constructed' from the MBR.
Is that supposed to be?
Then the problem appears to be in the number of heads.

What, no takers?

[snip]

 

[Folkert Rienstra]

Hello Svend Olaf,

thank you for your immediate response.

as you recommended i took the drive into another system and booted
from floppy and examined it with the dos version of findpart:

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

OS: DOS 7.10

Disk: 2 Cylinders: 9702 Heads: 128 Sectors: 63 MB: 38202

-PCyl N ID -----Rel -----Num ---MB -Start CHS- --End CHS-- BS CHS
0 - 0B 63 7055937 3445 0 1 1 874 127 63 B OK

-----FAT CHS -Size Cl --Root -Good -Rep. Maybe --Bad YYMMDD DataMB
0 1 33 16363 4# 2#16330 0 8 25 011224 4146

Partitions according to partition tables on second harddisk:

-PCyl N ID -----Rel -----Num ---MB -Start CHS- --End CHS-- BS CHS
0 1*0B 63 7055937 3445 0 1 1 874 127 63 OK OK


the bios drive recognition changed to:
Cylinders 1024, Heads 255, Sectors 63, CHS-Capacity 8422, LBA-Capacity 40060

It might be interesting to see the DOS output taken from that system with the odd BIOS capacity notices.

 

[Folkert Rienstra]

It is 32 GB, but I know you know.

Oops, 32GB was meant of course, not 8GB.

Yes the problem can be detected as soon as something unique is written to
the disk.
What I meant by saying "seen" is that the son would not see the problem

until more than 32 GB of data were on the disk.

Actually, with the modulo 32GB problem, there cannot be more than 32GB
on the disk. Anything more takes the place of (i.e. overwrites) older data.
That is why it is the modulo 32GB problem.

So the correct way to explain would be that the problem is likely going
to be noticed as soon as the disk is written to to a destination over the
32GB border. With some file systems that may be even sooner than later
(or is that later than sooner?), depending on how the file system allocates
available free space.

Please understand.

I think I do now. There is more than one way to notice the problem
and that is what caught me off, I hadn't considered the first one.
I took your comment
"I see that on the repeated finding at cylinder 8192"
for real where you just meant to say that it was a fake
copy and actually a mirror image of the one at cylinder 0.

One way to notice it very soon is by running Findpart immediately after par-
titioning and formatting and noticing the fake FAT and bootsector entries.
Unfortunately there isn't anything to prompt you to do that so nobody ever does.
The other is when it is too late and your data is trashed while it may say that
there is more than, or about 32GB or so of space used by files. If you are lucky.
If you're not, the MBR is overwritten too and that info will not be available.

 

[Svend Olaf Mikkelsen]

Hello Svend Olaf,

thank you for your immediate response.

as you recommended i took the drive into another system and booted
from floppy and examined it with the dos version of findpart:

Reply no. 2.

From mail I have in part:

Finddir, version FP 4.42.
Copyright Svend Olaf Mikkelsen, 2004.

Searches for subdirectories and calculates cluster two
location. 'Cluster' is cluster number or cluster 2 CHS.
'KB' is cluster KB. May also say something about FAT location.

OS: DOS 7.10

Disk: 2 Cylinders: 9702 Heads: 128 Sectors: 63 MB: 38202

Start cylinder: 0 End cylinder: 5000

--------- CHS ----- LBA -- Cluster (2) ----- LBA -KB YYMMDD
0 0 1 0 searched
4 8 62 32821 possible root
9 31 61 74589 5223 040522
9 34 8 74725 4 8 62 32821 4 040522
9 38 4 74973 4 8 62 32821 4 040522
9 56 22 76125 4 8 62 32821 4 040522
9 86 12 78005 4 8 62 32821 4 040520

1084 91 1 8747109 4 8 62 32821 4 040701
1085 63 45 8753453 4 8 62 32821 4 040701
1086 59 33 8761253 4 8 62 32821 4 040531
1093 25 39 8815565 4 8 62 32821 4 040701
1095 67 33 8834333 4 8 62 32821 4 040701
1102 119 45 8894069 4 8 62 32821 4 040629

2020 19 9 16290485 4 8 62 32821 4 030228
2020 126 52 16297269 4 8 62 32821 4 031024

2076 109 19 16747749 4 8 62 32821 4 020228
2085 72 35 16818010 possible root
2521 29 56 20331226 109790 040519

5000 0 1 40320000 searched

------FAT CHS ------LBA Confidence Distance Type Sig
0 1 33 95 8028 32 OK
0 110 50 6979 12 6884 32 NB
2 5 16 16458 8040 9479 32 OK

2081 108 33 16788020 858 199335 32 OK
2083 90 34 16803015 858 14995 32 OK

A FAT for a 30004 MB FAT32 partition (assuming 16 KB cluster size) was
located at a nonstandard location at cylinder 2081. The partition is
about 858/14995 filled with data. Can be a previous partition.

As far as I can see there is no trace from a partition directly
following the current partition in the searched area.

For the partition in the beginning of the disk, the second FAT copy is
the best, but it is not known if it is perfect.

I would say that for the two partitions located, the method will be to
copy data to another disk, if possible using the Findpart for Windows
commands:

findpart chsdir 2 0 1 33 16363 4 2 copy fat2

findpart chsdir 2 2081 108 33 14995 16 2 copy

The commands are run in the directory to which the files should be
copied. Will only work with some partition damage types.

If more data are lost, more information is needed regarding what is
missing.

Still, Scandisk or chkdsk should not be run on the disk.

 

[Mike Tomlinson]

Actually, with the modulo 32GB problem, there cannot be more than 32GB
on the disk. Anything more takes the place of (i.e. overwrites) older data.
That is why it is the modulo 32GB problem.

Pardon me for jumping in, but just so I understand: is the "modulo 32GB
problem" you're discussing a BIOS problem or a Windows problem?

 

[Svend Olaf Mikkelsen]

Actually, with the modulo 32GB problem, there cannot be more than 32GB
on the disk. Anything more takes the place of (i.e. overwrites) older data.
That is why it is the modulo 32GB problem.
Yes.

So the correct way to explain would be that the problem is likely going
to be noticed as soon as the disk is written to to a destination over the
32GB border. With some file systems that may be even sooner than later
(or is that later than sooner?), depending on how the file system allocates
available free space.
Yes.

I think I do now. There is more than one way to notice the problem
and that is what caught me off, I hadn't considered the first one.
I took your comment
"I see that on the repeated finding at cylinder 8192"
for real where you just meant to say that it was a fake
copy and actually a mirror image of the one at cylinder 0.

One way to notice it very soon is by running Findpart immediately after par-
titioning and formatting and noticing the fake FAT and bootsector entries.
Unfortunately there isn't anything to prompt you to do that so nobody ever does.
The other is when it is too late and your data is trashed while it may say that
there is more than, or about 32GB or so of space used by files. If you are lucky.
If you're not, the MBR is overwritten too and that info will not be available.

It is only in some cases a repeated finding will be seen in the
Findpart output, since only standard partition locations are searched.
It will depend on the modulus value, and the disk geometry.

The GB32 program should be used to detect the problem.

 

[Folkert Rienstra]

[snip]
It is only in some cases a repeated finding will be seen in the
Findpart output, since only standard partition locations are searched.

Yes, but within a cylinder, right?

It will depend on the modulus value, and the disk geometry.

For your GB32 program maybe, but not Findpart.
If the modulo problem (whatever size it is at) occurs it occurs at
a cylinder or head change and the search continues from LBA 0,
nomatter what disk geometry.

The GB32 program should be used to detect the problem.

But that one *is* dependent on the modulus value, and the disk geometry.
And if my suspicion is right (see other post) you should use the sector
count value in the MBR in your calculation for distance, although a sector
count other than 63 is probably very rare.

 

[Folkert Rienstra]

Pardon me for jumping in, but just so I understand: is the "modulo 32GB
problem" you're discussing a BIOS problem or a Windows problem?

I think that we are not quite sure on that.

It is likely a CHS problem but CHS only extends to 8GB so I
think they internally use LBA->'pseudo CHS'->LBA translation.
Notice that with 63 sectors you don't get a nice binary bit transition where
a shortage of bits in a register leads to a spontaneous modulo xyz problem.

If it is a CHS problem then it likely is a modulo (x cylinder * y heads)
where x*y = 1048576 (FFFFFh) problem, not a precise neat modulo 32GiB
problem. And hey presto, now we have a carry on to next bit transition.
Sounds like they use a 20-bit register somehow.

And, as you may have noticed the Bios of the system it was found on is acting
strange too in reporting the CHS capacity.