Sponsored by:

Fully Managed Technology Services

 

An Examination of the
NTFS Volume Boot Record

Of Microsoft® Windows™ 2000
(NT5.0) and Windows™ XP (NT5.1)
[ It's also found in SPCMDCON.SYS and
other System files; see Introduction below. ]


Web Presentation and Text are Copyright©2004, 2007, 2009, 2012
and 2015 by Daniel B. Sedory
NOT to be reproduced in any form without Permission of the Author !

 

Note: It's always best to confirm whatever you read on the Net with your own experiments. During the long span of Windows XP, Microsoft changed the code for these Boot Record sectors once before:
http://support.microsoft.com/kb/320397 (Windows may not start and you may receive an "NTLDR is missing" error message if Windows is not up-to-date and there are too many files in the root folder) in which you'll find out why Microsoft had to change the Boot Record code for Windows 2000 with Service Pack 4 (SP4) and Windows XP with Service Pack 2 (SP2). Note: Installing Windows XP SP2 or Windows 2000 SP4, will not correct this issue on existing volumes. To update the boot code on existing volumes, you must either obtain and run the utility "bcupdate2.exe" (MD5 hash value is: "2e2ed06d9ae54c8d959a534a83284705") from Microsoft, or manually change the boot code using an updated copy. The service pack updates will only write the new boot code for new volumes; they cannot correct old volumes.

You can contact us here if you have a specific question about this page.





Introduction

The NTFS Boot "Record" is 16 sectors long!
(It's Boot "Sector" is only 1 sector.)

The term "Boot Record" is not a good description when used of the first sector of a floppy diskette or USB drive or any other type of external (to a PC) storage media when it's only used to access data files on that media. It is, however, an historical reference to the fact that PC's in the past were quite often, if not solely, boot into an OS from a floppy diskette. But those early "Boot Records" also required the necessary boot files (e.g., "ibmbio.com" and "ibmdos.com"; and the code in them) to be present in order to load their file systems (which would have been DOS back then) into Memory before reading or writing files from or to the diskette (or later on, a hard drive).

It should be noted that the only data that was actually required to be present in those early Boot Records for a 'data' diskette (or other type of FAT storage media) was the BIOS Parameter Block (see BPB below). And today is no different: You can zero-out all but the first sector of an NTFS $Boot record's 16 sectors, and even remove all of the remaining “Bootstrap Code” from its Boot Sector without ever keeping an OS from accessing that volume's files! All of that code is only used if an OS must be boot-up from within that volume. And if one examines a number of floppy disks from the past, eventually a "Boot Record" containing only a BPB and a very short string of code that displays something similar to: 'This is not a bootable diskette.' would be found. Why? So floppy diskette manufacturers could never be accused of copying any IBM or Microsoft code.



The NTFS Boot Record's “Backup Sector”

The Win 2000/XP OSs make a "backup" of each NTFS volume's Boot Record which they store in the very last sector of its partition!
[ Note: I said "partition" not volume. This is why an NTFS partition's Total Sectors count in the MBR/EBR's Partition Table is always 1 sector more than the "Total Sectors (in Volume)" count found in its Boot Record. Although the words partition (primary) and volume are often thought of as being synonymous (we may even use them as such here!), this shows they are not always the same. ]

Brian Carrier, the developer of The Sleuth Kit ( TSK) appeared to have discovered this for himself when writing about the 'backup copy' of the boot sector on page 220 of his work, File System Forensic Analysis (2005; Addison Wesley). But instead of stating as we did here, that the Volume is 1 sector less than the size of its Partition, it seems to us he mistakenly chalked this up to something he called 'the NTFS file system size' being smaller than the NTFS Volume: "My survey of Windows NT 4.0, 2000, and XP volumes had the backup copy in the last sector. I found that the total number of sectors in the file system was less than the total number of sectors in the volume, so the backup copy of the boot sector did not have to be allocated to a specific file." As usual, you must be careful when researching for technical facts; we cannot guarantee everything will always be correct at The Starman's Realm either.


 




The NTFS Bios Parameter Block



        0  1  2  3  4  5  6  7  8  9  A  B  C  D  E  F

 000B                                   00 02 08 00 00              .....
 0010  00 00 00 00 00 F8 00 00 3F 00 FF 00 3F 00 00 00   ........?...?...
 0020  00 00 00 00 80 00 80 00 AE 39 D7 00 00 00 00 00   .........9......
 0030  04 00 00 00 00 00 00 00 8D EF 00 00 00 00 00 00   ................
 0040  F6 00 00 00 01 00 00 00 FC 5D E1 A4 99 E1 A4 B4   .........]......
 0050  00 00 00 00                                       .....
