Windows 95 Partition Bug
By: Howie Andreasen

Win'95 seems to have a very serious partitioning flaw in its' Fdisk routine creating the extended partition. The following text describes this flaw in detail and some of the ways you can avoid it.

Some people didn't seem too interested when I first reported this anomally except for the people at MicroFirmware who have been working with me on this problem, which appears to be a MAJOR bug in the Win'95 operating system. We will begin to see many, many more reports of this problem as time goes on because of the authoring of BIOS's that support int13 extensions in order to allow Win'95 to take full advantage of LBA addressing on the new and larger EIDE Harddrives, along with the newer systems being shipped with and having their harddrives formatted with Win'95.

The following is the formula required to have this anomally occur:

1. You have to have one of the latest BIOS's that support the use of int13 extensions and full LBA.

2. You have to Fdisk using the Win'95 version of the program.

3. You have to have one of the latest EIDE harddrives that support full LBA and have to have partitioned it into at least two partitions.

Once you have the above ingredients you will unfortunately have the same problem on your hands. According to Microsoft, they have become aware of the problem but have no plans to correct it until the release of the next operating system. Until then save your old DOS disks and Fdisk with them and then finish the job with Win'95.

By having this problem brought in to the sporlight we be able to help prevent someone from suffering some very serious losses through data curruption. To most of the home PC users like myself, the data loss would not be too serious other than recreating some lost data but the potential disaster for business is could be astronomical.

Sincerely,

Howie Andreasen
Sickdude@aol.com

Problems with New Partition Types Used by WIN95 FDISK
Part One - WIN95 FDISK Shows PRI or EXT DOS Partition, DOS 6.x Shows NON-DOS

We have seen some cases where a hard drive will work fine with WIN95 but the drive will not show up when booted under DOS 6.x and the DOS 6.x FDISK command will show that the drive has a NON-DOS partition.

Supposedly WIN95's FDISK and DOS 6's FDISK are interchangeable. For the most part they are - any partition created by MS-DOS 6.0, 6.20, 6.21, or 6.22 (or even most earlier versions) should work fine with WIN95. WIN95's FDISK should show these partitions as Primary DOS or Extended DOS Partitions just as DOS 6's FDISK would. In fact WIN95 actually runs on top of MS-DOS 7.0. The WIN95/DOS 7 FDISK command resides in the WINDOWS\COMMAND directory. WIN95's FDISK has added two new partition types, which it may choose to assign to a drive that it is partitioning. These are type 0Eh for a Primary DOS Partition and type 0Fh for an Extended DOS Partition. These appear to be treated the same as type 06h (Primary DOS) and type 05h (Extended DOS) which are used by MS-DOS 3.3, 4.x, 5.x and 6.x.

WIN95 FDISK may use Type 6 and Type 5 when partitioning a drive or it may use the newer Type E and Type F. If a partition is labeled as type E or F, then any DOS version prior to DOS 7 (WIN95) will consider this a NON-DOS Partition and will not be able to recognize it.

If WIN95 is installed on top of an existing DOS 6.x / WIN3.1 installation, this problem will not occur since WIN95 is not partitioning the hard drive and WIN95 will not change an existing partition type. The problem also will not occur if WIN95 is installed on a new, blank hard drive, since DOS 6.x can not be installed on top of a WIN95 installation.

The scenario in which we initially discovered this anomaly is also not a likely one - partitioning drive with WIN95 FDISK and then installing an earlier DOS. The situation in which this is likely to occur is when a new harddrive is added to an existing hard drive so that one drive was partitioned with DOS 6 FDISK and another drive is partitioned with WIN95 FDISK. Sometimes there is no problem since WIN95 FDISK may use the normal type 6 or type 5. But if the drive is labeled as a type E or F and the system is booted from the original drive using the option to boot previous DOS version, then the new drive will not be accessible by DOS 6.x or earlier.

These new partition types are mentioned in the Microsoft Knowledge Base http://www.microsoft.com/kb/) in article Q69912.

The reason for these new partition types has to with supporting the new Int13 Extensions (which both our BIOS and WIN95 can use) to take full advantage of LBA addressing on newer EIDE hard drives. If a hard drive supports LBA and the BIOS supports LBA, then the BIOS and the drive will use LBA addressing between themselves. To take full advantage of LBA, it should also be used by the operating system and applications when communicating with the drive. Apparently these new partition types are used by WIN95 to accomplish this.

The solution to the problem of not being able to access a drive partitioned with WIN95 FDISK is to repartition the drive with DOS 6's FDISK. This solution was suggested to us by the second and third level of Microsoft's technical support that we spoke with. Microsoft also explained that this is an example of a problem that occurs as technology is moved into the future - in otherwords we can't expect all new software and hardware to be backwards compatible with everything that precedes it or we will not be able to advance to newer standards.


Part Two - "Phantom" Drives and Potential for Massive Data Corruption

