1. The Power-On Self-Test (POST)

The journey begins the instant you press the power button. Electrical current flows from the power supply unit to the motherboard and all connected components. The first software to execute is not Windows itself, but the firmware stored on a ROM chip—traditionally the BIOS (Basic Input/Output System) or, on modern PCs, the UEFI (Unified Extensible Firmware Interface). This firmware immediately performs a critical diagnostic routine known as the Power-On Self-Test (POST). During POST, the firmware checks for the presence and basic functionality of essential hardware, including the CPU, main system memory (RAM), and the graphics adapter.

You might hear a single short beep if everything passes, or a series of beeps (beep codes) to indicate specific hardware failures, such as a missing graphics card or faulty RAM. The firmware also initializes low-level system devices, setting up the motherboard chipset and allocating system resources like I/O ports and interrupt requests (IRQs). If the POST fails, the boot process halts, often with an error message on screen or a sequence of beeps; if it succeeds, the firmware moves to locate a bootable device.

2. Firmware (BIOS/UEFI) Initialization and Boot Device Selection

After POST completes successfully, the firmware enumerates all attached storage devices—hard drives, SSDs, USB drives, optical discs, and network adapters. It then consults its internally stored boot order priority list, which you can typically configure in the firmware setup menu. The firmware scans each device in sequence, looking for a special data structure called a boot signature. In legacy BIOS systems, this signature is a two-byte value (0x55, 0xAA) in the first sector (sector 0) of the storage device, marking the Master Boot Record (MBR). In modern UEFI systems, the firmware looks for a FAT32-formatted EFI System Partition (ESP) containing boot loader files with the .efi extension.

Once the firmware identifies the first valid boot device, it loads the initial bootstrap code from that device into RAM. On an MBR-based BIOS system, this is the first 440 bytes of the MBR (the boot code); on a UEFI system, it loads the EFI boot loader, typically located at \EFI\Microsoft\Boot\bootmgfw.efi. At this point, the firmware hands over control of the system to this newly loaded code, and the hardware-specific phase ends.

3. Windows Boot Manager (Bootmgr) Activation

The code loaded from the boot device is the Windows Boot Manager, a small but crucial program named bootmgr on the system partition. The Boot Manager’s primary job is to read the Boot Configuration Data (BCD) store, a database that replaces the old boot.ini file from Windows XP and earlier. The BCD store contains all boot-time configuration parameters, including a list of installed Windows operating systems, their physical locations on disk, timeout values for the boot menu, and any special options like loading a debugger or booting into Safe Mode.

On a typical single-OS system with no user intervention, the Boot Manager proceeds automatically. If multiple OSes are present or if you press a special key (like F8), Bootmgr presents a text-based or graphical boot menu. When you select an entry (or when the timeout expires), Bootmgr loads the appropriate OS loader. For Windows Vista and later, this loader is winload.exe (on BIOS systems) or winload.efi (on UEFI systems). Bootmgr then transfers execution to the loader, which resides on the system volume (often a separate small partition) but will load the main Windows kernel from the boot volume (where Windows is installed).

4. Operating System Loader (Winload) Phase

winload.exe (or .efi) is the first truly Windows-specific component to run. It begins by loading essential system registry hives into memory, starting with the SYSTEM hive, which contains information about device drivers and system services. Using the registry data, winload loads the kernel of Windows (ntoskrnl.exe) and the Hardware Abstraction Layer (hal.dll). The HAL is a critical piece that abstracts away differences in motherboard and chipset designs, allowing the Windows kernel to present a consistent interface to higher-level software.

Next, winload loads all boot-start device drivers—those marked as necessary for the system to start. These include drivers for the disk controller, file system (e.g., NTFS), and any other device required to read the main Windows volume. Crucially, winload also reads a special registry value called the “SafeBoot” key; if it finds this key, it enters Safe Mode, loading only a minimal set of drivers. At this point, winload initializes the kernel and HAL, passing them a data structure that describes the loaded drivers and the state of the system. Control then passes to the kernel, and winload’s job is done.

5. Kernel Initialization and System Session Start

The Windows kernel (ntoskrnl.exe) takes over and begins its own initialization phase, often called “Phase 0.” The kernel sets up the system’s internal data structures—the object manager, the process manager, the memory manager, and the I/O manager. It creates the first system process (System Idle Process, PID 0) and the System process (PID 4), which will host most kernel-mode system threads. The kernel then calls the HAL to complete hardware initialization, including interrupt controllers and timers. Once the core kernel is running, it starts the Session Manager Subsystem (smss.exe), the first user-mode process. Smss is responsible for creating the user environment: it opens the remaining registry hives (like SOFTWARE, SAM, SECURITY, and DEFAULT), creates system environment variables, and launches the Win32 subsystem (csrss.exe), which provides the Windows API and console windows. Smss also starts wininit.exe, the Windows Initialization process, which in turn launches the Service Control Manager (services.exe) and the Local Security Authority Subsystem (lsass.exe). At this stage, the system is still running in a pre-login state, but the core of Windows is fully operational.

6. Logon and Startup Applications

The final phase begins when wininit.exe starts the Logon User Interface process (LogonUI.exe). This is the familiar welcome screen or the classic Ctrl+Alt+Delete login prompt. When you enter your credentials, LogonUI passes them to lsass.exe, which authenticates you against the SAM (Security Account Manager) database or a domain controller. Upon successful authentication, Windows creates a new user session and loads the user’s registry hive (NTUSER.DAT). The system then launches userinit.exe, which runs the Shell (usually explorer.exe) — the Windows desktop, taskbar, and Start menu. Finally, Windows processes the “Run” registry keys (both in HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run and HKCU\...) and the Startup folder in the Start menu, launching any applications configured to start automatically. Notification area (system tray) icons appear, background services finish loading, and the desktop becomes interactive. Only at this point is the boot process truly complete, and you can begin using your Windows PC normally.