What Does Microsoft's™ (Win 9x/ME)

do to a Hard Disk?

Copyright©2004 by Daniel B. Sedory


We used a rather small drive (only 540 MB; see details below) for our experiments, and the whole drive was filled with zero bytes (using Maxtor's MAXDIAG.EXE) then checked at various locations with a disk editor to make sure the drive had actually been zero-filled (or cleared). Following this, an arbitrary number of sectors (the first 92,260 consecutive) were then filled with a 5Eh byte (personal choice; it's also the ^ character in ASCII), so we could make sure that any zero bytes written by FDISK could also be identified.

Test Drive Used:
 A Maxtor 7540AV (1046 Cylinders, 16 Heads, 63 Sectors)
 Drive has: 1,054,368 Total Sectors, or 539,836,416 bytes; approximately 539.8 MB or exactly 514.828125 BinaryMB (MiB).

FDISK versions Used:

The experiment was repeated with the MS-FDISK (file date/time) from:

1) Windows 95B Boot diskette (08/24/96 11:11AM ver. 4.00.1111 with a Y2K updated COMMAND.COM dated 02/19/99 10:55am),
2) Windows 98 Emergency Boot Diskette (05/11/98 7:01PM; ver. 4.10.1998) and
3) Windows 98SE Emergency Boot Diskette (04/23/99 10:22PM; ver. 4.10.2222).

Each time, FDISK was set for "Large Disk Support" (32-bit FAT); which Microsoft recommends using on drives of 512 BinaryMB (about 536.87MB) or more. The results were the same for each version.


