Hello,

First off, OS, = Win 98 SE, Award Bios, WDC1600BB 160GB in 3
partitions, 4GB primary the rest extended with 2 logical drives, D &
E: of 40 & 116 GB. Was using the DLG overlay

I have a 160 MB WDC1600BB which I was using with no problem till about
a month ago. What I suspect happened is that I hit the 137 barrier and
started getting corruption with high ascii characters and eventually
no boot. Quite a bit of corruption on the C: & E: drives, but got most
of my data back and reinstalled the OS and the DDA, which had
disappeared. Also replaced cables and cut back bus speed to 133.
Everything fine until yesterday, when I tried to burn a CD and could
only see high ascii where my D: drive was(maybe that 137 GB
again...had just copied 2 large image files). E: was accessible
Rebooted and now can only see the 4GB primary partition. BOTH the
extended and logical partitions are visible in Partition Magic as
"unallocated" Oh, and the DDA has gone again, and DLG won't let me
reinstall it! the options are blanked out except for "make a boot
diskette" and "update MBR". BIOS reports the disk as 33821 GB. The
data is not critical, but I'd like to get it back if I can.Thanks to
everyone, this is a great group! Here's Findpart(Thanks Svend):


Findpart, version 4.37 - for Windows 95/98/ME/NT/2000/XP.
Copyright Svend Olaf Mikkelsen, 2003.

Searches for partitions type 01, 04, 06, 07, 0B, 0C, 0E, 82, 83,
plus Fdisk F6 and Lilo sectors. Information based on bootsectors
is marked B. If the disk is larger than supported by BIOS, the
supported part of the disk is examined. Disks are numbered from 1.

OS: Windows 4.10

Disk: 1 Cylinders: 4111 Heads: 255 Sectors: 63 MB: 32248

-PCyl N ID -----Rel -----Num ---MB -Start CHS- --End CHS-- BS CHS
0 - 0B 63 8177022 3992 0 1 1 508 254 63 B OK
4032 1 0B 63247802562120997 4032 1 119456 254 63 NB OK?

-----FAT CHS -Size Cl --Root -Good -Rep. Maybe --Bad YYMMDD DataMB
0 1 33 7970 4 2 7970 0 0 0 030910 1381

Partitions according to partition tables on first harddisk:

-PCyl N ID -----Rel -----Num ---MB -Start CHS- --End CHS-- BS CHS
0 1*0B 63 8177022 3992 0 1 1 508 254 63 OK OK
0 2 0F 8177085304367490148616 509 0 119454 254 63 OK?

No signature CHS: 509 0 1

On Sun, 19 Oct 2003 14:07:16 GMT, Joe <barakaSpamlesS@hemscott.net>
wrote:

as I am sure it supported large disks before. Also here's the
Partinfo(which also mentions geometry errors on startup, due I
suppose, to the overlay):

================================================== ================================================== =======
Disk Geometry Information for Disk 1: 4111 Cylinders, 255 Heads,
63 Sectors/Track
Warning: Logical drive chain points to sector without partition table.
System PartSect # Boot BCyl Head Sect FS ECyl Head
Sect StartSect NumSects
================================================== ================================================== =======
MAX1 0 0 80 0 1 1 0B 508 254
63 63 8,177,022
0 1 00 509 0 1 0F 1022 254
63 8,177,085 304,367,490
Info: Begin C,H,S values were large drive placeholders.
Info: End C,H,S values were large drive placeholders.
Actual values are:
0 1 00 509 0 1 0F 19454 254 63 8177085
304367490
Error #109: Partition ends after end of disk.
ucEndCylinder (19454) must be less than 4111.

================================================== ================================================== =======
Partition Information for Disk 1: 32,247.7 Megabytes
Volume PartType Status Size MB PartSect #
StartSect TotalSects
================================================== ================================================== =======
C:MAX1 FAT32 Pri,Boot 3,992.7 0 0
63 8,177,022
ExtendedX Pri 148,616.9 0 1
8,177,085 304,367,490
EPBR Log 0.0 None --
8,177,085 63
Unallocated Log 28,254.9 None --
8,177,148 57,866,067
Unallocated Log 120,362.0 None --
66,043,215 246,501,360

