Navigate to the folder Windows x64 sources or P: Windows x32 sources and drag&drop the file gatherosstate.exe to the desktop. Run the file afterwards. It creates GenuineTicket.xml on the desktop. This file is needed so copy it to a USB drive or other location. Run a clean install of Windows 10 afterwards on the system. Import answer file to USB media. To include an autounattend.xml file on a Windows 10 bootable media, use these steps: Open File Explorer. Navigate to the autounattend.xml file location. As soon as you boot up your system or log on to your user account, Windows 10 automatically runs all programs or files listed in the startup folder.Up until Windows 8, you could view and change these applications directly from the Start menu. Mount the ISO file and connect a certified USB drive to your Windows 10 computer. Click Windows button and go to Control Panel Windows To Go. In the Create a Windows To Go workspace window, choose the certified USB drive onto which you want to install Windows 10 and click “ Next ”. If you are booting up - then it is in the right place. That may be the C: partition - not necessarily. It depends on your installation history. If you look in Disk Management, the partition labelled System, Active will be the location of bootmgr. OS: Vista x64 / 7 X64.
[Also embedded in vdsutil.dll,
winsetup.dlland various other
System files]
Web Presentation and Text are Copyright©2011, 2015 by Daniel B. Sedory
NOT to be reproduced in any form without Permission of the Author !
This page examines the Windows 7, 8/8.1 or 10 MBR code; it's the same exact bytes for all of these OS versions. We'll not only examine some interesting facts about this MBR sector's code and display each assembly instruction; as we did with our previous MBR/VBR pages, but also discuss some differences in how these OSs install on your computers. Whenever you install Windows 7/8/10 to a hard disk, even one with an existing MBR, its first sector may be overwritten with the Windows 7/8/10 MBR code. (Note: If necessary, it will also change the Volume Boot Record of an existing Active Windows boot OS; usually found in the first partition of a PC's first hard disk.) This code is also installed on blankhard drives when using Windows 7/8/10's Disk Management utility. NOTE: On our Windows 7 RC Install DVD, all 512 bytes of this MBR (including the zero-bytes in the partition table) were found in bootbootsect.exe, sourcesupgdriver.dll and sourceswinsetup.dll; see below for more files containing this code. Like all other MBRs presented in this series, this MBR code could still be used to boot any OS on some x86 PCs if it meets the conditions listed here*. |
- Data Strings
The MBR created by Windows Vista Installs or Disk Management Utility
The
MBR created by Windows 2000/XP/2003 Installs or Disk Management UtilityThe MBR created by Windows 95B/98/98SE and ME's FDISK
An Examination of the Standard MBR created by MS-DOS FDISK
And Microsoft OS Volume Boot Records:
A Comparison of Windows™ Vista, 7, 8 and 10 VBR Code
An Examination of the Windows 8 / 10 OS Volume Boot Record
An Examination of the
Boot Log File Location Windows 10
Windows 7 OS Volume Boot RecordAn Examination of the Windows Vista OS Volume Boot Record
An Examination of the Windows 2000/XP OS Boot Record (NTFS)An Examination of the Windows 95B/98/98SE/Me OS Boot Record (MSWIN4.1)
Confused? Send us an email if you have a specific question about the MBR or any Boot Records..
| IMPORTANT: One of the first things that any PC user should do after setting up a new hard disk (or creating a new partition with a utility such as Partition Magic) is to make a copy of its MBR; especially if you have more than one partition on the disk! Why? If you accidentally overwrite this sector, or are infected by a Boot sector virus, you may never be able to access some or even all of your disk again! Even the most expensive HD utility might not correctlyrestore the Partition Table of a multi-partitioned hard disk! Some advice: Save the Partition Table data on floppy disks or write it down on paper(!); it does no good to have the data you need to access your HD on the un-accessible HD itself! There are many ways you can do this.. See our MBR Tools Page. Any good Disk Editor will allow you to manually enter data you've written down under an easy to use Partition Table View, or you can use a utility program, such as 'MbrFix' (for Win NT/2K, XP, 2003, PE, Vista & 7; even 64-bit versions!) to save the binary data to a file on say a thumb drive, and later on restore the MBR from that saved file. |
____________
| * | NOTE:Even though we're examining code created by a Microsoft Operating System, this MBR can also be used to start the boot process for any operating system's Boot Record on an x86-CPU based (PC) computer as long as that OS is: 1) on the Primary Master hard drive, 2) set to be the only Active partition and 3) it has a boot loader in the first sector of that partition. Most Linux OS distributions can install LILO or GRUB as a Boot Record rather than in the MBR and following sectors, so even the oldest MBR by Microsoft could still be used to boot Linux; as long as its boot code was at or under the 1024 cylinder limit that is. Furthermore, the processor must be an 80386or later in order to use the Win7 MBR code, since it includes the 'Operand-Size Prefix' (66h which can only be executed by an 80386 or later CPU. See Code, location 0659). When certain 16-bit assembly instructions, such as PUSHA (PUSH All registers onto the Stack), are prefixed by the byte 0x66, it forces that instruction to act as if it were running in 32-bit mode. So PUSHA effectively becomes a PUSHAD instruction, pushing all the 32-bit registers onto the Stack. Windows 7 can also boot multiple OSs using its console (Command Prompt) program BCDEDIT (Boot Configuration Data Editor; 'Sets properties in boot database to control boot loading') and BOOTMGR files, so for systems with multiple OSs, this would be a far more practical approach than changing the Active partition in the MBR each time you want to boot up a different OS. If you intend to install a Linux OS, it would probably be best to do so after installing Win7, then use the GRUB boot manager as the first boot code to load the others from. By the way, BCDEDIT (like any program that affects system files) must first have the Command Prompt window opened in Administrator mode (right-click on the icon or program name and choose to open it as Administrator). Running BCDEDIT without any switches will display a few facts about BOOTMGR and the Windows Boot Loader (another program first created for Vista); which is the Windows 7 OS Loader: Windowssystem32winload.exe. |
Like Vista, if you install Windows 7/8/10 on a hard disk with no existing partitions, the first partition will start at Absolute Sector 2048 (counting from zero; Sector 0 is where the MBR is located). This is an offset of exactly 1 Binary Megabyte (2048 * 512 = 1,048,576 bytes) into the disk. In hexadecimal, this is an offset of 100,000 hex (100000h = 1 MiB). The main reason Microsoft gave for doing this is found in their article, KB-923332; with the number of sectors given only in hex: 0x800 = 2048 and 0x3F = 63.
Basically, since the starting offset for many disks, including the majority of Windows XP OS installs, was 63 (an odd number), they chose a starting offset that should give an even number of sectors for any large-sector drive manufacturers produce. It would cause performance issues on large-sector drives if there were a 'misalignment' between the size of a physical sector and the partition(s). Western Digital and other drive manufacturers have been producing such hard disks for some time now; calling them Advanced Formatdrives, with physical sectors 8 times the size of a 512-byte sector (8 * 512 = 4096 bytes). But even with new disks using 4 KiB-sized sectors, the Win7 offset of 1 MiB still gives an equivalent offset of 256 such sectors (1048576/4096 or 2048/8). IfMicrosoft had picked an offset of any even number of sectors divisible by the size of a new large-sector, wouldn't that have solved any 'misalignment' issue? So why not simply pick an offset of 32, 64 or even 128 KiB? Did Microsoft really want to be sure you could continue to use your Win7 OS on drives with even much larger sector sizes?[Actually, their reasoning was quite clear, but not widely shared: 'The size of the advanced format sector was chosen because it matches the x86 page size and the NTFS cluster size.' (Windows Internals, 6th Edition, 2012, Part 2, page 126)] The point for technicians or forensics investigators working with Windows 7 OS hard disks (on either current or future models) being that they now have a much larger sized reserved space (1,048,576 bytes vs. 32,256 bytes) they must deal with.
(Note: Do not confuse this generally unused reserved space with the new Windows 7 'System Reserved' partition described below.)
However, unlike Vista, Microsoft added a further complication for those who must deal with software designed to make image copies of Windows 7 hard disks: For each standard install of Windows 7/8, the install DVD defaults to creating two partitions!(NOTE: This is not true if you use an Upgrade DVD where Win 7/8 must be installed onto a disk with an existing Windows partition; whether you choose to keep your data or overwrite the whole partition, its files will only be installed into the OS partition.) Bluestacks version 1 mac.
It's also important to note: Some 'name brand' computer manufacturers insist on adding their own special partition(s), either before or after the OS partition(s); or both! For example, DELL PCs often include a small FAT16 formatted partition at the very beginning of the disk drive (type 0xDE), but 'name brand' PCs may also include a partition for restoring the entire OS partition to the state it was in when shipped from the factory.
Note: For the standard Windows 7 install, to a disk that has no existing partitions, the first partition will always be set to a size of only 100 MiB and labeled 'System Reserved'. [Note: For a Windows 8 OS install, the first partition is set to a size of 350 MiB (i.e., 716,800 sectors).] Users may also be confused by the fact that although this partition is set as the Active partition, it's often hidden from them due to having no drive letter assigned to it; in which case, you need to use Disk Management (see Figure 3 below; enter: diskmgmt into the 'Search programs and files' box to open it) or some other utility to see the PC's partitions. Otherwise, if it is assigned a drive letter, it will be volume E:, since the DVD drive has traditionally been assigned to D:. So here's a case where under Microsoft Windows, a simple clean OS install not only has two partitions, but also has the drive letter C: assigned to the second partitionon the disk; not the first.
So be aware of this when examining the MBR of a Win7/8/10 OS disk.
The typical (default) Windows 7 OS partition table (with its 100 MiB System partition as the first entry) will appear as:
where 'nnnnnnnn' simply represents that partition's actual capacity in sectors for the main OS partition. The 'RELATIVE' offset of the first partition is 2048 sectors; instead of the usual 63. For technicians, it may take some time getting used to seeing both a Starting CHS triple of 0,32,33 (instead 0,1,1) and an Ending CHS triple of 12,223,19 (for disks with 255 heads) rather than the 1023,254,63 we had become so familiar with seeing on many user's computers. The whole first entry above will appear as follows in a disk editor (showing the actual hex bytes rather than decimal values in the table above): '80 20 21 00 07 DF 13 0C00 08 00 0000 20 03 00' (see below), where the Head and Sector values are 20h and 21h (in Cylinder 00h) for the Starting Sector. And DFh, 13h and 0Ch for the Head, Sector and Cylinder values of the Ending Sector.
NOTE: For a Laptop/Notebook PC, the BIOS may use a different pseudo-CHS geometry translation for its 'Head' value. For example, if a Windows 7 PC's BIOS decides its hard disk should have only 240 Heads (instead of 255), the values you will find in your Partition Table's first entry should be: '80 20 21 00 07 A3 13 0D00 08 00 0000 20 03 00' for an Ending CHS Triple of 13,163,19 which still results in a total of 204800 (32,000 hex) sectors (a capacity of 100 MiB) for the first partition.
The typical (default) Windows 8 OS partition table (with its 350 MiB System partition as the first entry) will appear as:
where 'nnnnnnnn' simply represents that partition's actual capacity in sectors for the main OS partition. The 'RELATIVE' offset of the first partition is 2048 sectors; instead of the usual 63. For technicians, it may take some time getting used to seeing both a Starting CHS triple of 0,32,33 (instead 0,1,1) and an Ending CHS triple of 44,190,18 (for disks with 255 heads) rather than the 1023,254,63 we had become so familiar with seeing on many user's computers. The whole first entry above will appear as follows in a disk editor (showing the actual hex bytes rather than decimal values in the table above): '80 20 21 00 07 BE 12 2C00 08 00 0000 F0 0A 00', where the Head and Sector values are 20h and 21h (in Cylinder 00h) for the Starting Sector. And BEh, 12h and 2Ch for the Head, Sector and Cylinder values of the Ending Sector.
NOTE: Just as we stated above for Windows 7, the BIOS of a Laptop/Notebook PC may use a different pseudo-CHS geometry translation for its 'Head' value with a Windows 8 OS install.
Quick answer: Because the Windows 8/8.1 System Reserved Partition needs the room! With Windows 8, they decided to install the Recovery Environment right on the physical drive; of which the Winre.wim file (found in this drive's RecoveryWindowsRE folder) is 225 MiB, so uses most of the additional space. Here we see that 75% of that 350 MiB is in use:
Figure 3. Shows the Properties window of a Windows 8.1 System Reserved partition shortly after being installed.
Figure 4. Disk Management view of small 25 GB Win 7 OS drive. The terms Active and Boot are no longer the same.
Prior to Windows 7, we often used the terms Active or Bootable as synonyms when discussing the partition that the Master Boot Record (MBR) code would load and execute in Memory from its Boot Sector, ifit found the first byte of its Partition Table entry to be 80h. However, when Microsoft programmer(s) created a more elaborate booting scheme, which could place the BOOTMGR code and BCD database in a separate partition from that of the Windows 7 OS, they decided to refer to the partition that contains the operating system as the Boot partition and the one that execution is initially passed to as the Active partition.
Windows 7 does have the same useful feature related to boot records and booting which first appeared under Vista:
Its Disk Management utility has the ability to both shrink and expand partitions; similar to what Partition Magic could do for previous Windows versions. We may present a detailed page about this in the future, but note: All studies so far, have led us to the conclusion that no matter how much empty space you have remaining within your last partition, this utility will allow you to shrink it to only about 50% (just half of) the capacity of the physical disk drive! Example: If the full capacity of a 320 GB disk drive was partitioned when installing the Windows 7 OS, this utility allows you to shrink the main OS partition to only about 160 GB; even if there is only 4 or 5 GB, or any other small number of GB, of that partition in use! And this will not change even if you run the utility again on the shrunk partition!
This page examines the MBR code most likely to be found in a Microsoft® Windows 7 OS installation. Win7's various editions, such as Home Premium or Ultimate, all contain the same exact MBR code. When partitioning a disk without an MBR sector, this code will be written to Cylinder 0, Head 0, Sector 1 (that's Absolute or LBA Sector 0) of the Disk Drive by various OS routines, such as Win7's Disk Management utility. But even in the case of a drive that already has a functioning Windows MBR, the Win7 install DVD will overwrite the existing MBR code of the boot disk as part of the process. [As with Windows XP and Vista, Windows 7 itself will write data to an existing MBR sector (e.g., of a slave drive connected to the system), when necessary (compare Disk Signaturecomments for the Windows XP MBR).]
This link shows where copies of the MBR can be found for a Windows 8.1 ISO file or DVD, or the files on its installed OS drive.
For our Windows 7 install, all the bytes of Win7's MBR code were also contained inside the following files (listed by location, alphabetically; with offset to first byte of the code). In each case, there will be a full 512 bytes that comprise the MBR code (the location for the NT Disk Signature and the 64-byte Partition Table are all zero-filled, the last two bytes being 55h followed by AAh):
1.C:WindowsSystem32RelPost.exe [Offset: 12CD0h]
('Windows Diagnosis and Recovery'; File version: '6.1.7600.16385 (win7_rtm.090713-1255)'; 182,784 bytes; Modification Date: '07/14/2009 1:14 AM'). There's also a second copy here: C:Windowswinsxsx86_microsoft-windows-reliability-postboot_31bf3856ad364e35_6.1.7600.16385_none_4d97265566a66f7eRelPost.exe.
2.C:WindowsSystem32vdsutil.dll [Offset: 22CA8h]
('Virtual Disk Service Utility Library'; File version: '6.1.7600.16385 (win7_rtm.090713-1255)'; 151,040 bytes; Modification Date: '07/14/2009 1:16 AM'). There's also a second copy here: C:WindowswinsxsBackupx86_microsoft-windows-
31bf3856ad364e35_6.1.7600.16385_none_6ac128c35c0231aa_vdsutil.dll_f2ef43cf.
3.C:WindowsSystem32vssapi.dll [Offset: E20D0h]
('Volume Shadow Copy Requestor/Writer Services API DLL'; File version: '6.1.7600.16385 (win7_rtm.090713-1255)'; 1,123,328 bytes; Modification Date: '07/14/2009 1:16 AM').
There's also a second copy here: C:WindowswinsxsBackupx86_microsoft-windows-vssapi_31bf3856ad364e35_6.1.7600.16385_none_d4bd3473e31540bf_vssapi.dll_51f72c64.
4.C:WindowsSystem32VSSVC.exe [Offset: E1BA8h]
('Volume Shadow Copy Service'; File version: '6.1.7600.16385 (win7_rtm.090713-1255)'; 1,025,536 bytes; Modification Date: '07/14/2009 1:15 AM').
There's also a second copy here: C:Windowswinsxsx86_microsoft-windows-vssservice_31bf3856ad364e35_6.1.7600.16385_none_5aa3249a792b0938VSSVC.exe
5.C:WindowsSystem32oobewinsetup.dll [Offset: 184220h]
('Windows System Setup'; File version: '6.1.7600.16385 (win7_rtm.090713-1255)'; 1,794,048 bytes; Modification Date: '07/14/2009 1:16 AM').
There's also a second copy here: C:Windowswinsxsx86_microsoft-windows-setup-component_31bf3856ad364e35_6.1.7600.16385_none_3202d4720e95de08winsetup.dll.
Using the file 'C:WindowsSystem32vdsutil.dll' of '151,040 bytes' with a Modification Date of 'Tuesday, July 14, 2009 01:16:17 AM' as an example, the MBR in this file was found at offsets 22CA8h through 22EA7h (of which only 80 of its 512 bytes are shown here):
Figure 5. Showing the bytes '63 7B 9A'which are part of the Win7 MBR's code.
The following is a disk editor view of how the bytes of this MBR are stored on a hard disk's first sector; that's Absolute (or Physical) Sector 0, or CHS 0,0,1. (See Examination of the Code below to find out where this data ends up in Memory when it's executed.)
The first 355 bytes (000h through 162h) of this 512-byte sector are executable code and the next 80 bytes (163h through 1B2h) contain error messages. The last 66 bytes of the sector contain the 64-bytePartition Table (1BEh through 1FDh); data in the Table will depend upon the size, structure and file systems on the hard disk. [See our pages on Partition Tables, for notes on how to interpret the data in a particular disk's partition table.] The sector ends with the Word-sizedsignature ID of AA55h (sometimes called the MBR's Magic number). Note: On PCs using an Intel (or x86 compatible) CPU, hex Words are stored with the Low-byte first and the High-byte last.
The programmers of this MBR had to use almost every bit of space available, because all 110 bytes of the code shown between brackets in Figure 6 (offsets C6h through 126h and offsets 156h through 162h) are either related to, or directly involved in, determining if the hardware supports TPM (Trusted Platform Module) version 1.2; which can then be used to provide extra functionality for the Microsoft Windows BitLocker™ Drive Encryption. The letters 'TCPA' at offsets EFh through F2h are not coincidental; they stand for 'Trusted Computing Platform Alliance' and are part of the code which tests for the existence of a TPM chip (see comments below).
The remaining 11 bytes (between the Error Messages and the Partition Table; 1B3h through 1BDh) begin with only two zero-bytes as padding; followed by the three bytes (63 7B 9A) at 1B5h through 1B7h for a Win7 install with English messages (see below for all the details about this). If you stop the installation before any NT-type Operating Systems starts to boot-up, the next four bytes may remain as they were; usually zero-bytes. But once Windows has begun running, it will write a Disk Signature in the MBR. These four bytes from offsets 1B8h through 1BBh are called the Windows Disk Signatureor NT Drive Serial Number. See here for details on Disk Signature use in the Windows Registry!
The three bytes at offsets 1B5h through 1B7h ('63 7B 9A') are used by Microsoft Windows for a very specific purpose; for English versions of Windows 7, you'll always see these same Hex values ('63 7B 9A') in the MBR. They're used by the MBR code to display Error Messages on your screen. But for those using Windows 7 in a different language, their MBRs may have different values in the second and third bytes depending upon how many characters are in each of the three messages. If you look in the code section below, starting at offset 0731h (instruction: 'MOV AL,[07B7]'), you'll see these three bytes are used to reference the offset in Memory of the first byte of each Error Message that can be displayed on screen at boot up: 0763h, 077Bh and 079Ah. Since the code portion above the messages will always be the same, the first offset (0763h) will never change no matter what languages (and string lengths) are used.
Now that you know what the bytes at offsets 1B5h through 1B7h are used for, you could change these error messages to display whatever you wish (as long as they all fit into the space between offsets 163h and 1B4h) by counting their character lengths and using a disk editor on the MBR sector to make the appropriate changes.
After executing the POST (Power-On Self Test), the BIOS loads this sector into memory at 0000:7C00 (as it does any MBR) then transfers control to this code.
But this code must first copy itself into another area of Memory. This is necessary because the code must also load the Boot Sector of the Active Partition into the same area of Memory that it occupies just after being loaded! Unlike the Windows 2000/XP MBR, this code copies all 512 of its bytes to the new location, starting at: 0000:0600. Only the first three instructions are the same as the Windows 2000/XP MBR, so keep your eyes sharp if you're comparing the two.
You can learn a great deal about the instructions used here by obtaining the x86 Opcode Windows Help file and Ralf Brown's Interrupt List from our Intro to Assembly page.
NOTE: We've begun some new pages called Pathways through the Windows 7 MBR which graphically display all registers (and include detailed comments) for each step of the MBR code as it is being executed. These pages refer to the Bochs Enhanced Debugger as the tool chosen to provide these illustrative steps (We would appreciate any email comments or questions you might have concerning these pages). |
Here's a Listing of the disassembled code (; with comments) after first being loaded into Memory at 0000:7C00 by the BIOS (all Memory locations listed below are in Segment 0000:). If you see an asterisk (*) next to an instruction, it means that MS-DEBUG can not disassemble that code.
Note: If you compare this code to that of the Windows Vista MBR, you'll find there's only a slight variation due to changing two jump instructions from 32-bit to 16-bit at Memory locations 06A2 and 06C9; allowing for the insertion of a CLI instruction immediately after it, and an STI instruction at 06E1. Lastly, they also decided to add a HLT (Halt) instruction at 0753. Due to these changes, which added 12 more bytes to the Windows 7 MBR code, various offset bytes also needed to be adjusted. (The first byte difference from the Vista MBR code occurs at Memory location 062B, where the location to jump to changes from 073D to 073B. The next adjustment doesn't occur until 069E; just a few bytes before all the same code bytes become shifted by 1 to 4 bytes compared to Vista's MBR.)
Just like most of the MBR code we've studied here, if you were to load a copy of the Win7 MBR with an empty partition table (or one that has no Active Boot Flag for any of its entries) as a *.bin file into MS-DEBUG (e.g., debug mbr.bin), move all the code to offset 0x0600 (-m 100 2ff 600), set the IP to 0x061C (-rip then 61c) and run it (-g; Note: Although MS-DEBUG cannot step through the code at 0x0629 since it doesn't understand instructions beyond the 8086 through 8088 processors, when you enter 'g' it will simply pass all the code it encounters to Win XP/Vista/Win7's NTVDM program; under which you are actually running DEBUG, without trying to disassemble it), you would then see the following error message on your screen:
Note: Although this was possible under Windows 7 RC, the retail Windows 7 OS did not
include the MS-DEBUG program! We recommend installing VMWare Player and creating
your own Windows XP (or even MS-DOS) virtual computer to run MS-DEBUG inside of.
Because NTVDM was never programmed to handle an 18h Interrupt any further than displaying this message. If you Ignore it, the NTVDM program might warn you one more time about accessing the hard disk, but it will eventually freeze or go off into oblivion if you Ignore it again; and you'll have to use Task Manager to close the DOS Prompt window gracefully.
The following code is missing some comments, but all the instructions are here for you to study.
Location of EnglishError Messagesand
Message Offsetsin Memory
Location of SampleDisk Signature
andPartition Tablein Memory
This is how it would be seen in a disk editor that can interpret Partition Table data: |
Three views of PT Calc showing: 1) The CHS values for a Vista or Windows 7 OS install's first partition (at Absolute Sector 2048) for either a typical desktop or notebook disk, and 2) How disks which are assigned a different number of Heads in their BIOS (255 and 240 are shown) can have different CHS values for exactly the same sector (206848).
Note:
The sector must have a 'signature' of 0xAA55. It's located at the very end of the partition table (remember that low-bytes appear first and high-bytes last). The BIOS checks for the signature and if it's not there, you'll see an error message such as 'Operating System not found.' (The message being dependent upon the BIOS code; most PhoenixBIOS, including those modified for VMWare, display this one. But under BOCHS, you would see: 'Boot failed: not a bootable disk' and on a PC using Award BIOS 6.00PG, it actually displays: DISK BOOT FAILURE, INSERT SYSTEM DISK AND PRESS ENTER.)
Windows 10 Uefi Boot File Location
First Published: 12 MAR 2011 (12.03.11).Updated: 22 MAR 2011 (22.03.2011); 8 MAY 2011 (08.05.2011); 14 MAY 2011 (14.05.2011); 28 MAR 2012 (28.03.2012); 18 APR 2012 (18.04.2012); 12 MAY 2013 (12.05.2013); 29 JUN 2013 (29.06.2013); 11 JUL 2013 (11.07.2013); 17 FEB 2015 (17.02.2015); 1 MAY 2015 (01.05.2015); 1 JUN 2015 (01.06.2015); 21 JUN 2015 (21.06.2015); 10 AUG 2015 (10.09.2015); 16 MAR 2018 (16.03.2018).
Last Update:3 May 2018. (03.05.2018)
You can write to me using this: online reply form. (It opens in a new window.)
The Starman's FREE TOOLS Page
MBR and Boot Records Index
The Starman's Realm Index Page
Windows 10 Boot Manager File Location
Windows 10 Boot Logging File Location
The BCD Store file is usually located in the Boot folder of a Windows 7/8.1/10 OS's System Reserved partition; which in many cases will not even have a drive letter assigned to it. So if you really want to see where these system files are located, you'll first need to go into Disk Management and give that partition a drive letter. (Note: Some OS distributions, such as the 'Embedded Standard' editions, do not have a separate System Reserved partition.) Apart from possibly needing to add a drive letter, all system files are by default hidden from view, so you'll also need to change the Folder Settings to show hidden system files. But, since the BCD file is kept open by the OS, you wouldn't be able to open it to look at it anyway!However, you can use the BCDEDIT program to make a backup copyof the BCD file which you can then open with a hex editor (to see everything) or even NOTEPAD (to see all the readable characters). [Contents of a real BCD file are linked below.]
If you enter 'bcdedit' at a simple Command Prompt window, you'll probably see:
Because you need Administrator privileges to access the BCD file with BCDEDIT. So, be sure to run the Command Prompt using a RIGHT-CLICK and selecting: ('Run as administrator').
The following is what you would typically see when entering the command bcdedit all by itself:
Note that the Boot Manager program (bootmgr) is often located in a volume without a drive letter, such as in this example, but it could have one. If there were only one partition on the drive, then it would appear in the C: partition.
The following is a dump of a Windows™ 7/8 (or Vista) Administrator console (Command Prompt window) after entering 'help bcdedit' ('bcdedit /?' will give the same):
Note: What you see above is exactly how a Vista/Win7/8 display appears; and, yes, the word 'Command' in the last heading was spelled wrong by Microsoft, it should be plural (Commands) just like all the others. And if there really was only one, then the word 'control' should have had an 's' after it! This was still true for a Windows 7 SP1 install we examined, and even Windows 8.1. Is this a case of 'If it ain't broke, don't fix it!'? Apparently, the cost of qualifying a revised program outweighs this grammatical error.
And even though Windows™ 10 added six new commands (shown in white below), they doubled the same grammatical error (shown in red). Now it's incorrect for both of the last two command types:
BCD Editor EXAMPLES:
If you ask for help on the '/export' switch, you'll see:
So we tried the following and saw it was successful:
After examining this backup file in our Documents folder (using HxD), our first reaction was: 'Man, this thing appears to be full of all kinds of needless 'gunk'!' It even saves the path and filename to this backup file, inside the file itself!
Then we compared it to the original BCD file by making a copy of that file while the OS was offline (connected as a slave drive to a different OS), and found there were MANY differences! So, the 'backup copy' is not really a true copy. And the differences go well beyond simply changing the path name of its location.
So why is this file so 'cluttered' compared to the Windows XP boot.ini file? Its first 4 bytes are a big clue: 'regf'. Reason: The BCD file has the same format as a Windows Registry hive! (For example, the NTUSER.DAT file begins with the same 4 bytes.) And in fact, once a Windows Vista/7/8 OS has actually started booting-up, it loads the BCD file into the Windows Registry at: HKEY_LOCAL_MACHINEBCD00000000.
BOOTMGR Experiments:
What happens if we change the NT Disk Signature on a Windows 7 disk drive?
To test this, we used a disk editor to alter the bytes at offsets 0x1B8 through 0x1BB in the MBR (first sector of the disk drive) by simply adding 1 to each byte. If you attempt to boot a PC after doing that, you'll see the following BLACK error screen:
In previous Windows versions, the OS would still boot up this way; even though there was the possibility some program that used the Disk Signature could then have problems. Note: The same error message, with Status: code of 0xc000000e, will also be displayed if we change those NT Sig. bytes to all zeros! Only if you edit these bytes back to their original values will the PC boot-up again.
It's also possible to see such an error if your PC is somehow directed to start booting from a drive other than the normal boot drive, and the BCD Store on that drive points to the first drive, which will obviously contain a different Disk Sig. than what is stored in that drive's BCD. Most PC BIOS have a 'Boot Menu' (often accessible using the F12 key at boot-up) which temporarily makes whatever drive you select, be the first drive on the PC, so a Windows 7, 8.1 or 10 OS on that drive will not have this error! (Note: Unless you plan on alwayskeeping an original Windows OS drive anda new Windows OS drive both connected to your PC, you should never do a new OS install with any other drives connected to the PC!) Why? Because new Windows OS installs often make changes to a primary disk drive, even when installed to a secondary drive! Disconnect all but the disk drive you intend to install a new Win OS on, and in the future you will be able to boot-up the new drive all by itself (or using a Boot Menu key) without it depending upon some primary disk drive you decided to remove, or that has failed.
NOTE: The error shown above is a function of the bootmgr program! We know this, because the same error message will be displayed after altering the NT Disk Signature on a drive that has had its entire C: Volume (where the actual Windows OS resides) removed! So, the Boot Manager must check the NT Disk Signature before it even looks for the presence of the C: Volume.
But how does bootmgr know what those hex bytes should be?
Answer: After examining both our copy and the original BCD file, we found the NT Disk Signature there, in the same order as found in the MBR Sector, no less than 9 times. For our small test install of a new Windows 7 OS, this shows where those bytes occurred (highlighted with a pink background color); along with all the other data contained in a BCD Store file. Note: The Boot folder of your System Reserved partition will also contain a few LOG files: BCD.LOG, BCD.LOG1 and BCD.LOG2, but the numbered files are often empty. This LOG file is a copy of the BCD file, having the same location written inside it and all the general indications of a BCD Registry file, but about half its bytes may be different.
Have fun examining your own backup BCD copy.
Why is it so difficult to move the C: Volume under Windows 7 or later?
To clarify: Under most previous Windows installs, such as Windows 98, people who performed multi-booting or simply had many different partitions on their PCs often used a program called Partition Magic to shrink or even completely rearrange the layout of partitions on their disk drives. But attempting to change where the C: Volume begins under Windows 7 results in a similar BLACK screen error as above; including the same exact message: 'Info: The boot selection failed because a required device is inaccessible.' But with a different code: 'Status: 0xc0000225.'
[Note: This is true whether the correct location is specified in the Partition Table or not; same Status code will be shown in either case. In fact, we doubt that bootmgr even looks at the Partition Table, provided it can find the C: volume where it is supposed to be!]
This problem is similar to the one above (concerning the NT Disk Signature), but involves the exact sector location of the C: drive's partition.
So where in the BCD file, is the sector location of the Windows Boot Sector stored?
The reason for the question being: Although we can find our drive's NT Disk Signature in the BCD Store, we can not find a sector location for the C: drive! Before searching, we had thought only the BCD file would need to be updated if we moved the C: Volume. We knew how partitions are referenced in a Windows REGISTRY (see NTFS Disk Signature), but could not find any similar bytes; other than the 4 bytes of the NT Disk Sig., in our BCD file! So how does bootmgr know where the sector offset location of a C: drive should be, and prevent booting from an OS volume we simply moved and did not resize; even though the data in both the Partition Table and its Boot Sector (Hidden Sectors which give us sector offset to Boot Sector) have already been updated?
NOTE: All of the following is still under construction . . . mainly because we have yet to find a solution that allows one to effectively move where a Windows 7 OS's C: drive partition begins! After using a Microsoft install DVD to REPAIR such a drive, although it did allow us to boot-up that drive and use it, the repair did not change anything permanently! After attempting to boot-up the drive again, the same error message is displayed, no matter how many times we used the DVD to 'repair' the drive!!.
Could it be as simple as the OS already having accessed the REGISTRY; with much of the system already running in Memory, it then finds the offset stored there does not match the values in the Partition Table and/or Boot Sector, so it gives us essentially a false message, stating: 'The boot selection failed because a required device is inaccessible.'? Yet, the bootmgr program could only know that if it didfind and access the Registry.
Other Experiments:
2. We next carried out the following steps on a copy of our Windows 7 OS install in order to verify our theory about why Windows 7 does this:
A) Copy the hidden file bootmgr and various folders (including 'BootenUS' and 'BootFonts') from the 'System Reserved' partition to the root directory of the C: drive. Note: Five or six files must be 'skipped' when doing this, because the BCD Store (and associated files) will remain in use by the OS (preventing them from being copied)!
B) Create a copy of the BCD file in C:Boot by using this command (as Administrator): bcdedit /export C:BootBCD
C) Change the MBR Sector, so the main OS partition is the 'Active' partition.
After that we were able to boot-up the OS from only the C: drive. In order to prove this is true, we used HxD to zero-out the entry in the Partition Table for the System Reserved partition. (Note: The reason we did not use Windows to 'delete' the partition, is because that could have ruined being able to access it again in the future. By saving those hex bytes elsewhere and zero-filling the entry, we can simply enter those bytes in the table again, in order to restore and access the partition!) Upon rebooting and opening the Disk Management utility, one can graphically see this is true:
D) We shrank the size of this Volume (C:) to only 8 GB in order to run the next test below.
What about BOOTSTAT.DAT and BOOTSECT.BAK files?
E) shift the beginning of the C: drive to where the System Reserved partition had been, by correcting the data in both the Boot Sector (VBR) and the Partition Table; not to mention, actually moving the Boot Sector and its following Volume Boot Record sectors as well Cant download utorrent on windows 10.
Windows 10 Boot.ini File Location
First Published: 2004.
Updated: 18 APR 2012 (18.04.2012); 02 AUG 2015 (02.08.2015); 03 AUG 2015 (03.08.2015); 10 SEP 2015 (10.09.2015).
Last Update: 12 February 2020. (12.02.2020).
You can write to us using this: online reply form. (It opens in a new window.)
Free MBR/VBR TOOLS Page
Back to MBR and Volume Boot Records Index
The Starman's Realm Index Page