This content originally appeared on DEV Community and was authored by Anna Villarreal
Hello Everyone!
I’m on page fifteen-hundred-and-something in the Comptia A+ book I’ve been reading for some time. Yes, aiming for the certification. Interesting how, all the way in the back of the book we find the boot process. I would argue it belongs in the front of the book. But that’s besides the point. I realized I’ve been doing all this coding and editing, but I never took a second to understand how the whole process starts in further detail.
Did you ever slow down to think about how a computer actually turns on? It’s definitely something most people take for granted and do not think about until there is a problem. Let’s take a moment to appreciate the curious process of booting, step by step. Assuming we have a shiny new computer all built up just the way we expect it, the boot process for Windows follows.
Windows Boot
1. System self-checks and enumerates hardware. Each machine has a different startup routine called POST (Power-on-self-test). This POST test verifies the functionality of core components like CPU, memory, and peripherals. This is executed by the commands written to the motherboard.
2. On a BIOS-based system, the BIOS loads the MBR (Master Boot Record), which is located in the first sector (sector 0) of the hard drive. The MBR contains a small bootloader and a partition table. It is loaded into memory, and then the bootloader in the MBR locates the active (bootable) partition and loads its boot sector to continue the boot process.
* On a UEFI-based system, the firmware does not use the MBR. Instead, UEFI reads the EFI System Partition (ESP) which is a FAT32-formatted partition, and directly loads a .efi bootloader executable (like bootmgfw.efi or grubx64.efi) to memory. *
3. MBR determines the filesystem and loads BOOTMGR. Information in the boot sector allows the system to locate the system partition and to find and load into memory the file located there.
4. BOOTMGR reads the boot configuration data (BCD) to get a list of boot options for the next step. The BCD contains multi-boot information or options on how the boot process should continue.
5. BOOTMGR then executes winload.exe. This switches the system from real mode to protected mode and enables paging. Protected mode enables the system to address all the available physical memory.
6. If windows is returning from hibernation, winresume.exe is responsible for reading the hiberfl.sys file into memory and passes control to the kernel after the file is loaded.
7. The OS kernel loads the executive subsystems. Yay! What’s that? Executive subsystems are software components that parse the registry for configuration information and start needed services and drivers.
8. The HKEY_LOCAL_MACHINE\SYSTEM Registry hive and device drivers are loaded. The drivers that load at this time serve as boot drivers, using an initial value called a start value.
9. Control is passed to the kernel, which initializes loaded drivers. The kernel loads the Session Manager, which then loads the windows subsystem and completes the boot process!
10. Winlogon.exe then loads. At this point, you see the login screen.
Phew! Dija breathe?
Key Notes for Troubleshooting
- The hardware starts with POST
- The software starts with BOOTMGR
- You can use boot logging to find issues
Let’s Examine a Windows Boot Driver!
Boot drivers must be loaded early in the boot process, before the Windows kernel fully loads. This includes disk, file system, and chipset drivers.
Since boot drivers are crucial for the initial startup of a system, they are typically written in languages that compile directly to machine code, like C, C++, or assembly. So then what does a boot driver look like, you may wonder. I did for sure, so here is a simple example of a UEFI driver in C.
#include <Uefi.h>
#include <Library/UefiBootServicesTableLib.h>
#include <Library/UefiLib.h>
#include <Library/UefiApplicationEntryPoint.h>
EFI_STATUS EFIAPI UefiMain (IN EFI_HANDLE ImageHandle, IN EFI_SYSTEM_TABLE *SystemTable)
{
EFI_STATUS Status;
Print(L"UEFI Boot Driver Initialized.\n");
// Perform disk initialization or hardware detection
// This could include reading sectors from disk, finding file systems, etc.
return EFI_SUCCESS;
}
As you can C from the example, some libraries are being included at the top, followed by some gibberish of the finest caliber. After which point, a block of code containing a few lines – many of us will recognize “Print”
Windows vs. Linux Boot Process
 STAGE 0: Hardware Initialization (BIOS/UEFI)  Same
|
||
| Steps Same for both OSes.
|
Windows | Linux |
| BIOS/UEFI runs firmware POST (power-on self-test), initializes CPU, memory, basic hardware. | ||
| Boot order is read, finds bootable device (like SSD). | ||
| If using UEFI: it looks for an .efi file (bootloader). | ||
 STAGE 1: Bootloader  DIFFERENT
|
||
| Feature | Windows (BCD + Bootmgr) | Linux (GRUB, systemd-boot, etc.) |
| Bootloader | bootmgr.efi (Windows Boot Manager) | grubx64.efi, systemd-boot, or others |
| Boot Config | BCD (Boot Configuration Data) | GRUB config files (e.g., /boot/grub/grub.cfg) |
| OS Selection | Simple menu if multiple OSes | Full menu in GRUB with many options |
| Kernel Location | Windows bootloader loads Windows Kernel from NTFS | GRUB loads Linux Kernel from ext4, btrfs, etc. |
Windows uses a proprietary boot manager with BCD. Linux is modular and allows different bootloaders and more advanced customization.
 STAGE 2: Kernel Loading DIFFERENT
|
||
| Feature | Windows | Linux |
| Kernel | ntoskrnl.exe | vmlinuz or bzImage |
| Kernel Arguments | From BCD | From GRUB config (linux, initrd, etc.) |
| Init RAM Disk | Loads boot.wim and system drivers | Loads initrd or initramfs |
| Device Drivers | Kernel-mode drivers loaded from registry | Kernel modules loaded from /lib/modules/ |
Linux kernels are generally more configurable and modular, whereas Windows kernels load tightly controlled drivers (often digitally signed).
 STAGE 3: Init System DIFFERENT
|
||
| Feature | Windows | Linux |
| Init System | smss.exe → wininit.exe → services | systemd, SysVinit, or OpenRC |
| Service Startup | Services defined in registry | Unit files in /etc/systemd/system/ |
| Shell/Login | winlogon.exe + GUI login | getty (CLI), then graphical login (like GDM, SDDM) |
Windows uses a fixed startup sequence of services, while Linux’s init systems (especially systemd) allow for flexible and parallelized startup of services.
 Summary of Key Differences |
||
| Boot Stage | Windows | Linux |
| Bootloader | bootmgr.efi + BCD | GRUB, systemd-boot, LILO, etc. |
| Kernel File | ntoskrnl.exe | vmlinuz, bzImage |
| Init System | wininit, smss, services.exe | systemd, init, OpenRC, etc. |
| Drivers | Precompiled, signed .sys files | Loadable .ko modules |
| Filesystems | Typically NTFS | ext4, xfs, btrfs, etc. |
| Customization | Limited (via BCD & registry) | High (bootloader, kernel, services) |
Next time you turn a device on, maybe you will have just a teeny-weeny bit more appreciation for all of the unseen, but vitally important processes! Or perhaps my friend, you are already a wizard of appreciation.
This content originally appeared on DEV Community and was authored by Anna Villarreal