================================================== ================================================== =======
Boot Record for drive C: (Drive: 1, Starting sector: 63, Type:
FAT32)
================================================== ================================================== =======
1. Jump: EB 58 90
2. OEM Name: MSWIN4.1
3. Bytes per Sector: 512
4. Sectors per Cluster: 8
5. Reserved Sectors: 32
6. Number of FAT's: 2
7. Reserved: 0x0000
8. Reserved: 0x0000
9. Media Descriptor: 0xF8
10. Sectors per FAT: 0
11. Sectors per Track: 63 (0x3F)
12. Number of Heads: 255 (0xFF)
13. Hidden Sectors: 63 (0x3F)
14. Big Total Sectors: 8177022 (0x7CC57E)
15. Big Sectors per FAT: 7970
16. Extended Flags: 0x0000
17. FS Version: 0
18. First Cluster of Root: 2 (0x2)
19. FS Info Sector: 1
20. Backup Boot Sector: 6
21. Reserved: 000000000000000000000000
22. Drive ID: 0x80
23. Reserved for NT: 0x00
24. Extended Boot Sig: 0x29
25. Serial Number: 0x3D4308E1
26. Volume Name: MAX1
27. File System Type: FAT32
28. Boot Signature: 0xAA55

On Sun, 19 Oct 2003 14:07:16 GMT, Joe <barakaSpamlesS@hemscott.net>
wrote:

You could:

Explain the exact jumper setting, not what the disk is set to, but
where the jumpers are on the pins.

Do with no other user programs running (assuming the disk is primary
master):

findpart ide fp-a.txt
findpart setsize pm native expert
findpart pm fp-b.txt
findpart finddir pm 509 550 fp-c.txt

The fp-c.txt file probably will be too large for usenet, but you can
mail me the file.

If the setsize command changes the disk size, it will not be kept
after reboot.

Until now it is known that the first logical partition is more or less
damaged.

--
Svend Olaf
http://www.partitionsupport.com/utilities.htm

On Sun, 19 Oct 2003 17:22:04 GMT, svolaf@inet.uni2.dk (Svend Olaf
Mikkelsen) wrote:

recognised the 160 GB natively! This allowed me to undelete one of the
missing partitions with Pmagic. I now have the former E: drive, and
what was the D: is showing as unallocated.. I know this was a pretty
dumb thing to do, but the E: was the most important. Still not good
though....I've checked with partedit and I still have the corrupted
DDO in the boot sector..

I just can't understand why the bios suddenly decided it would
recognise the large disk. When I first got this Mobo, I had terrible
corruption and partition errors which I eventually pinned down to the
PSU(supplying +4.5-6v on the +5). My "current" psu is 4.8-4.9. I'm
beginning to think there is a problem there again. I'll be doing a lot
of backing up tonight.

On Sun, 19 Oct 2003 19:33:14 GMT, Joe <barakaSpamlesS@hemscott.net>
wrote:


know how to did of the dregs of that DDO as well. Basically I have a
good 4 gb c: and a 116 gb d:. In between those is an unallocated
former d: partition of 29 gb.
Here's the new findpart.

OS: DOS 7.10 WINDOWS 4.10

Disk: 1 Cylinders: 19457 Heads: 255 Sectors: 63 MB: 152625

--PCyl N ID -----Rel -----Num ---MB --Start CHS- ---End CHS-- BS CHS
0 - 0B 63 8177022 3992 0 1 1 508 254 63 B OK
509 2 05 60870285243497205118895 3789* 0 1 18945*254 63 +3789OK
4032 1 0B 63247802562120997 4032 1 1 19456 254 63 NB OK
4298 1 0B 63243497142118895 4298* 1 1 19454*254 63 R0 OK
0 - 0B 69047433243497142118895 4298 1 1 19454 254 63 B OK

------FAT CHS -Size Cl --Root -Good -Rep. Maybe --Bad YY-MM-DD DataMB
0 1 33 7970 4 2 7970 0 0 0 03-09-10 1603
4298 1 33 Second FAT not found.

Partitions according to partition tables on first harddisk:

--PCyl N ID -----Rel -----Num ---MB --Start CHS- ---End CHS-- BS CHS
0 1*0B 63 8177022 3992 0 1 1 508 254 63 OK OK
0 2 0F 8177085304367490148616 509 0 1 19454 254 63 OK

509 2 05 60870285243497205118895 4298* 0 1 19454*254 63 OK

4298 1 0B 63243497142118895 4298* 1 1 19454*254 63 R0 OK