Offset Length Hex
Numbers
Decimal
Equiv. or
Meaning
Description
0Bh Word 0200 512  Sector Size (in bytes)
Reference     " If maximum compatibility is desired, only the value 512 should be used. There is a lot of FAT code in the world that is basically "hard wired" to 512 bytes per sector and doesn't bother to check this field to make sure it is 512. [So]...values [other than 512] are not recommended."
0Dh Byte 08 8  Sectors per Cluster; so
 Cluster size here = 4 KiB
Reference

" Number of sectors per allocation unit. This value must be a power of 2 that is greater than 0. Values of 1, 2, 4, 8 are quite common."
    [
I've seen a value of 4 ( for a Windows XP partition of less than 2GB ), but a value of 8 ( for Windows 2000 and XP ) is probably the most common. ]

0Eh Byte 00 0   Reserved Byte;
  We've never seen anything but zero here for NTFS (has anyone's BPB On Disk ever had anything else here?).
NOTE: Under Windows 7 / 8, After loading into Memory, 7C0Eh is set to the DRIVE NUMBER (usually 80h) by the MBR here, then used by both the VBR (here and following) and the BOOTMGR Loader code (when reusing the VBR code as well as: here) when reading sectors from the Boot Drive.

However, under Windows XP/2000: After loading into Memory, this location (7C0Eh) is used to store how many sectors of the Boot Record are to be read into Memory; it begins with a value of 16 (decimal) and counts down to zero. (See line: 7C6C below.)
0Fh Byte/(Word) 00 0   Reserved Byte/(Word);
  We've never seen anything but zero here for NTFS (has anyone's BPB On Disk ever had anything else here?).
