Jump to content

Recommended Posts

Posted

There may be a problem with the Information Sector (Second Boot Sector) that is preventing DOS or Windows from updating the Free Space Entry. You would have to send me the Second Boot Sector from both a normal Partition and from a Problem Partition to examine.

Ok. What I did was to capture the first 3 clusters of the volume, first with the drive formatted using format.com, and second with the drive formatted using the Western Digital Data Lifeguard program (WD-DLG). I captured the first 3 clusters because I wasn't sure if the 3 boot sectors are stored each in their own cluster. If they're not, then I suppose that the 3 boot sectors will all be found in the first cluster, and the other 2 clusters can be ignored.

I can tell you right now that there are some differences in the first sector between the two versions.

The first two Sectors were enough.

WD-DLG is flawed, it set the FS Info Sector Pointer to 0, it should have been 1. You can see the difference in the two text files you posted.

The FS Info Sector is the Second Boot Sector (LBA Sector 1). Without a proper pointer, the Free Space could not be updated.

Yea, so the format.com I've been using on the 1.5 tb drive comes from win-98se. Looks like it's good for the upper limit on a FAT32 volume - 2 TB yes?

I'm not sure how far FORMAT.COM can go, but VFAT.VXD has a bug that can cause lockups when a Partition is larger than 1TiB.


Guest wsxedcrfv
Posted (edited)

WD-DLG is flawed, it set the FS Info Sector Pointer to 0, it should have been 1. You can see the difference in the two text files you posted.

The FS Info Sector is the Second Boot Sector (LBA Sector 1). Without a proper pointer, the Free Space could not be updated.

How would you explain the other differences between the two, such as:

WD-DLG vs MS-DOS

Physical drive: 129 vs -1

Cylinders: 625 vs 0

Heads: 255 vs 0

Sectors per cylinder: 63 vs 0

Why would MS-DOS format.com set the cylinders, heads, and sectors per cylinder all to 0? What is the operational relevance of that, as well is setting the Physical drive to -1?

Does the second boot sector follow the first one in the first cluster? I haven't looked at the second boot sector - are they the same or different between these two copies?

Would changing the FS Sector value from 0 to 1 on the WD-formatted volume be the remedy or fix in this situation?

I'm not sure how far FORMAT.COM can go, but VFAT.VXD has a bug that can cause lockups when a Partition is larger than 1TiB.

Is VFAT.VXD contained within Win-98's self-generated "master" driver (I forget the file name)? I don't see it as a separate file in this computers various c:\windows directories.

I seem to have 2 versions of that file in my archives - one with version 4.10.1998 and the other with version 4.10.2223 (10/19/2000). Is there no version 4.10.2222 for that file ???

Edited by wsxedcrfv
Posted

Are you refeering to the two .txt files?

WHAT did you use to make them?

Anyway these:

Logical drive: D

Physical drive: -1

Total logical sectors: 1062876402

Cylinders: 0

Sectors per cylinder: 0

Heads: 0

Bytes per sector: 512

Logical drive: D

Physical drive: 129

Total logical sectors: 1062876402

Cylinders: 625

Sectors per cylinder: 63

Heads: 255

Bytes per sector: 512

Are info that come from the MBR (and not from the bootsector) i.e. from PhysicalDrive and not from LogicalDrive.

jaclaz

Posted

It's actually this one:

http://www.theabsolute.net/sware/dskinv.html

It is not - as a general rule - a good ide to link to a .exe file directly.

It is clearly a gltch of the program.

Open the disk in any "simple" tool, like the ones listed here:

http://mirror.href.com/thestarman/asm/mbr/BootToolsRefs.htm

or beeblebrox:

http://replay.waybackmachine.org/20080423005903/http://students.cs.byu.edu/~codyb/

http://replay.waybackmachine.org/20060223003038/http://students.cs.byu.edu/~codyb/beeblebrox9xsetup.zip

You will see that these data:

  • Total logical sectors: 1062876402
  • Cylinders: 625
  • Sectors per cylinder: 63
  • Heads: 255

will remain the same (they are physical values of the actual hard disk).

However, I was incorrect, these data come from system calls, particularly the 129 means drive 0x81 i.e. second drive in DOS (as taken from the BIOS) and the rest are physical values, but the cylinder one is also blatantly wrong.

