The Windows NT Runtime Environment explained: Part 1

Sequence of Execution

[1] The Boot Process

There are two varieties of general-purpose computing platforms on the market: those that support the traditional BIOS interface, and those that support the more recent and featureful UEFI interface. Both are standardized firmware interfaces that provide hardware (board + peripheral) abstraction to the operating system-specific (or external third-party) bootloader during the initial stages of the bootup process. Microsoft does a good job of hiding away the nuances of the BIOS-based or UEFI-based bootup process in Windows Setup and the day-to-day Windows user experience, so the fact that there are significant differences between the two isn’t so obvious. [1]

Figure 1
Figure 1. All three stages of the Windows bootloader are firmware dependant therefore Windows installation process and boot up process will vary depending on whether the platform is BIOS-compliant or UEFI-compliant. Grey box indicates generic (non OS specific) bootloader, Blue indicates OS-specific bootloader, Orange represents the actual OS kernel.

Installation/Boot up on BIOS-compliant systems

The Windows installation process will typically format the mass storage device to one or more partitions supporting either the FAT32 or NTFS file system.* Information about the arrangement of these partitions and the file system they are associated with will be written to the very first sector of the storage medium, this is referred to as the boot sector, i.e. the fixed location where the BIOS will look to find (a) information about the medium and it’s volumes, and (b) code to execute next. In the boot sector, the BIOS will expect to find an entry in either the traditional MBR (Master Boot Record) format or of the more recent GPT (GUID Partition Table) format.** [2]

* A mass storage device may be split into many partitions. A formatted partition is referred to as a ‘physical volume’ – each physical volume will have a Volume Boot Record (VBR) written to its boot sector (the first sector) during the formatting process. An unformatted partition i.e. a partition that does not support any file system, is not considered a ‘physical volume’. See:

** At the time of writing, there is only one default Windows Stage 1 bootloader for BIOS-compliant systems – and that is MBR-based; there is no support for GPT. Since a MBR is limited to a maximum volume size of 2TB, it is likely to be superseded by GPT within a few years. Meanwhile, certain hacks can be used to allow Windows to boot from a GPT medium.

Stage 1 (MBR)

After power up, when ready, the BIOS will execute the MBR’s boot code (also referred to as the ‘master boot code’) which is in essence a generic (non-operating system specific) ‘stage 1’ or ‘primary’ bootloader. Upon control being handed over to the master boot code, it functions to locate the system partition (also referred to as the active partition) so that it may load this partition’s boot code from its Volume Boot Record (VBR).

Stage 2 (VBR -> Bootmgr)

Only one volume may be flagged as the system partition in a MBR; the system partition flag indicates to the MBR’s boot code which volume’s VBR to read to find the operating-system specific ‘stage 2’ or ‘secondary’ bootloader. Note that this volume is also generally flagged as hidden (viz. System Reserved) so that it may not be seen or modified once the operating system has booted up.

In the default case of Windows Setup, a distinct 100MB NTFS partition is created and installed with Windows Boot Manager (Bootmgr) and Boot Configuration Database (BCD) files; this volume is referred to as the ‘System Volume’. The System Volume is the partition which has both system/active flag and hidden flag checked; due to the first flag, the MBR knows to hand over execution to the boot code in the System Volume’s VBR. This boot code is written during Windows Setup and its function is to (1) locate Bootmgr from the volume’s root directory, (2) load it to memory, and (3) execute/hand over control to this secondary bootloader. [3] [4, pp. 502-512] [5]

Note: Though the Volume Boot Record is written at the boot sector (viz. first sector) of all volumes during the partitioning process (to store information about the volume), not all VBRs will consist of usable boot code. Also, unlike boot code featured in the MBR, the BIOS does not execute boot code from any of the VBRs directly. [6]

For a BIOS-compliant platform, there are two executable files that constitute Bootmgr, and Bootmgr.exe. This is due to the fact that the processor will be running in 16-bit real-mode from the time the BIOS executes the master boot code; there is no translation of virtual-to-physical memory addresses in 16-bit real-mode, and the .com executables that run in this mode rely solely upon the first 1MB of physical memory. For this reason, is executed first and is responsible for switching the processor over to 32-bit protected-mode where full 32-bits of physical memory becomes accessible before Bootmgr.exe is executed. Bootmgr.exe has access to It is Bootmgr.exe which initializes page tables and finally enables virtual-to-physical memory address translation. [4, p. 504] [7]

Installation/Boot up on UEFI-compliant systems

The UEFI firmware is designed with the expectation that a UEFI-compliant boot manager is present in the Non-Volatile RAM (NVRAM); in the case of Windows, this is actually a distinct UEFI-compliant version of the Windows Boot Manager (Bootmgfw.efi) which is written to the NVRAM by Windows setup along with complementary BCD content. The UEFI-compliant Windows Boot Manager relies on the UEFI API and services instead of BIOS interrupts and is automatically loaded by the UEFI firmware without the need to read the boot sector of the storage medium or the relevant volume – in fact, though UEFI-MBR boot up is possible, UEFI firmware is primarily designed to support boot up from GPT mediums (UEFI-GPT boot). [4, pp. 512-513]

Note: In UEFI systems, all applications run in the native CPU mode with virtual-to-physical memory address translation/paging enabled. Images of executable UEFI API-based code (UEFI applications) generally end in the .efi file extension and can be executed whilst the UEFI “boot services” are active. UEFI boot services have to be terminated by a specific function call via the API by one of the UEFI applications – this is generally the boot manager once it has finished doing its job.

Figure 2
Figure 2. Executable code (images) involved in the Windows boot up process, and the CPU mode of execution.


[1], “Some basics of MBR v/s GPT and BIOS v/s UEFI,” [Online].
[Accessed 4 March 2018].
[2] lifewire, “What is a Boot Sector?,” [Online].
[Accessed 4 March 2018].
[3] Microsoft, “TechNet: Master Boot Record,” [Online].
[Accessed 4 March 2018].
[4] M. Russinovich, D. A. Solomon and A. Ionescu, Windows Internals, Part 2 (Sixth Edition), Washington: Microsoft Press, 2012.
[5] The Starman, “The Starman’s Realm: Details of many versions of MBR and VBR,” 30 January 2018. [Online].
[Accessed 4 March 2018].
[6] lifewire, “What is a Volume Boot Record?,” [Online].
[Accessed 4 March 2018].
[7] “Bucaro TecHelp: The Windows Bootup Process,” [Online].
[Accessed 5 March 2018].