The Windows 7 boot sequence looked like this:
BOOTMGR Takes the Stage (as of Vista)
If Windows XP was the moment Windows became a truly independent operating system, Windows 7 was the moment Microsoft modernized the entire startup process.
At first glance the boot process looks similar to Windows XP. The system still starts with POST, the BIOS still finds the disk, and the operating system still ends up loading NTOSKRNL.EXE. Under the hood, however, Microsoft replaced some of the most important startup components.
The biggest change is immediately visible:
- NTLDR has been replaced with the BOOTMGR
- BOOT.INI has been replaced with the BCD Store
- NTDETECT.COM has been removed
- WINLOAD.EXE and WINRESUME.EXE (or WINLOAD.EFI and WINRESUME.EFI on UEFI systems) have been introduced
BIOS vs UEFI: Two Roads to the Same Destination
One of the most interesting aspects of Windows 7 is that it sits right at the crossroads between two generations of firmware. Depending on the hardware platform, Windows 7 can start using either the traditional BIOS startup process or the newer UEFI model. While both paths ultimately lead to the Windows kernel, the route taken to get there is quite different.
As shown in the diagram, both startup sequences begin in a familiar way. After the system successfully completes the Power-On Self-Test (POST), the firmware takes control and prepares to locate a bootable Windows installation. This is where the paths begin to diverge.
In a BIOS-based system, the firmware locates the Master Boot Record (MBR) on the disk and executes its boot code. From that point onward, ownership of the startup process is effectively transferred to Windows. The BIOS has fulfilled its purpose and steps aside, allowing the boot sector, BOOTMGR, and ultimately WINLOAD.EXE to continue the startup sequence.
The UEFI path follows a different philosophy. Rather than searching for boot code in the MBR, UEFI reads boot entries stored in firmware and directly launches the Windows Boot Manager from the EFI System Partition (ESP). Instead of discovering boot code, UEFI already knows where Microsoft’s boot files are located and launches them directly.
The distinction may seem subtle, but architecturally it is significant. BIOS operates using a classic handoff model: it finds executable code and then relinquishes control. UEFI remains aware of the boot environment through its firmware configuration and EFI variables, maintaining a much closer relationship with the operating system startup process.
This architectural shift would become increasingly important in later versions of Windows. Technologies such as Secure Boot, Measured Boot, and modern hardware trust chains all depend on capabilities that simply do not exist in the traditional BIOS model.
Regardless of which path is taken, both startup sequences eventually converge at the same destination. Whether launched through BOOTMGR and WINLOAD.EXE in a BIOS environment or through BOOTMGFW.EFI and WINLOAD.EFI in a UEFI environment, the goal remains unchanged: loading NTOSKRNL.EXE, the heart of the Windows operating system.
After locating a bootable disk, the BIOS loads the Master Boot Record (MBR) into memory and executes its boot code. Although the MBR occupies only the first 512 bytes of the disk, it plays a crucial role in the startup sequence. This is also the moment when ownership of the boot process changes hands. The BIOS has found the startup code it was looking for and effectively steps aside, leaving the remainder of the process to Windows.
The MBR locates the active partition and transfers execution to the partition’s boot sector. Unlike Windows XP, where the boot sector searched for NTLDR, the Windows 7 boot sector now looks for BOOTMGR, the Windows Boot Manager.
BOOTMGR represents one of the most important architectural changes introduced in Windows Vista and carried forward into Windows 7. Acting as the central coordinator of the startup sequence, BOOTMGR is responsible for reading boot configuration data, displaying operating system selection menus, supporting recovery environments, and launching the appropriate Windows loader.
Another major improvement is the introduction of the Boot Configuration Data (BCD) Store. Windows XP relied on BOOT.INI, a simple text file that administrators could easily edit with Notepad. While simple, BOOT.INI was also remarkably easy to break. Windows 7 replaces this approach with a structured configuration database, providing greater flexibility, improved security, and better support for advanced boot scenarios. Noteworthy, the BCD Store is not plain text 💜 it’s a binary database that is typically viewed and managed using BCDEDIT.EXE.
Windows Boot Manager
——————–
identifier {bootmgr}
device partition=C:
description Windows Boot Manager
locale en-US
default {current}
displayorder {current}
timeout 30
Windows Boot Loader
——————-
identifier {current}
device partition=C:
path \Windows\system32\winload.exe
description Windows 7
locale en-US
osdevice partition=C:
systemroot \Windows
nx OptIn
The move from BOOT.INI to BCD wasn’t just a cosmetic change. Microsoft moved from a single editable text file to a structured object-based configuration store, allowing support for:
- Multiple Windows installations
- Recovery environments
- UEFI boot entries
- Resume from hibernation (winresume.exe or .efi)
- BitLocker integration
- Advanced boot options
Or, in true Feminine Nerd fashion:
BOOT.INI was a notebook with directions.
BCD became a database with a GPS, a backup route, and an emergency recovery plan. 💜🤓
Once BOOTMGR has read the BCD Store and determined which operating system should be started, it launches WINLOAD.EXE. This component serves as the operating system loader and is responsible for preparing Windows for execution. WINLOAD loads the Windows kernel (NTOSKRNL.EXE), the Hardware Abstraction Layer (HAL.DLL), boot-critical drivers, and portions of the system registry required during startup.
At this stage, NTOSKRNL.EXE finally takes control. As the heart of the Windows operating system, the kernel manages processes, memory, hardware communication, security enforcement, interrupt handling, and countless other low-level functions that keep the operating system running.
With the kernel active, Windows starts SMSS.EXE, the Session Manager Subsystem. This component initializes system sessions, creates environment variables, and launches several critical operating system processes. It effectively prepares the environment that the rest of Windows depends on.
The next stop is WINLOGON.EXE, which is responsible for user logon, security policy enforcement, and session creation. By the time the logon screen appears, WINLOGON is already hard at work preparing the user experience.
Finally, Explorer.exe is launched, the desktop appears, and Windows 7 is fully operational.
One particularly important addition in Windows 7 is support for hibernation and resume operations through WINRESUME.EXE. Rather than performing a complete boot sequence every time, Windows can restore a previously saved memory state and return the system to exactly where it was before hibernation. On UEFI systems, these components evolve into WINLOAD.EFI and WINRESUME.EFI, laying the groundwork for the modern boot architecture used by Windows 10 and Windows 11.
In many ways, Windows XP taught Windows how to stand on its own, while Windows 7 taught Windows how to evolve. By replacing legacy startup components with BOOTMGR, the BCD Store, and the Windows Loader architecture, Microsoft created a boot platform designed for the future. Technologies such as BitLocker and UEFI found a natural home in this new architecture, while future Windows releases would continue building on these foundations with Secure Boot, Virtualization-Based Security, and the hardware-rooted trust model that eventually became a cornerstone of Windows 11.
Yours truly,
Lady Itris | The Feminine Nerd 💜