625*255*63=10,040,625 sectors * 512=5,140,800,000

so they make NO sense.

On the other hand, the value of 1,062,876,402+63=1,062,876,465/63=16,871,055/255=66,161 Cylinders

Your disk should have a "virtual CHS geometry" of 66,161 or 66,162/255/63

jaclaz

Guest wsxedcrfv
Posted

Is there a *simple* program, that either runs in DOS or win-98, that doesn't have a million different options or settings, that will save the boot sector(s) of the desired drive? If there is such a program, please post a link to the .exe or .zip or what-ever. I tried the beeblebrox program and I have no clue how to use it to read and save-to-file the desired sectors.

Unless rloew is reasonably sure that the cluster files that I've already saved are the actual boot sectors that are in question.

Posted

Well, the easiest would be HDhacker but is NT/2k and following only.

Beeblebrox and similar tools tend to just save the first sector (which actually in the case of FAT32 is however the only one containing meaningful DATA).

For DOS you can use MBRwizard

http://mbrwizard.com/

you want the "Legacy" version, please note how you need to get to the firesage site through the above "old" site in order to get the "Legacy" tab.

But more generally any disk editor working under DOS/Win9x will do, a good one is the PTS-DE one:

http://mirror.href.com/thestarman/tool/FreeTools.html#PTSDE

http://mirror.href.com/thestarman/tool/de/PTS-DE.htm

jaclaz

Guest wsxedcrfv
Posted

The freeware versions (including the DOS versions) are here: mbrwizard. :)

I had actually tried MBRwizard before I found Disk Investigator.

When you use MBR wizard to save the MBR (mbrwiz /disk=1 /save=mbr.bin) you only get a 512-byte file. I was thinking that wasn't good enough if the goal is to see at least the first two if not all 3 boot sectors.

So if the first sector is relevant, I used mbrwizard to save the mbr of the 500-gb volume as described above. I also saved the mbr of another volume created by WD-DLG on another drive. This volume is about 37.4 gb in size, has 9.3 million clusters, and has 4kb cluster size. The first DIR command on this volume also takes some time to complete. I saved these mbr's as dlg-mbr.bin and dlg-mbr2.bin and zipped them into the file I'm attaching to this post.

MBR.ZIP

Posted

The MBR is NOT the bootsector.

This is where you probably are confusing matters.

Normally the bootsector of first partition is at sector 63 (CHS 0/1/1) on "legacy" systems (up to XP/2003) and on sector 2048 (CHS 0/32/33) on Vista :ph34r:/2008/7 (if not patched to follow "legacy" Rules)

The MBR is NOT part of the volume, it is part of the disk.

Review this:

http://mirror.href.com/thestarman/asm/mbr/DiskTerms.htm

http://mirror.href.com/thestarman/asm/mbr/DiskTerms.htm#LOC

and take some time on the Starman's pages to understand the structure of disks and partitions and volumes and filesystems.

First sector of a hard disk (sector LBA0) is the MBR or Master boot record.

The bootsector of a partition starts at first sector of the partition or volume, as said for first partition it is normally LBA 63 or 2048 depending on the OS that partitioned the volume.

More generally you read the partition table in the MBR (and for extended partitions in the EPBR chain) to know where the bootsector of a given partition starts.

FAT 12/16 the bootsector is 1 sector long

FAT32 the bootsector is actually 3 sectors long, first, second and third if formatted under DOS/Win9x/Me:

http://mirror.href.com/thestarman/asm/mbr/MSWIN41.htm

first, second, third and thirteenth:

http://mirror.href.com/thestarman/asm/mbr/FAT32brcomp.htm

if formatted under 2K/XP and later

(for the record, for unknown reasons the FAT32 of ReactOS uses 15th sector innstead of 13th)

jaclaz

Posted (edited)

After looking at your ZIP attachments, a further clarification (re - jaclaz) is in order.

Sectors are (generally) 512-bytes long. The MBR is one sector (always 1st sector). Each PBR is as-stated above and is JUST the 1st three sectors of the beginning of any given partition (Volume, if you will). Each Partition is "pointed to" by the MBR Partition Table. Each Partition has a Reserved Area for the Root Directory. All Files and further Directory/File chains lead off of the Root.