And there is more to the story. Even in cases where DOS 6.x or earlier is not in the picture at all, there can still be major problems related to the new partition types used by WIN95. Apparently these new partition types are used by WIN95 FDISK when it detects that the BIOS supports the new int13 extensions. The following details an experiment we did to duplicate a problem reported by a customer.

  Motherboard: Micronics JX30 
  BIOS: Micro Firmware Phoenix BIOS part no. M4HS45 version 4.05.07
  Hard Disk 1: Western Digital AC31200 1.2GB EIDE
  Hard Disk 2: Western Digital AC2850 850MB EIDE
  CD-ROM: NEC CDR260

Zeroed out boot sectors on both drives using DEBUG script (as described in HDCLEAR.TXT - available on our BBS). Booted with WIN95 Startup Disk - used WIN95 FDISK to create primary partition on first half of first drive, extended partition with one logical drive on second half, and one primary partition on second drive using entire drive. We found that the first drive had a type 6 (primary) partition and a type F (extended) partition and the second drive had a type E (primary) partition. Then installed WIN95 with no problems.

All drive letters look as expected:

HD1: C:, E:
HD2: D:
CD-ROM: F:

Restarted system in MS-DOS mode - drive letters still look OK. We copied a file to drive E:, we'll call it EFILE1. Then we typed EXIT to go back to WIN95. We now have an extra drive letter showing up under My Computer. C:, D: and F: are the same, what was drive E: is now G:, and E: is now a mirror image of drive C:. Reboot and everything looks OK. (Note - this did not occur in cases where the system decided to reboot when we typed EXIT to return to WIN95). We also found this - the file that we copied to drive E: in DOS mode does not show up if we start a DOS prompt under WIN95 and look at at drive E:. If we now copy a different file, EFILE2, to drive E:, this file will not show up if we restart in DOS mode. The other file, EFILE1, will still be present. We edited the partition table to change the primary partition on the first drive to a type E: - same results. We then changed all partition types to type 5 and 6 - all problems disappeared. Also - we later repeated the above experiment with just one harddrive, also partitioned into a primary and an extended partition, and had the same results.

On further investigation our engineers found that WIN95 is modifying some of the partition information in memory (see last section below) when changing between DOS mode and WIN95. This happened only on the partitions that were marked as type E or type F. This did not occur when the 32BitDisk drivers were disabled in WIN95.

These findings are preliminary, but we believe this to be a bug in WIN95. We are still looking into this and will attempt to pursue this with Microsoft. We welcome any information on this problem. We may possibly decide to remove the int13 extensions from our BIOS ("dumbing it down") to prevent this problem.

In the meantime we recommend that all large drives to be used with WIN95 under Phoenix 4.04 or 4.05 BIOS (or any BIOS implementing int13 extensions) be partitioned with DOS 6.22 FDISK. In the case of drives already using a type E or type F partition, it is possible to just edit the partition table and change the byte that describes the partition type. We can't guarantee that this is safe to do but it seems to be. This procedure is described in the following section.

Also - we later repeated the above experiment with just one harddrive, also partitioned into a primary and an extended partition, and had the same results.


Here is a DEBUG script that can be used to look at the partition table to identify the partition type. Various disk utilities can be used instead.


  C:\>DEBUG
      - A 100
       xxxx:xxxx MOV AX,201  (ignore xxxx:xxxx segment:offset values on left)
       xxxx:xxxx MOV BX,200
       xxxx:xxxx MOV CX,1
       xxxx:xxxx MOV DX,80   (or use 81 for 2nd drive, 82 for 3rd, 83 for
4th)
       xxxx:xxxx INT 13
       xxxx:xxxx INT 3
                    (press ENTER an extra time here to return to dash prompt)
       - G=100
                    (ignore register dump)
       - D 3BE 3FF  (following output is a hex dump of the partition table)

                                                           x1 x2 
       xxxx:xxxx x3 x4 x5 x6 x7 x8 x9 10-11 12 13 14 15 16 xx xx 
       xxxx:xxxx xx xx xx xx xx xx xx xx-xx xx xx xx xx xx xx xx 
       xxxx:xxxx xx xx xx xx xx xx xx xx-xx xx xx xx xx xx xx xx 
       xxxx:xxxx xx xx xx xx xx xx xx xx-xx xx xx xx xx xx 55 AA 

       - Q        (quits back to DOS prompt)

The hex dump resulting from above procedure shows the partition table for the first hard drive. The above values 1 through 16 are the 16 bytes (each represented by 2 digits of hexadecimal) that hold the information for one partition. There are four 16-byte slots - so that four paritions can be defined on the drive - for instance, a Primary DOS parition and an Extended DOS partition may be defined, as well as partitions created by other operating systems. These four 16-byte slots are followed by the the values 55 AA which identifies this as a valid partition table. The 55 AA also indicates the end of the boot sector. The fifth byte in each slot (5 above) indicates the partition type. Here are the partition types used by MS-DOS as indicated in Q69912:

    Type:         Size:     FAT type:    First used in:
    01 - PRI DOS  0-15MB    12-bit FAT   MS-DOS 2.0
    04 - PRI DOS  16-32MB   16-bit FAT   MS-DOS 3.0
    05 - EXT DOS  0-2GB     n/a          MS-DOS 3.3
    06 - PRI DOS  32MB-2GB  16-bit FAT   MS-DOS 4.0
    0E - PRI DOS  32MB      16-bit FAT   Windows 95
    0F - EXT DOS  0-2GB     n/a          Windows 95