On Sun, 19 Oct 2003 17:22:04 GMT, svolaf@inet.uni2.dk (Svend Olaf
Mikkelsen) wrote:

The second line(setsize) above only gave me the error screen BTW.

fp-1.txt:
Findpart, version 4.36.
Copyright Svend Olaf Mikkelsen, 2003.

IDE disks:

Primary Master Model: WDC WD1600JB-00DUA3 Revision: 75.13B75
Disk: PM Cylinders: 16709 Heads: 255 Sectors: 63 MB: 131069
IDE CHS: 16383/16/63 CTM: 16383/16/63 IDE MB: 131072
User sectors: 268435455
Real sectors: 312581808
Sector 0: OK Sector 1000: OK

BIOS: 0x80: 152625 MB







fp-2.txt
Findpart, version 4.36.
Copyright Svend Olaf Mikkelsen, 2003.

Searches for partitions type 01, 04, 06, 07, 0B, 0C, 0E, 82, 83,
plus Fdisk F6 and Lilo sectors. Information based on bootsectors
is marked B. If the disk is larger than supported by BIOS, the
supported part of the disk is examined. Disks are numbered from 1.

OS: DOS 7.10

Disk: PM Cylinders: 16709 Heads: 255 Sectors: 63 MB: 131069
IDE CHS: 16383/16/63 CTM: 16383/16/63 IDE MB: 131072
User sectors: 268435455
Real sectors: 312581808

--PCyl N ID -----Rel -----Num ---MB --Start CHS- ---End CHS-- BS CHS
0 - 0B 63 8177022 3992 0 1 1 508 254 63 B OK
509 2 05 60870285243497205118895 3789* 0 1 18945*254 63 +3789OK?
4032 1 0B 63247802562120997 4032 1 1 19456 254 63 NB OK?
4298 1 0B 63243497142118895 4298* 1 1 19454*254 63 R0 OK?
0 - 0B 69047433243497142118895 4298 1 1 19454 254 63 B OK?

------FAT CHS -Size Cl --Root -Good -Rep. Maybe --Bad YY-MM-DD DataMB
0 1 33 7970 4 2 7970 0 0 0 03-09-10 1603
4298 1 33 Second FAT not found.

Partitions according to partition tables on primary master:

--PCyl N ID -----Rel -----Num ---MB --Start CHS- ---End CHS-- BS CHS
0 1*0B 63 8177022 3992 0 1 1 508 254 63 OK OK
0 2 0F 8177085304367490148616 509 0 1 19454 254 63 OK?

509 2 05 60870285243497205118895 4298* 0 1 19454*254 63 OK?

4298 1 0B 63243497142118895 4298* 1 1 19454*254 63 R0 OK?






fp-3.txt
Finddir, version FP 4.36.
Copyright Svend Olaf Mikkelsen, 2003.

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: PM Cylinders: 16709 Heads: 255 Sectors: 63 MB: 131069
IDE CHS: 16383/16/63 CTM: 16383/16/63 IDE MB: 131072
User sectors: 268435455
Real sectors: 312581808

Start cylinder: 509 End cylinder: 550

--------- CHS ----- LBA -- Cluster (2) ----- LBA -KB YYMMDD
None found.

Joe <barakaSpamlesS@hemscott.net> wrote in message
news:ru15pv8ns2etmlh2vvi389p28vcq3er69p@4ax.com...

Looks much more likely that its something else
corrupting the data, not the 137GB barrier.

Unlikely. Much more likely to be a problem elsewhere.

On Sun, 19 Oct 2003 19:33:14 GMT, Joe <barakaSpamlesS@hemscott.net>
wrote:

Yes, it is difficult to explain what happened here. Usually there is a
natural explanation, but sometimes it must just be examined what is
present. If the BIOS shows a wrong size, it would normally be because
the BIOS detected the disk at a time where the disk size was limited
by jumpers or disk managers.

From other messages it seems as the MBR partition table is now OK, and
that the partition content is not moved 63 sectors into the disk by a
disk manager.

It should be safe to boot directly to a floppy and do "fdisk /mbr",
but since the current MBR can boot the disk, there should be no need
for that. It has no significance if disk manager code is present in
sector 2 to 63 numbered from 0, except that some partition tools may
complain.
--
Svend Olaf

On Sun, 19 Oct 2003 20:52:18 GMT, Joe <barakaSpamlesS@hemscott.net>
wrote:

