The Starman's Free Tools Page
MBR
and Boot Records Index The Starman's Realm Index
This page examines how the Windows™
95B, 98, 98SE and Me Operating Systems
make use of the bytes at offsets 0DAh-0DFh of the first sector
(MBR) of any hard drives connected to a computer.
WARNING!
The most important thing you need to know from
this page is:
If you make an exact copy of any drive's MBR after using the Win 95B, 98, 98SE or Me operating systems onto another physical drive (typically you would do that in order to transfer your whole drive contents to a larger drive, or just to have a "backup" drive) and reboot the OS while both of those drives are connected, you will most likely experience problems ranging from hardware that appears to have never been installed (missing drivers, etc.) to possibly not being able to boot up the OS (blue screen)!
The cause is simple: These OSs choke and sputter whenever they see two MBR sectors (one per drive) with exactly the same mystery bytes; which we've identified as a drive number/timestamp! All the details are presented below.
A Preventative Solution: If you know for sure that the first sector of your HDD (the MBR) does not contain any Boot manager or extended BIOS software (only the usual Win98/Me MBR code), then boot up with a Windows 98/Me Emergency Boot Disk and perform the FDISK /MBR command on that drive (which writes zeros to the mystery bytes). If you'd rather use a disk editor under DOS, that's fine too; anything that will change one drive's timestamp.
If you've already run into problems by booting up with both an original and a copied drive connected under Win98/Me, the first step would still be the same: change one of the timestamps so it won't happen again!
The six bytes with blue highlight in this disk editor view:
Absolute Sector 0 (Cylinder 0, Head 0, Sector 1)
0 1 2 3 4 5 6 7 8 9 A B C D E F
0000 33 C0 8E D0 BC 00 7C FB 50 07 50 1F FC BE 1B 7C 3.....|.P.P....|
0010 BF 1B 06 50 57 B9 E5 01 F3 A4 CB BE BE 07 B1 04 ...PW...........
0020 38 2C 7C 09 75 15 83 C6 10 E2 F5 CD 18 8B 14 8B 8,|.u...........
0030 EE 83 C6 10 49 74 16 38 2C 74 F6 BE 10 07 4E AC ....It.8,t....N.
0040 3C 00 74 FA BB 07 00 B4 0E CD 10 EB F2 89 46 25 <.t...........F%
0050 96 8A 46 04 B4 06 3C 0E 74 11 B4 0B 3C 0C 74 05 ..F...<.t...<.t.
0060 3A C4 75 2B 40 C6 46 25 06 75 24 BB AA 55 50 B4 .u+@.F%.u$..UP.
0070 41 CD 13 58 72 16 81 FB 55 AA 75 10 F6 C1 01 74 A..Xr...U.u....t
0080 0B 8A E0 88 56 24 C7 06 A1 06 EB 1E 88 66 04 BF ....V$.......f..
0090 0A 00 B8 01 02 8B DC 33 C9 83 FF 05 7F 03 8B 4E .......3.......N
00A0 25 03 4E 02 CD 13 72 29 BE 46 07 81 3E FE 7D 55 %.N...r).F..>.}U
00B0 AA 74 5A 83 EF 05 7F DA 85 F6 75 83 BE 27 07 EB .tZ.......u..'..
00C0 8A 98 91 52 99 03 46 08 13 56 0A E8 12 00 5A EB ...R..F..V....Z.
00D0 D5 4F 74 E4 33 C0 CD 13 EB B8 00 00 00 00 00 00 .Ot.3...........
00E0 56 33 F6 56 56 52 50 06 53 51 BE 10 00 56 8B F4 V3.VVRP.SQ...V..
00F0 50 52 B8 00 42 8A 56 24 CD 13 5A 58 8D 64 10 72 PR..B.V$..ZX.d.r
0100 0A 40 75 01 42 80 C7 02 E2 F7 F8 5E C3 EB 74 .@u.B......^..t
0 1 2 3 4 5 6 7 8 9 A B C D E F
|
These six bytes
are what we originally called the mystery bytes.
The first two bytes at offsets 0DAh-0DBh,
will always be zero!
Although we'd still like to know exactly how these mystery bytes are used by the various Windows OSs, their meaning is no longer a mystery! Rather than looking for answers on the Net, we simply did some tests on our own hard drives. In a short time, we came up with all the data needed to remove the mystery. Most people think the same six bytes are always written to everyone's hard disks at these locations. Definitely not true!
We purposely displayed a string
of ZERO-bytes in the code shown above, because that's how these bytes are
hard coded in all the FDISK.EXE utilities for Win 95B, 98, 98SE and Me.
As a matter of fact, if you use the FDISK from one of these OSs
with the /MBR switch on any drive, all of its "mystery
bytes" will be overwritten with zeros!
The FDISK program never writes
anything but zeros to these locations. So, what does
change these bytes? The Windows OS itself changes the last four
of these six bytes whenever they are all zeros! Most
likely some routine buried deep inside an obscure .DLL file does the checking.
If you can identify it, please let us know! So,
an intelligent technician that needs to copy the same Win9x/Me drive contents
to many physical drives, would be sure to start with an image copy that
has all zeros in these six bytes!
After discovering this, a first guess was that these bytes might be used during
the initial OS setup to let Windows know if it was ever booted up for the first
time. But it seemed really
odd that it would keep looking at these bytes every single boot-up if that
were its only function! At some point during the booting of the Windows
OS, it looks at these six bytes on each drive, and if they are all zeros,
it changes the last four bytes to reflect the MBR's drive number
and the current time when these bytes were written:
|
Byte: DCh
|
Bytes: DDh through
DFh
|
|
Physical
Drive Number
|
Time
when bytes were written to the MBR
|
| 80h = First Hard Disk |
Hours,
Minutes and Seconds in
Reverse order
|
| 81h = Second HD, etc. |
36
09 17 => 5:09:36 pm
|
NOTE: The Drive Number in
byte DCh only reflects where it was located when the OS
wrote that byte to the drive. You
can have any number of drives with an 80h in byte DCh of their
MBRs, and that in itself will not cause a problem!
We know that byte DCh is a Physical drive
number, because zeroing-out bytes DAh through
DFh in the MBR of a second drive connected
at the same time (which by the way had an 80h in byte DCh after Windows
booted up!), caused them to be changed to: 00 00
81 52 22 06 at 6:22 am the morning we tested it. Furthermore,
we can also state with certainty that the byte at DAh MUST ALWAYS BE 00 hex because given the
chance, these Windows OSs will also change bytes DCh through DFh
of any Standard MBR that might
exist on a connected hard disk as well... and the 00 in
DAh is the 'end of message' marker for the Standard MBR's last error
message. So any change to that byte would cause its MBR code to continue displaying
bytes until it finally found a zero byte!
At first, you might think that an OS which overwrites code in any MBR sector
might lead to some serious problems in Boot Manager software. But a bit of reflection
will soon show that it'd be highly unlikely that any MBR code (or data for that
matter) would ever place a string of six zero bytes at this particular
location. After our initial discovery, we became interested in trying
to find some reliable information on why Microsoft did this; not only
what we could observe, but to know exactly how these bytes
were intended to be used by these Windows OSs. If
you know for sure what their intended purpose is supposed to be, you can
write to me using this online form; no email
program required. But please read this note first:
[ NOTE: These bytes have nothing to do with how Windows determines if it
was improperly shut down! The Dirty Shut Down flag is located in the
first sector of the FAT ( File Allocation Table);
because you need such a flag for each Volume! This page describes: The
Usage and Location of the Shut Down Flag. Furthermore, this is part of the
Windows 9x OS; it has nothing to do with a Windows NT S/N of some kind.
NT Serial Numbers are located at offsets 1B8h through 1BBh. ]
The following are
comments sent in by readers who had problems because of this timestamp,
or already knew about it.
Silas writes (slightly edited): "I
once did maintenance work on a program which did raw disk copying
for backup purposes. The previous programmer must have encountered
this problem, because the Windows 95/98 version of the product had code
in it that incremented the mystery byte's timestamp
area when doing the disk copy.
However, there were two scenarios where you could get two disks in the system
with the same value in that field. One was a setup with dual boot of NT and
95/98, and the disk copy done with the NT version of the product, which did
not increment the bytes (until I added that). If you chose to
boot into the 95/98 installation from the NT menu, you'd have this exact problem
The other way you could get into this situation was by having two backup
disks. Remember, that field was only incremented, not randomized. So if
you did the disk copy to both backup disks, each of them would have the same
driveID/timestamp number. Much fun followed. I have thankfully forgotten
the details."
Earlier, Ron had written to me, saying my MBR pages were the only useful thing
he'd found on the Net after doing a drive copy and running into the problems
listed above. He added: "We
have since confirmed the same results on a second Win 98 box. We simply
matched the timestamp on both drives and rebooted. The problems
showed up in Device Manager as before. We then changed one digit in the
timestamp on the second drive, rebooted and the problems went away! Both Win
98 boxes behaved the same way. Nothing bad happened, they just showed
errors in Device Manager, and the CD drive wouldn't work,
until we made the timestamps in the two MBRs non-identical. The
drives don't need to be physically the same, just those 4 bytes and, I assume,
the MBR code. The partition tables were very different!
" [Read
that again. It's possible to have this problem with drives that were
never copied!]
"Our Win95 box blue-screened and did something to
the chipset drivers, so they had to be re-installed (don't want to do that again!).
What could this timestamp possibly be for! What possible use for a
timestamp that doesn't include a date, and is never changed unless it is zeroed-out?!
"
After that, Ron mentioned there's a 1 in 86,400 chance of accidentally matching two drives that weren't copies, just created on different days. I'd say the chances were a lot less for most companies, since they often keep the same business hours and could easily have someone doing new installs and then 'backup' copies at almost the same time each day. Sooner or later some technician will connect two drives having the same mystery bytes to the same computer! What indeed was Microsoft thinking?!
Ron recently (September 2, 2004) commented that these OSs don't "seem to care if the 'timestamps' are valid, but if they match it assumes the IDE is not working correctly." His tests described in the following comments may bear directly on how Microsoft uses these bytes:
"The
BSOD [Blue Screen] that I got in Windows 95 and the Device Manager
in Windows 98 both referred to compatibility mode. So I searched for
that and found a couple of MS-KB articles that say in essence: "to
troubleshoot compatibility mode problems, first remove the NOIDE Registry
entry."
Well, since I have a set of batch files that will save/restore the Registry,
I got brave and matched my time stamps again. A reboot got me a BSOD,
so I did a hardware reset, booted into a command prompt and restored the MBR
and the Registry. From there I booted into Windows and, after waiting for ScanDisk
to run, everything came up normally. That convinced me the 'timestamp' is used
to detect a problem in the IDE.
[Ron's] explanation/guess:
If the OS sees the same 'timestamp' on two drives during a boot, it assumes
that it is seeing a ghost image of a single drive because of a problem
in the IDE. So it puts NOIDE in the Registry and uses compatibility
mode drivers. I guess Windows 98 're-tries' the IDE on each boot so the
NOIDE [can be] removed by the OS when it [no longer] sees identical time
stamps.
More testing might be needed to prove it, but I'm convinced, unless I see evidence
to disprove it. "
This appears to be as good an explanation as any. Wouldn't it be wonderful if Microsoft just came right out and told us the truth about such things! If the source code was open to all, we'd at least be able to look for the answers.
People obviously lost interest in this
page after the many changes to Windows™ over decades, but one of our readers finally pointed
out that Microsoft did provide a "partial description of the meaning [of these bytes] in
KB article 192606 (or the file: MBtFAQ)." Since "Q192606" is difficult to find these
days, I'll quote the most relevant portion here:
"During its real-mode initialization, IOS
[Note that IOS here stands for Input/Output Subsystem; it's not the iOS term commonly
referred to today] builds an INT 13h device map. It builds this map by reading the MBR of each
valid INT 13h device. If the first word at the end of the boot code in the MBR is zero, IOS will store
the MBR signature for the device and its INT 13h unit [drive] number. The last possible byte of boot
code in the MBR is considered to be at offset D8h. Therefore the word that it checks for to be 0
is at offset DAh in the MBR. The MBR signature is at offset DCh. If the MBR
signature is zero, IOS will try to write a new non-zero MBR signature to the device's MBR that is built
from the current time (hour, minutes, seconds) and the device's INT 13h unit number. If the attempt
to write the new signature fails or the first word after the boot code is non-zero, IOS will instead
store a checksum of the MBR and the INT 13h unit number, rather than the MBR signature.
Subsequently, during the IDE port driver's device inquiry phase the port driver will attempt to read
the MBR itself by submitting an IOR_READ command to IOS (bypassing INT 13h). If the MBR is successfully
read, it will then try to match the MBR signature or checksum for the device with an entry in IOS's map
of INT 13h devices. If a match is found, the port driver will store the INT 13h unit number in the DCB,
along with the device's apparent geometry (as returned by INT 13h, function 8h, Get Drive Parameters).
The actual geometry for the device (as reflected in the FDPT) will also be copied into the DCB at this
point. If the attempt to find a matching entry in IOS's INT 13h device map fails for a device on the
primary IDE controller, the port driver will fail to load and the device will be accessed via
RMM."
MBtFAQ (8 JAN 1998, ©Microsoft); "The Windows 9x Master Boot
Record," Microsoft Windows 9x Device Driver Developer Support Team (OEM/IHV), page 3.
Updated: September 4, 2004 (2004.09.04).
Last Update: January 8, 2022 (2022.01.08); finally added Microsoft reference to these bytes!
You can reply to us here.
The Starman's Free Tools Page
MBR
and Boot Records Index The Starman's Realm Index