NOTE: Although it's possible to safely use FDISK to check a drive's currently formatted partitions, it's much safer to use the command:
FDISK  /STATUS  rather than run the risk of accidentally pressing the wrong key (using FDISK interactively) and overwrite some of your sectors! [ Missing the correct key for "Display partition information" and mistakenly bumping the ENTER key a couple times instead (note that not every key on a keyboard is always in perfect condition either!), will launch FDISK's "Verifying drive integrity" routine as it starts to partition your disk! ]

Once you tell FDISK to begin partitioning all or part of a drive (even if you didn't mean to), it will start to perform its Verifying drive integrity, with its nn % complete indicator on the same line. This takes place on the screen entitled:
Create DOS Partition or Logical DOS Drive

As soon as this process begins, it immediately starts writing sectors full of F6h bytes to certain locations on your drive!
I confirmed this (many times over) by breaking out of the program (CTRL+C) or pressing CTRL+ALT+DEL (forcing a reboot) before FDISK had a chance to proceed any further. ( It took less than 10 seconds for this small drive to complete this phase of the FDISK process! All I can say if you suddenly realize you're doing this to the "wrong drive" is to reboot (whichever way you prefer) as quick as you can! If you catch it at less than about 20% to 30% you might still have an intact second copy of the FAT to use; the quicker you act, the better off at any point during this process).


What does the FIRST "Verifying Drive Integrity"
Process Do?

It writes to and verifies (reads back) sectors full of F6 bytes on your hard drive; I don't know if it does both for each sector written (that would be best for anyone who makes a mistake and tries to catch it in time) or if it writes all of them first, and then does the verification as part of its % count. These "F6 sectors" are written to the 1st and 7th sectors of each "Head" number (except for Head 0) until a calculated number of sectors (depending upon the size of the partition) at the beginning of the drive (or partition) have been "verified" by FDISK.
[ Some would call this damaging the drive's data (rather than 'verifying its integrity'). Why? Because not all FDISK programs act this way! As a matter of fact, many of them will only write to the MBR or EBRs; Linux's fdisk program, for example, is a non-destructive fdisk. ]

The F6-Sectors that MS-FDISK wrote to our 540MB Drive

Absolute Sectors (C,H,S values)
Absolute Sectors (C,H,S values)
. . .
. . .
. . .
. . .
These continue in the same pattern as above, past the last
Head (
31*) of Cylinder 0 and into Cylinders 1 and 2 :
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
4668 was the last sector to be filled with F6 bytes.
* The number of Heads, 32 (since the count begins with a 0), reflects the choice made by the BIOS of this computer when translating its given CHS of  1046, 16, 63 into one having no more than 1024 cylinders.  Most drives today use all 255 heads in the Partition Table (yes, though it is possible for a byte to count up to 256, only 255 are used; see this note: Why MBRs do not use 256 Heads for the reason). Many drives that are larger than 8.4 GB have the values 1023, 254, 63 (for 1024 cylinders, 255 heads and 63 sectors) in their Partition Table. But I've seen Ending CHS sets with slightly smaller cylinder values. If  you ever see a much larger value (such as 4096 cyl.), you need to know that's only an interpretation by the utility program you are using, since it's impossible to count past 1024 cylinders in a Partition Table! There are many variations in how the BIOS chips and/or disk utilities (such as Partition Magic) calculate CHS values these days.

What does the SECOND "Verifying Drive Integrity"
Process Do?

The next screen you would normally encounter when using FDISK to set up a hard drive is titled: Create Primary DOS Partition which asks the question, "Do you wish to use the maximum available size for a primary DOS partition and make the partition active (Y/N)............? [Y]" Once you press the ENTER key, FDISK repeats its Drive Integrity process once again! You'll see the same "Verifying drive integrity, nn % complete." line at the bottom as you did before. It may be that FDISK goes over the same exact sectors listed above twice, but since I can't run this part of the program without first going through the part above, there's no way I can say for sure.

During this last phase of the partitioning, FDISK writes its version of the MBR code to the very first sector on the drive (even if it already exists!) and enters the new partition's data into the Partition Table. For a view of every byte of the code that the MS-DOS 7.1 FDISK program writes to the MBR, take this link.

MS-FDISK wrote the following data to this drive's Partition Table:

                      Starting loc   Ending loc   Relative  Number of
#     Type      Boot  Cyl Head Sec  Cyl Head Sec   sectors    sectors
- ------------  ----  --- ---- ---  --- ---- ---  --------  ---------
0  FAT-32(0Bh)   Yes   0    1   1   521   31  63       63   1,052,289

You may see Type 0Ch ("FAT32 LBA") here instead. When MS-FDISK is run on a computer with a somewhat older BIOS, it may still reserve all the space in the last cylinder of a drive (about 1MB for this one) for the now archaic "test cylinder" (apparently for some kind of compatibility reason). But, when you partition the same drive on a computer that has a modern (usually made in 2000 or later) BIOS chip, it should use the whole drive for the partition; producing these results:

                      Starting loc   Ending loc   Relative  Number of
#     Type      Boot  Cyl Head Sec  Cyl Head Sec   sectors    sectors
- ------------  ----  --- ---- ---  --- ---- ---  --------  ---------
0  FAT32(0Bh)    Yes   0    1   1   522   31  63       63   1,054,305

At this point, it also warns you that you must reboot for the new partition data to take effect on your system. When you do, the OS will recognize the partition and DOS (or Windows) will assign it a logical drive letter. If this was the only drive on the system, once you reboot with a diskette again, you can even enter C: at the DOS Prompt and have C:\> appear on the screen, but trying to read any data from this new partition (such as entering, DIR C:) will cause that horrible DOS error message:

C:\>dir c:
Invalid media type reading drive C
Abort, Retry, Fail?

to appear. You can take this next link to read about "What Does Win 9x's MS-FORMAT do to your Hard Drive?" (Before you can actually store files in any new partition, you must also FORMAT it.)

So What happens When FDISK overwrites Sectors
on a Drive already containing Valuable Data?!?

The major problem with MS-FDISK: It was purposely designed (or so it seems at least) to destroy the means of being able to access any data that was stored on the drive prior to using it!  And if it wasn't bad enough that FDISK writes F6-sectors all over both copies of the FAT (File Allocation Table), it also overwrites sectors in the Root Directory and may even overwrite some of your Data too! This is why MS-FDISK is so dangerous to your data, if used incorrectly!

Because of the difficulty of getting back any files that are kept in the Root Directory, it's a very good idea to store important data files in a subdirectory one or two levels down from the Root (note how MS-Windows does this with its "Program Files" subdirectory), since each Application will have their own 'directory file' to rebuild lost data from! This is why commercial software programs such as RunTime, Inc.'s "GetDataBack" can retrieve many of your files after an 'FDISK and/or FORMAT accident' occurs. Remember, there's a very low probability of recovering a file if it's being stored in the Root Directory if  its directory data is close to the start of the volume's Data area. Like many other things in life, it's safer not to be too close to any boundaries (like a fish at the edge of a school  in shark infested waters, or someone walking on a ledge 200 meters high with no safety net).

[ We may expand on the single drive example presented here at a later date, but the data above should be more than adequate for an understanding of what MS-FDISK does. ]


Last Revised: 3 August 2004.
Updated: 4 May 2005.

You can write to me using this: online reply form.
(It opens in a new window.)

Back to: Detailed Notes on MS-FDISK

MBR and Volume Boot Records Index

The Starman's Realm Index Page





Hosted by uCoz