There are rules that must be followed for 16-bit/32-bit/(other, e.g. 48-bit) operations and the info is usually stored in the associated places in the HDD according to the formatter being used. It's the code/stored-info combo that's maybe confusing you. ("why this does this and that does that?"). It's the point that's been made already (albeit vaguely).

Go get a Trial version of Hex Workshop - it allows to read each singe Physical Drive and each Logical Partition. Just for fun, then you may understand... (along with StarMan's great information).

Edited by submix8c
Guest wsxedcrfv
Posted

Ok, after downloading something called HxD Hex Editor (http://www.mh-nexus.de/hxd/) I was easily able to modify the single-byte value corresponding to the "FS Info Sector", also known as the "Sector Number of the FileSystem Information Sector". This is the 30h byte of the FAT32 Boot record (the first sector of every partition). A description of the FileSystem Information Sector can be found here: http://www.easeus.com/resource/fat32-disk-structure.htm. It contains the number of free clusters, and the cluster number that was most recently allocated.

MS-DOS Formatted volumes seem to always have the FS_Info_Sector set to 1. All the volumes that I've seen formatted with the Western Digital Data LifeGuard utility has the FS_Info_Sector set to 0. By changing it to 1 using HxD, I immediately noticed that the completion delay to perform the first command such as DIR or Chkdsk has been eliminated. GUI Scandisk (running under win-98) ran fine on these modified (or corrected?) volumes - but Norton Disk Doctor Still crashes with a blue-screen error even when operating on the volume with the smallest number of clusters (9.35 million).

So I can see an opportunity here to create a simple utility that checks the value of FS_Info_Sector and changes it from 0 to 1 if the user is experiencing a large initial time delay to access the drive. Over time, I'm sure we can identify which drive-preparation utilities correctly set that byte to 01, and which of them set it to 00.

Thanks to Rloew for quickly indicating which byte in the Boot Record (or Boot Sector) was the likely cause of this drive access-delay issue.

PS: If there is a third boot sector as part of the Boot Record, is there any similar pointer to it's location? And a description of it's contents?

PPS: I still have a feeling that there is some difference (maybe small, maybe significant) in these various FAT32 data structures between Windows 98se and Windows ME. Does anyone know for sure?

Posted
PS: If there is a third boot sector as part of the Boot Record, is there any similar pointer to it's location? And a description of it's contents?

It's complicated... FAT-32 always uses 3 sectors for the boot structure, however:

1) If the OS is MS-DOS,

LBA0 is the boot sector that loads IO.SYS and LBA6 is its backup;

LBA1 is the FSInfo sector and LBA7 is its backup;

LBA2 has the second part of the boot code (and is pointed to from within the code in LBA0) and LBA8 is its backup.

2) If the OS is Win 2k/XP/2k3,

LBA0 is the boot sector that loads NTLDR and LBA6 is its backup;

LBA1 is the FSInfo sector and LBA7 is its backup;

LBA2 is blank (or has whatever contents it had before), and so is LBA8!

LBA12 has the second part of the boot code (and is pointed to from within the code in LBA0), and has *NO* backup!

3) If the OS is ReactOS,

LBA0 is the boot sector that loads FreeLoader and LBA6 is its backup;

LBA1 is the FSInfo sector and LBA7 is its backup;

LBA2 is blank (or has whatever contents it had before), and so is LBA8!

LBA14 has the second part of the boot code (and is pointed to from within the code in LBA0), and has *NO* backup!

See:

And this Tutorial about ReactOS

Posted

I'm not sure how far FORMAT.COM can go, but VFAT.VXD has a bug that can cause lockups when a Partition is larger than 1TiB.

Is VFAT.VXD contained within Win-98's self-generated "master" driver (I forget the file name)? I don't see it as a separate file in this computers various c:\windows directories.

I seem to have 2 versions of that file in my archives - one with version 4.10.1998 and the other with version 4.10.2223 (10/19/2000). Is there no version 4.10.2222 for that file ???

VFAT.VXD is compressed and inserted into WINDOWS\SYSTEM\VMM32.VXD.

Version 1998 is the original Windows 98 Version

Version 2222 is the original Windows 98.SE Version.

Version 2223 is the latest Windows 98.SE Update.

I have a Patch to correct this bug.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...