Good, since when the disk already was recognized correct by the BIOS
(according to another message), the command should not be run. (It was
a missing Findpart edit environment variable).

Now we know that the MBR partition table is not disk manager adjusted,
and that there is no Ontrack 63 sectors offset on the disk.

No traces of FAT or directories were found in the first 329 MB of the
expected location for the lost D: partition. Directories and data
usually still would be present later in the partition. It then will be
a FAT32 without FAT recovery situation.
--
Svend Olaf

On Mon, 20 Oct 2003 00:15:04 GMT, svolaf@inet.uni2.dk (Svend Olaf
Mikkelsen) wrote:

Well, it is late here.

It has no significance if disk manager code is present in sector 2 to
63 numbered from 1, except that some partition tools may
complain.
--
Svend Olaf

svolaf@inet.uni2.dk (Svend Olaf Mikkelsen) wrote:

This can be easily fixed by running CleanTrack0 from
http://resq.co.il/iv_tools.php

Cheers
--
NetZ Computing Ltd. ISRAEL www.invircible.com www.ivi.co.il (Hebrew)
InVircible Virus Defense Solutions, ResQ and Data Recovery Utilities
E-mail sent in reply to this post will not be considered private and
will be answered in the newsgroup. Top posting is not appreciated!

On 27 Oct 2003 07:43:04 -0600, Lippy Espinda <Lippy@alohamotors.com>
wrote:

I assume that you can access usenet from another PC. If not, you
should wait.


Download lippy1.bat in

http://inet.uni2.dk/~svolaf/lippy1.zip

and put lippy1.bat on the same boot floppy as findpart.exe.

Run lippy1.bat, which contains:

set findpart=edit
findpart 1 0 2 - 0F 3892 0 1 19456 254 63 0 19457 255 63 26 zero
set findpart=
findpart 1 table fp1-1.txt

Note that this will delete the current primary partition, since that
partition covers the entire disk.

After that, you can reboot to the floppy, and look at the partitions
from DOS. Note that the first logical partition should get the C:
drive letter, since there is no primary partition.

You have the option to post the content from fp1-1.txt for
confirmation.
--
Svend Olaf

On 28 Oct 2003 12:09:09 -0600, Lippy Espinda <Lippy@alohamotors.com>
wrote:

Cyldir by itself is a DOS tool, and then you could have used the
fp.sys device driver, and then we could have talked about a compact
tool?

Anyway, the partition tables are as expected, and I assume you
verified that the partitions are OK.

You are welcome.
--
Svend Olaf

On Mon, 20 Oct 2003 07:06:42 +1000, "Rod Speed" <rod_speed@yahoo.com>
wrote:

copying a large file near the 137 gb limit and random corruption
appears every time; this is definitely the problem. My BIOS supports
48 bit LBA but windows 98 SE doesn't. As I don't have an Intel
chipset, it looks like an upgraded OS is needed to use the 23 gb
safely. Also, I found this while looking for a
solution(http://www.48bitlba.com/win98.htm):

"CAUTION! You may be able to install a 48-bit LBA drive without either
of the above options where it seems that the drive is working at full
capacity. **However, from our tests we found that data will become
corrupted once the amount of data on the hard drive begins to extend
beyond 137 GB."***

Joe <barakaSpamlesS@hemscott.net> wrote in message
news:r9n7qv4r3rpj3cfks5m6qltodhbmqsaejt@4ax.com...
Yep,

Nope, very unlikely indeed to get the specific
symptoms you are seeing due to that.

What's that supposed to mean ? Do you mean the file itself
is that large ? Presumably not because it isnt possible to
copy a file that large on a drive of that size, there isnt room
for both copys that need to be there during the copy.

If you mean that the file is LOCATED near the 137GB limit,
how did you determine where it is physically on the drive ?

You shouldnt be getting 'random corruption' either. It should
be completely non random corruption that affects the bit of
the file thats over the 137GB limit on the physical drive.

Dont believe it. Its MUCH more likely that you in fact have a
drive that has a problem with the cylinders at the high GB end
of the drive and that the RANDOM CORRUPTION occurs when
the file ends up in those cylinders with the bad sectors in them.

You can test that possibility by running a diagnostic on the drive.

That shouldnt produce RANDOM CORRUPTION.

What the hell has that to do with anything ?

That url below spells out how to do it safely with that OS.

That aint RANDOM CORRUPTION, thats completely predictable
corruption when the file ends up in the space over 137GB.