NOTE: Under Windows 7 / 8, After loading into Memory, 7C0Fh - 7C10h (so WORD) are used by the VBR to first calculate and then store (see lines 7CAF and 7CB2):
Bytes per Sector divided by 16; which is then used in an interesting way to read the remaining 15 sectors of the VBR Area into Memory at lines 7CBB through 7CD4 and the Subroutine at 7C0:011D. The stored value of Bytes per Sector divided by 16 (which is often 20h, since 512 / 16 = 32) is also used in a similar way by the Win 7 BOOTMGR Loader code at 7D59.
10h Byte 00 N/A  Must always be zero for NTFS volumes (originally the number of  FATs for a FAT partition).
11h 2 Bytes 0000 N/A  Must always be zero for NTFS volumes (originally the Max. Root Directory Entries under FAT12/16).
13h 2 Bytes 0000 N/A  Most often set to zero, but not used by NTFS (orig. used for the FAT12/16 small sectors count; must be zero for FAT32).
15h Byte F8 "Fixed Disk"    Media Descriptor ID.
( Win 2000/XP do not use it, but other code might so it's set to F8).
16h 2 Bytes 0000 N/A  Must be set to zero for NTFS volumes (originally for FAT12/16 "Sectors per FAT" value).
18h Word 003F 63  Sectors per Track
1Ah Word 00FF 255  Number of Heads (Sides)
1Ch Double Word 0000003F 63  Number of "Hidden
 Sectors" (Cyl=0 Head=0)
Under Vista and 7 00000800 2048   (Cyl=0 Head=20h Sect=21h)
Reference

   Note: Under Windows™ Vista and Windows™ 7, the number of "Hidden" or Reserved Sectors for the first partition has been increased to 2048 (0x800) rather than 63 (0x3F).

   " Count of hidden sectors preceding the partition that contains this [NTFS] volume. This field is generally only relevant for media visible on interrupt 0x13. This field should always be zero on media that are not partitioned. Exactly what value is appropriate is operating system specific."  [ Although I'm not exactly sure what all the implications are of this quote from Microsoft, I can tell you that this value is definitely used while reading the boot sectors into Memory! See line: 7CCF in the Subroutine below. This value is supposed to be the number of physical sectors on the disk preceding the first sector of this volume; it's obvious why the first entry in a disk's partition table has a 63 here, but it will also be a 63 for each Logical volume on a disk since each Logical volume in an Extended Partition is preceded by its own Extended MBR. So, this value varies only for an NTFS partition that is a 2nd, 3rd or 4th Primary Partition.
    Note: If you see a value of 29 (1D hex) in this field, it's most likely because the volume was created on a Dynamic Disk.]

Is it safe to change this value for booting a Windows OS? & Can Win 2000/XP boot from an Extended partition?

20h 4 Bytes 00000000 N/A  Most often set to zero, but not used by NTFS (originally used for the Total Number of Sectors in a FAT32 volume).
After loading into Memory ( and carrying out the instructions in the subroutine at offsets 7C7B and following ), offset 7C20h is used to store the Total Number of Sectors on the Disk Drive we're trying to boot from; see line: 7CA5 for reference. This value is used later by the NTFS Bootstrap (or NTLDR Loader) code in Memory location D0D4. [Only true for disk drives (or image files) smaller than about 8.42 GB.]
24h 4 Bytes 80008000 First byte:
80h
is the drive number !
An NTFS OS always
fills these bytes with:
"80008000"
According to most documentation, this area is not supposed to be used by NTFS, but after examining the code in the Boot Record, it seems clear that the first byte of these four bytes is used  to set the drive number! (See offsets: 7C7B and 7CAF).
28h Long
Long
Word

(8 Bytes)
00000000
00D739AE
14,105,006
Total Sectors
( in the Volume )

Read following note!
  As we mentioned above, this value will always be 1 sector less than the total number
  of sectors in the volume's partition table entry, because the NTFS "Backup
  Boot Sector" is not considered part of the NTFS Volume.
30h Long
Long
Word

(8 Bytes)
00000000
00000004

00000000
000C0000
4
(Win 2000)

786,432
(for XP*)
Starting Cluster Number for the $MFT File in this partition (starting Logical Sector is this value times the Sectors per Cluster value. E.g., 4 x 8 = 32 )
 *All Windows XP and later Windows operating systems place the $MFT file at LCN
  0x0C0000 (786,432). See our Introduction to NTFS, Layouts, Era 2.
38h Long
Long
Word

(8 Bytes)
00000000
0000EF8D
61,325*  Starting Cluster Number for the $MFTMirr File in the center of this partition.
 *All Windows 7 and later operating systems place the $MFTMirr file immediately
  after the Volume Boot Record. At LCN 0x02 (Logical Sector 16 for 4 KiB clusters).
  See our Introduction to NTFS, Layouts, Era 3, for more on this change.
40h Signed
(+/-)
Byte
F6 -10 =>
1024 bytes
 Clusters (or bytes) per
 File Record Segment
 (FRS).

The Number of Clusters for each MFT record, which can be a negative number when the cluster size (8 sectors in this case) is larger than the MFT File Record size! The value F6 hex (which appears as 246 decimal in many utility programs) is in fact a negative 10 (-10 decimal). However, you obviously can not have a negative number of clusters!  So, a negative number here is instead an indicator  that the record length for any MFT File Record is: 2 to the power of the absolute value of this negative number; which of course, results in a positive number.  For our example values above, that would be: 2 ^ (|-10|) = 2 ^ 10 = 1024 bytes!  This number agrees perfectly with the MFT Record sizes we've seen on real disks. Microsoft® finally documented this in their Windows XP Professional Resource Kit, Table 28-17, stating: "If this number is positive (up to 0x7F), it represents Clusters per MFT record. If the number is negative (0x80 to 0xFF), the size of the File Record is 2 raised to the absolute value of this number." Prior to this, we had already reached the similar outcome as expressed in note (c) on page 49 of the Linux-NTFS Project's ntfsdoc.pdf file.

41h 3 Bytes 000000 N/A  Most often set to zero, but unused by NTFS.
44h Signed
(+/-)
Byte
01 1 Clusters per
Index Buffer.

 Thus, the size of each Index Buffer; used to allocate space for NTFS structures such as Directories.

45h 3 Bytes 000000 N/A  Most often set to zero, but unused by NTFS.
48h Long
Long
Word

(8 Bytes)
B4A4E199
A4E15DFC
- NTFS
Volume Serial
Number
.
 

 NOTE: When you use the DIR command and others inside of a CMD/DOS-box under Windows 2000/XP, it will show a Volume Serial Number composed of only the last four bytes of this Long Long Word! Example:
     C:\>dir
     Volume in drive C is Win2000
     Volume Serial Number is A4E1-5DFC
Obviously, we must look into this further to find out how all these bytes are being used by the Operating System!

 It is interesting to note how the (3rd and 4th) and (6th and 7th) bytes repeat here!
 Do you have a Serial Number where these two sets of bytes are not the same?

50h Double 
Word
00000000 0  Not Used by NTFS
 We've never seen anything except all zero bytes in this field, but some call this field a 'Checksum'.


The NTFS “$Boot” Sectors

   As stated above, it's been our experience that both the Windows 2000 and Windows XP Boot Record (a single sector) plus the “Bootstrap Code” consists of seven sectors beginning with the one we're examining in detail on this page. But the code itself shows that all 16 sectors of the NTFS Boot Record "Area" are loaded into Memory. In NTFS file system terminology, the first 16 sectors of an NTFS partition are known as the $Boot (which occupies Clusters 0 through 1 on most systems; those with 8-sector/4 KB clusters).

The Second sector always begins with the 16 Hex bytes:

05 00 4E 00 54 00 4C 00 44 00 52 00 04 00 24 00
            N   .   T   .   L   .   D   .   R   .             $  . 

which is mostly Unicode for the 5 characters: NTLDR; the preceding "05 00" means the following Unicode string is 5 characters long. These are followed by "04 00" and Unicode for a $ sign. The next line begins with: "49 00 33 00 30 00" (we have observed these same 10 hex bytes; which taken together are seen in ASCII as: "..$.I.3.0.", in some NTFS Metadata File Records).

The Third through Sixth sectors don't really have any outstanding features, and the Seventh sector ends with 138 zero bytes (300 in the original code prior to Windows™ XP SP2). On a newly formatted NTFS volume, the $Boot is immediately followed by the index to the $MFT (Master File Table) which usually contains a number of sectors full of FF bytes (often part of $Bitmap) before you can find something which is humanly intelligible! Most NTFS volumes will also contain some Metadata (system files) in the middle of the partition; such as, $MFTMirr (a backup copy of the first four $MFT records) and $LogFile (which is the NTFS journal and can be many megabytes in size). NOTE: On volumes that have had many files added and deleted, and especially those which have come close to running out of space, the Master File Table may have been relocated.

 




An Examination of the Assembly Code


Location of Error Messages and
Message Offsets in Memory


       0  1  2  3  4  5  6  7  8  9  A  B  C  D  E  F
7D83           0D 0A 41 20 64 69 73 6B 20 72 65 61 64      ..A disk read
7D90  20 65 72 72 6F 72 20 6F 63 63 75 72 72 65 64 00    error occurred.
7DA0  0D 0A 4E 54 4C 44 52 20 69 73 20 6D 69 73 73 69   ..NTLDR is missi
7DB0  6E 67 00 0D 0A 4E 54 4C 44 52 20 69 73 20 63 6F   ng...NTLDR is co
7DC0  6D 70 72 65 73 73 65 64 00 0D 0A 50 72 65 73 73   mpressed...Press
7DD0  20 43 74 72 6C 2B 41 6C 74 2B 44 65 6C 20 74 6F    Ctrl+Alt+Del to
7DE0  20 72 65 73 74 61 72 74 0D 0A 00 00 00 00 00 00    restart........
7DF0  00 00 00 00 00 00 00 00 83 A0 B3 C9 00 00 55 AA   ..............U.

Free Boot Record Tools

If you're unable to find a copy of Power Quest's Partition Info tool (see further below; since Symantec stopped distributing it!), or even if you are, we'd also recommend obtaining the latest free DEMO version of WinHex (version 18.1 at this time). Run it as Administrator in Windows 7 or later. Extract all files to a temporary folder in your Downloads area, then run the setup program (defaults to C:\Program Files (x86)\WinHex as the install directory) Open your C: Logical drive, and with the cursor at the very first byte, open "View" menu and choose "Template Manager". Then select the "Boot Sector NTFS" item and click on "Apply!" You should see a pop-up similar to this one (it will take some time getting used to where its 'Templates' and other tools are located in the menus):

See our Free Tools page for a link to PQ's Partition Info Tools (Power Quest's Partition Information viewer will list all the fields in an NTFS Bios Parameter Block). The following is a display similar to what you'll see using PQ's Partition Info program for NT (after clicking on the "Boot Record" button):

Entries 1, 2 and 23 are in the first sector of the Boot Record, but are not part of the BPB or Extended BPB. All of the red colored boxes show entries which must be zero in order for this to be an NTFS Boot Record. Note the eight-byte Serial Number in the pink box. Although documentation from Microsoft indicates that the data in the 'white' boxes (5, 8, 14 and 15) is unused by NTFS systems, we've seen only zero bytes in boxes 5, 8 and 14, and the '80 00 80 00' entry in box 15. Please refer to our detailed notes above on the BPB entries; especially for boxes 15 and 19.

 

First Published: June 6, 2007 (2007.06.06).
Updated: 29 JAN 2009 (29.01.2009); 1 FEB 2009 (01.02.2009); 1 MAR 2009 (01.03.2009); 8 MAR 2009 (08.03.2009); 16 AUG 2009 (16.08.2009); 6 MAR 2010 (06.03.2010); 26 AUG 2012 (26.08.2012); 2 SEP 2012 (02.09.2012); 20 FEB 2015 (20.02.2015); 7 JUL 2015 (07.07.2015); 10 JUL 2015 (10.07.2015); 12 JUL 2015 (12.07.2015); 19 JUL 2015 (19.07.2015) - Corrected some misktakes; 30 AUG 2015 (30.08.2015); 10 SEP 2015 (10.09.2015); 16 SEP 2015 (16.09.2015) - more notes related to use of BPB copies in Memory by the Windows 7 VBR and BOOTMGR Loader code; 5 MAR 2018 (05.03.2018).
Last Update: April 5, 2018 (05.04.2018).


You can write to us using this: contact page (opens in a new window).

MBR and Boot Records Index

The Starman's Realm Index Page