Here are what some of the other values indicate:

   1 - Active Status 80 = Active
                      00 = Not Active

   2 - Starting Head of Partition

   3/4 - Starting Cylinder and Sector (combined)

   5 - Partition Type

   6 - Ending Head of Partition (1 less than total number of heads)

   7/8  -  Ending Cylinder and Sector (combined)

   9/10/11/12 - Relative Partition Sector Start
             (no. of sectors between partition table and start of partition)

   13/14/15/16 - Size of Partition (in sectors)



Here is a DEBUG script that can be used to modify the partition type. Various disk utilities can be used instead.

CAUTION: Be very careful not to make any mistakes in this procedure. This also assumes that DOS is the only OS in the picture and that there is nothing complicated about the hard drive setup is - if partitions from other operating systems are present, results may vary. Also we cannot guarantee that this procedure is safe anyway. We strongly recommend that a drive be repartitioned with DOS 6.x FDISK instead of modifying the partition table. Please make sure that you have a complete backup before beginning.

Note that the first part of this script is the same as that above. You can use the above script to look at the partition table and then just continue on with the first "- E" below instead of quitting with "-Q".

  C:\>DEBUG
      - A 100
       xxxx:xxxx MOV AX,201  (ignore xxxx:xxxx segment:offset values on left)
       xxxx:xxxx MOV BX,200
       xxxx:xxxx MOV CX,1
       xxxx:xxxx MOV DX,80   (or use 81 for 2nd drive, 82 for 3rd, 83 for 4th)
       xxxx:xxxx INT 13
       xxxx:xxxx INT 3
                      (press ENTER an extra time here to return to dash prompt)
       - G=100
                      (ignore register dump)

       - E 3C2        (to show type of partition in first slot)
       xxxx:xxxx NN.  (ignore segment:offset to left)
                      NN indicates partition type. To change the type, just
                      type in the new type immediately following thedot and
                      then press ENTER to return to dash prompt
       - E 3D2        (to show type of partition in second slot)
                      This will also return a segment:offset valuefollowed 
                      two digits of hex and a dot. Change as above.
       - E 3E2        (to look at 3rd entry - normally 00)
       - E 3F2        (to look at 4th entry - normally 00)

So far changes have only been made in memory - you can bail out by typing Q at the dash prompt. To write these changes to the partition table, continue:

       - A 100
       xxxx:xxxx MOV AX,301
                      (press ENTER an extra time to return to dash prompt)
       - G=100        (ignore register dump)
       - Q            (quits to DOS prompt)

Here is some additional detail from our cheif engineer on what bytes are being modified:

The bytes that are getting changed are in one of DOS's data tables; It's something like this:

Offset  Description
------  -----------
00h     DWORD pointer to next table entry; offset is 0FFFFh if last one.
04h     BYTE  BIOS drive (80h=first hard drive, etc.)
05h     BYTE  relative DOS drive (0=A,1=B,2=C,etc)
06h     WORD  sector size
08h     BYTE  number of sectors per cluster
09h     WORD  number of reserved sectors
0Bh     BYTE  number of copies of the FAT
0Ch     WORD  number of root directory entries
0Eh     WORD  number of sectors per DOS drive (for drives <32M)
10h     BYTE  media type (0F8h for hard drive partitions)
11h     WORD  number of sectors per FAT
13h     WORD  number of sectors per track
15h     WORD  number of heads
17h     DWORD number of hidden sectors
1Bh     DWORD number of sectors per DOS drive (for drives >32M)
1Fh-26h       ?????
27h-3fh       Seems to be a duplicate of offsets 06h-1Eh
40h-4Ah       ?????
4bh-55h       Volume label
56h-5Ah       ?????
5Bh-63h       Filesystem type (FAT12 or FAT16)
The descriptions for offsets 06h-1Bh are based on what seems to be exactly the same data in the DOS boot sector for the partition.

The problem encountered, at for drives with partition type 0fh, is that the data at offset 17h in this structure seems to be based from the beginning of the physical drive, not from the partition table defining the partition as is usually the case. Once Windows 95 is started with the 32 bit disk access enabled, something changes this value to that of the relative sector start field in the partition entry for that partition. At this point, Windows 95 is happy with the extended partition, but if you exit back out to DOS, or run an program in single application mode, the extended partition looks trashed (as DOS is looking in the completely wrong location on the drive for it). Of course, attempting to write to the extended partition at this point will trash data elsewhere on the drive too.


------------------------------------------------------------------------------

     Micro Firmware Technical Support
-----------------------------------------------------------------------------
     Voice 405-321-8333                 email  support@firmware.com
     Fax   405-321-8342                 WWW    
http://www.firmware.com
     BBS   405-573-5538                 CIS    GO PCVEND Section 8