iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
When you press a PC’s power button, the operating system does not start immediately. Platform firmware first initializes enough hardware to operate the machine, applies a boot policy, finds a boot target, and starts a UEFI operating-system loader. That loader prepares the operating system and calls ExitBootServices(); firmware boot services end at that boundary, and the operating system assumes control. UEFI runtime services may remain available after the handoff.
The boot process is a chain of handoffs
A modern UEFI PC boot is best understood as four major transfers of responsibility:
- Platform initialization: firmware runs its initialization drivers and prepares the consoles, memory, and devices needed for boot.
- Boot selection: the firmware boot manager reads boot options stored in nonvolatile RAM (NVRAM), applies the configured order and platform policy, and chooses what to try.
- Loader execution: firmware loads the selected UEFI operating-system loader as a UEFI application. The loader uses firmware boot services while it prepares the operating system.
- Operating-system takeover: when the loader is ready to manage the platform itself, it calls
EFI_BOOT_SERVICES.ExitBootServices(). Firmware boot services stop, and the operating system continues starting with control of the platform.
The exact screens, delays, device order, and recovery behavior differ between PCs. The sequence below is the standards-based UEFI model, not a promise that every manufacturer exposes the same menus or performs every internal operation in the same order.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Fix the driver behind crashes, sound loss and screen glitches3Clear out junk files and repair common Windows errors1. Firmware initializes the platform
Firmware starts before an operating-system loader
After the platform reaches the point at which firmware can execute, UEFI begins its platform-initialization phases. Firmware must establish enough of a working environment to identify devices, provide console output where supported, and locate a bootable target. At this point, no Windows or Linux kernel is running; the firmware owns the machine’s resources.
#1 Best Overall
- AMD Socket AM4: Ready to support AMD Ryzen 5000 / Ryzen 4000 / Ryzen 3000 Series processors
- Enhanced Power Solution: Digital twin 10 plus3 phases VRM solution with premium chokes and capacitors for steady power delivery.
- Advanced Thermal Armor: Enlarged VRM heatsinks layered with 5 W/mk thermal pads for better heat dissipation. Pre-Installed I/O Armor for quicker PC DIY assembly.
- Boost Your Memory Performance: Compatible with DDR4 memory and supports 4 x DIMMs with AMD EXPO Memory Module Support.
- Comprehensive Connectivity: WIFI 6, PCIe 4.0, 2x M.2 Slots, 1GbE LAN, USB 3.2 Gen 2, USB 3.2 Gen 1 Type-C
UEFI Platform Initialization describes a driver-dispatch stage commonly called the DXE phase. The DXE dispatcher runs firmware drivers whose dependencies have been satisfied. Those drivers expose the services and device protocols that later boot stages need. The implementation is platform-specific, so two computers can perform similar work in different orders or display different logos and messages.
Why the initialization stage matters
- It creates the firmware environment in which the boot manager can inspect storage and other boot media.
- It initializes the consoles used for firmware menus or diagnostic output when the platform provides them.
- It loads the firmware drivers required to access the device paths and files identified by boot options.
- It determines which platform policies and recovery rules will apply when the normal boot path is attempted.
A failure during this stage occurs before the UEFI operating-system loader has been started. A machine that never reaches a firmware menu or boot-selection message is therefore at an earlier point in the chain than one that reports a missing loader.
2. The UEFI boot manager chooses what to run
Boot options live in NVRAM
UEFI stores boot options in global NVRAM variables. Each option identifies a device path and the UEFI image or file that firmware should load from that path. The boot order is a list of those options, and the firmware normally tries them in the configured sequence.
Quick wins for a faster PC:
Scan for outdated or missing drivers - takes under a minuteDriver Scan →Repair Windows errors before they cause bigger problemsFix Now →This is different from treating a disk as a single undifferentiated “boot device.” A UEFI option points to a particular device and file, allowing the firmware to start an operating-system loader located on a system partition or on supported removable media. The option can also carry a description shown in firmware setup, but the important functional information is the target path and its position in the order.
What the boot manager evaluates
| Boot-manager element | What it controls | What happens during normal boot |
|---|---|---|
| NVRAM boot option | Identifies a device path and UEFI image file | Firmware has a specific loader target to open |
| Boot order | Sequence in which options are attempted | The first usable option is normally selected |
| Internal or removable target | Where the device path points | Firmware can try an internal system partition or supported removable media such as USB |
| Platform boot policy | Rules for adding, discarding, or replacing options | Firmware may skip an invalid option or enter a recovery path instead of following the ordinary order |
Why a listed option may not be used
The configured order is not an unconditional command. Firmware policy can add options, discard options that are no longer valid, or invoke recovery behavior. A storage device can remain physically connected while its referenced file or device path is unavailable. In that case, the firmware may move to the next option, show a boot error, or use a platform-defined recovery path.
Rank #2
- Supports AMD Ryzen 5000 & 3000 Series desktop processors (not compatible with AMD Ryzen 5 3400G & Ryzen 3 3200G) and AMD Ryzen 4000 G-Series desktop processors
- Supports DDR4 Memory, up to 4400(OC) MHz
- Lightning Fast Experience: PCIe 4.0, Lightning Gen4 x4 M.2 with M.2 Shield Frozr
- Premium Thermal Solution: 7W/mK pad, additional choke thermal pad and M.2 Shield Frozr are built for high performance system and non-stop works
- Powerful Design: Core Boost, Digital PWM IC, 2oz Thickened Copper PCB, Creator Genie, DDR4 Boost
Removable media follows the same general idea: the firmware needs a supported device path and appropriate UEFI boot files, not merely an empty USB drive. A USB device can be useful for installation or recovery only when it has been prepared with the files and structure expected by the loader.
3. Firmware loads the UEFI operating-system loader
The loader is a UEFI application
Once the boot manager selects an option, firmware opens the referenced UEFI image and starts it as a UEFI application. This application is the operating-system loader. It is not yet the complete operating system and is not the same thing as the firmware boot manager.
While it runs, the loader can use UEFI boot services to access devices, allocate memory, read files, and perform other preparation work exposed by the firmware interface. The loader uses those services to find the operating-system components it needs and assemble the information required for the next phase.
The system partition and loader file
UEFI’s model separates the firmware-readable system partition from the operating-system files that will run later. The boot option identifies the device and the loader file. Firmware’s responsibility is to locate and start that file; the loader’s responsibility is to continue the operating-system startup.
This division explains why a computer can successfully pass a firmware screen yet fail before the operating system appears. Firmware may have executed correctly, but the selected loader could be missing, inaccessible, incompatible with the selected device path, or unable to continue its own work.
Rank #3
- LGA 1150 Socket: The gaming motherboard supports Intel 4th gen processor (Core i7/i5/i3/Pentium/Celeron/E3 series) with LGA 1150 CPU socket, e.g. i5 4570, i5 4690k, i7 4790, i7 4790k, etc.
- Dual-channel DDR3: The Intel LGA1150 motherboard supports dual-channel DDR3 desktop memory, 1333/1600/1866MHz frequency type, the maximum memory capacity is 32GB (4*8GB)
- High-speed Interface: The computer motherboard supports M.2 protocol, NVME and SATA mode automatic switching. And it is equipped with 1 RJ45 gigabit network, 1 PCIe x16 3.0, 1 PCIe x1 2.0, 2 PCI, 3 SATA 3.0, and VGA, DVI, HDMI-compatible high-definition multimedia transmission interface
- Stable Power Supply: 4-phase power supply, all-solid-state capacitor design, fine workmanship, professional stability. And the LGA 1150 M-ATX placa madre is equipped with 24+8 pin power interface (at least 500w brand power supply)
- High Performance Motherboard: The Intel DDR3 motherboard is equipped with B85 chipset. And the 8-layer PCB design effectively extends its service life. Heat dissipation armor protection, with strong heat dissipation, to ensure stable bus communication
4. The loader prepares the operating system
Preparation happens before the handoff
The UEFI loader performs the work needed to move from a firmware environment to an operating-system environment. It reads the operating-system components available through the boot path, allocates memory through boot services, and prepares the information that the operating system will need when it begins execution.
PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchThe precise tasks depend on the operating system and its loader. UEFI specifies the interface between firmware and the loader; it does not prescribe every later operating-system startup stage. Consequently, a Windows loader and a loader for another operating system can use the same firmware interface while performing different preparation steps.
Firmware still owns resources at this point
Until the handoff call, firmware remains the owner of the platform resources governed by UEFI boot services. The loader can request those services, but it has not yet taken permanent responsibility for resource management. The UEFI specification summarizes this state: “During boot, system resources are owned by the firmware and are controlled through boot services interface functions.”
5. ExitBootServices() transfers control
The boundary that ends boot services
When the loader has completed its firmware-dependent preparation, it calls EFI_BOOT_SERVICES.ExitBootServices(). This call is the formal boundary between firmware boot and operating-system control.
After a successful call:
- UEFI boot services are no longer available to the loader or operating system.
- The operating system, rather than firmware, is responsible for managing the platform resources it uses during normal execution.
- The loader proceeds with the operating-system startup using the data and memory arrangement it prepared before the call.
- UEFI runtime services may remain available, subject to the operating system and platform implementation.
ExitBootServices() is therefore more than a routine cleanup step. It marks the change in ownership. Before it, firmware supplies the boot-time environment; after it, the operating system must operate without those boot services.
The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Rank #4
- AM4 socket: Ready for AMD Ryzen 3000 and 5000 series, plus 5000 and 4000 G-series desktop processors.Bluetooth v5.2
- Best gaming connectivity: PCIe 4.0-ready, dual M.2 slots, USB 3.2 Gen 2 Type-C, plus HDMI 2.1 and DisplayPort 1.2 output
- Smooth networking: On-board WiFi 6E (802.11ax) and Intel 2.5 Gb Ethernet with ASUS LANGuard
- Robust power solution: 12+2 teamed power stages with ProCool power connector, high-quality alloy chokes and durable capacitors
- Renowned software: Bundled 60 days AIDA64 Extreme subscription and intuitive UEFI BIOS dashboard
Why the call is deliberately late
If the loader ended boot services before it had finished locating files, allocating memory, or collecting platform information, it would lose the standard firmware facilities needed for those tasks. Calling the function only after preparation is complete lets the loader use firmware while it needs it and then make a clean transfer of responsibility.
6. The operating system continues startup
What “the operating system loads” means
After the handoff, the loader continues into the operating-system startup path. The kernel and the components required for early execution begin running under operating-system control. The familiar sign-in screen, desktop, or service manager comes later; those visible stages are downstream of the firmware-to-loader sequence.
For Windows systems, Microsoft’s UEFI requirements describe firmware’s role as preparing the platform so Windows can access the boot device through UEFI and load the kernel. That requirement defines the firmware side of the boundary; it is not a complete description of every Windows startup phase that follows.
Runtime services are a different interface
Ending boot services does not necessarily mean that every UEFI function disappears. UEFI runtime services can remain callable after the handoff, although the operating system must arrange access to them and the platform must support them. Runtime services are distinct from the boot services used to discover devices and prepare the loader.
What you see on screen versus what firmware is doing
A manufacturer logo, a brief spinning indicator, a boot-menu prompt, or a blank screen does not identify one universal internal step. Firmware implementations choose their own presentation, and many stages complete too quickly to display anything.
Best Value
- AMD Socket AM4: Ready to support AMD Ryzen 5000/4000/3000 Series Processors.
- Enhanced Power Solution: Digital Twin 10+3 Power Phase and premium chokes and capacitors for steady power delivery.
- Advanced Thermal Armor: Advanced VRM heatsink for better heat dissipation. Integrated I/O Shield for quicker PC DIY assembly.
- Boost Your Memory: Compatible with DDR4 Memory and supports 4 DIMMs with Extreme Memory Profile support.
- Comprehensive Connectivity: 1x Ultra Durable PCIe 4.0 x16, 1x PCIe 4.0 M.2 slot, 1x PCIe 3.0 M.2 slot, 3x USB 3.2 Gen 2 Type-A, 1x USB 3.2 Gen 1 Type-A, and 1x Front USB 3.2 Gen 1 Type-C for hassle free setup.
- A setup screen is firmware configuration, not the operating system.
- A one-time boot menu asks the firmware to choose an option for that boot attempt; it does not necessarily rewrite the permanent boot order.
- An operating-system logo generally indicates that the loader has started or that the operating system is already taking over, but the exact transition depends on the platform and loader.
- A recovery screen can be selected by platform policy after an ordinary option is invalid or fails.
Because screen labels are implementation-specific, the reliable way to understand a failure is to identify the last confirmed boundary: firmware initialization, boot-option selection, loader execution, or operating-system takeover.
UEFI and legacy BIOS: what can be said safely
“BIOS” is still commonly used as a generic name for the firmware setup utility, but the sequence described here is the UEFI model. UEFI defines NVRAM boot options, device paths, UEFI loader applications, boot services, and ExitBootServices(). A legacy BIOS implementation does not expose that same UEFI boot-manager interface, so its internal sequence and terminology should not be inferred from this explanation.
Some computers provide compatibility features or firmware menus that preserve familiar BIOS wording while using UEFI underneath. The menu label alone is not enough to establish which boot path is active; the decisive details are the firmware mode, the boot options it stores, and the loader format it starts.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Diagnosing where a boot failure occurs
Use the handoff model to narrow the problem instead of treating “won’t boot” as one condition.
If the machine never reaches firmware interaction
- The failure is before the boot manager can select a UEFI option.
- Look for whether the platform shows any firmware logo, setup prompt, or diagnostic output.
- If none appears, changing the operating-system boot order cannot address the first failing stage.
If firmware opens but no operating system starts
- Inspect the available boot options and their order.
- Check whether the selected device path still points to the intended device and loader file.
- Try another valid option only when that option is known to contain appropriate UEFI boot files.
- Remember that platform policy may remove an invalid option or choose recovery automatically.
If the loader starts and then stops
- The firmware has already completed the selection and initial loader launch.
- The problem may be in the loader’s own preparation work or in the transition to operating-system control.
- Installation or recovery media can help only if it is prepared with a usable UEFI loader and the firmware can access its device path.
If the operating-system logo appears
The failure is later than basic firmware boot selection. Firmware has either started the loader or handed execution into the operating-system path, so repeatedly changing early boot options may not address the failing component.
The essential sequence to remember
- UEFI initializes platform hardware and dispatches the drivers needed for boot.
- The Boot Device Selection stage applies policy and prepares the boot environment.
- The boot manager reads NVRAM options and chooses a device-and-file target.
- Firmware starts that target as a UEFI operating-system loader.
- The loader uses boot services to locate and prepare the operating system.
- The loader calls
ExitBootServices(), ending firmware boot services. - The operating system continues startup; UEFI runtime services may remain available.
That sequence explains how a PC moves from firmware-controlled resources to an operating system that manages the machine itself, while also explaining why the same visible symptom can originate at several different boundaries.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
Free tools Windows power users keep installed
One-click scans. No signup required.
