Modern Windows PCs reach a usable desktop in seconds, and the speed is not an accident of faster storage alone. Since Windows 8, Microsoft has shipped a feature called Fast Startup, which reuses a saved kernel session instead of building a fresh one at every power on. Combined with the UEFI firmware interface and a streamlined handoff from firmware to the boot manager, the result is a start sequence that looks and feels almost instant compared to the era of spinning disks and legacy BIOS.
From BIOS to UEFI and Why Firmware Matters
For decades, PCs booted through the Basic Input Output System, a firmware layer that tested hardware, enumerated disks in fixed order, and loaded a small chunk of code from a master boot record. That code then found a partition, loaded a boot sector, and eventually started the Windows boot manager. Every step was small, 16 bit, and slow, and the firmware had no real knowledge of the operating system it was about to start.
UEFI replaces that model with a 32 or 64 bit firmware environment, defined interfaces, and a boot manager of its own. Instead of hunting through disks for a bootable signature, UEFI reads boot entries stored in its own variables and launches an EFI application directly from an EFI system partition. On a Windows machine, that application is bootmgfw.efi, the Windows Boot Manager. The firmware can also initialize hardware in parallel rather than sequentially, which alone removes several seconds on many systems.
UEFI also enables Secure Boot, which verifies the digital signature of each boot component before running it. For the Fast Startup story, the relevant part is simpler: UEFI knows exactly which file to run next, it can launch it without legacy disk probing, and it passes control to it quickly. The firmware to operating system handoff becomes a narrow, well defined step instead of a chain of small guesses.
Modern UEFI implementations also support a fast boot option inside the firmware setup, which skips some hardware tests and USB device initialization when nothing has changed since the last power on. This firmware level option is entirely separate from the Windows Fast Startup feature, but the two stack. A machine with both enabled initializes only the minimum hardware needed to reach the boot device, launches the Windows Boot Manager almost immediately, and leaves the rest of device discovery to the operating system kernel itself.
The Normal Boot Path From Firmware to Desktop
Understanding Fast Startup requires a quick tour of the normal path. After the user presses the power button, UEFI initializes the platform, loads bootmgfw.efi, and that program reads the boot configuration data store. The boot manager then launches winload.efi, which loads the Windows kernel, the hardware abstraction layer, and the boot device drivers into memory.
Once the kernel initializes, the session manager smss.exe starts, user mode subsystems such as the client server runtime process come up, wininit launches services and the local security authority, and winlogon presents the sign in screen. Windows documentation refers to the stage up to kernel initialization as kernel loading and the stages after it as logon phases, and the Boot Performance area of the Event Viewer measures them under event id 100 from the Microsoft Windows Diagnostics Performance log.
On a healthy modern system with an NVMe drive, this full path can already take well under twenty seconds. But with Fast Startup enabled, part of the path is removed entirely, which is why many machines find the desktop in single digit seconds. The part that gets removed is the kernel session creation, and understanding that change means understanding what Windows does at shutdown.
It is worth noting that the boot manager itself supports scenarios beyond the simple one system case. The boot configuration data store can hold multiple entries, so machines that dual boot Windows versions, or that include recovery environments, present a short menu before winload runs. On the common single system configuration the default entry loads with no visible pause, and the firmware to winload transition takes well under a second on current hardware.
What Fast Startup Actually Saves at Shutdown
When a user shuts down with Fast Startup enabled, Windows does not perform a complete power off. First, every user session is logged off, so applications, user hives, and user data behave exactly as they would in a true shutdown. Then, instead of closing the operating system root session, session zero, Windows hibernates it. It saves the current state of the kernel and the drivers to the hiberfil.sys file on the system volume, and only then cuts power.
The hibernation file in this scenario is written in a reduced mode. A standard hibernate from a sleep menu must preserve the kernel, all drivers, the session manager, and the memory of every open application, which makes the file large. A Fast Startup hibernation holds only the kernel session with its drivers, since users were already logged off. Windows sets a flag in the hibernation file indicating that only the kernel state is present, which is why engineers sometimes call this shutdown mode Hiberboot rather than pure hibernation.
Because firmware power on self test and UEFI preboot still run, the time saved is the time Windows would otherwise spend initializing the kernel, starting core drivers in dependency order, and bringing session zero services to life. On systems measured by Microsoft around the Windows 8 release, this trimming cut boot time by roughly 30 to 70 percent compared with a cold boot on identical hardware. Firmware time, usually a fraction of the total on UEFI systems, is untouched by the technique.
How the Saved Session Restores on Power On
When the user next presses the power button, UEFI again locates and launches bootmgfw.efi, but this time the boot configuration indicates a resume from hiberfil.sys. The boot manager loads winresume.efi instead of winload.efi, and winresume reads the compressed kernel image and driver state from the hibernation file straight back into memory. Once the memory snapshot is complete, execution jumps into the kernel at the point where it saved its state, and the drivers resume rather than reinitialize from zero.
This shortcut is why the desktop appears quickly even on machines where a full cold start still takes a while. The restore path consists mostly of reading sequential data from disk, and sequential reads are the one workload even slow drives perform well. After the kernel session is rehydrated, winlogon and the sign in screens appear almost immediately because session zero is already alive.
The resume sequence still replays some validation work. Hardware identifiers are checked so the hibernated session matches the machine, and drivers receive power callbacks to restore device state. If anything mismatches, Windows discards the hibernation data and performs a normal cold boot, protecting the user from a corrupted start. This fail safe design is part of why Fast Startup can remain enabled by default on Windows 10 and Windows 11 installations.
Resuming a saved session also skips work that a cold boot repeats every time, such as rebuilding the driver service dependency graph and running early start anti malware initializations from a blank state. The tradeoff is a slight delay at shutdown, since writing the kernel image to disk takes a second or two on solid state storage and longer on mechanical drives. Most user studies treat that cost as invisible because people walk away from a shutting down machine, while the saved seconds at power on are felt directly.
Why Restarts Differ From Shutdowns
An important behavior confuses users the first time they meet it: a restart takes longer than a shutdown followed by a power on. This is deliberate. Restart always performs a full boot cycle with genuine reinitialization of drivers, which is why Windows Update frequently schedules restarts and never leans on the hibernation shortcut. If a patch touches the kernel or boot drivers, that patched state must be exercised fresh at least once.
Conversely, shutting down through the Start menu with Fast Startup enabled never produces a truly fresh kernel unless the user takes extra steps. Holding Shift while clicking Shut down performs a full cold shutdown on that one occasion, and running the shutdown command with the full flag produces the same result from a script. The Fast Startup control lives in the classic Power Options control panel, on the screen that defines what the power buttons do, and the administrator can disable it there.
On managed fleets, some administrators disable Fast Startup entirely because dual boot systems can hit file system inconsistencies when another operating system mounts a volume Windows considers hibernated, and because Wake on LAN and certain firmware updates behave more predictably with fully cold boots. The behavior that matters for IT is that Windows treats the two user visible paths differently: shutdown is optimized for speed, restart is optimized for correctness.
Performance Numbers and Tooling for IT
Engineers who want precise measurements can read the Diagnostics Performance channel in the Event Viewer. Event id 100 summarizes boot duration and breaks it into paths, including main path boot time and boot post boot time. Microsoft documents BootStart, MainPathBoot, and PostBoot phases, and explains that a boot is considered finished when the system has been idle for a defined period rather than when the desktop first paints. That distinction matters, because a desktop that appears in eight seconds can still be loading services in the background for another thirty.
The Windows Performance Toolkit gives much deeper insight. The xbootmgr and later wpr based traces capture every phase from firmware handoff through post boot activity, and the Windows Performance Analyzer displays them as stacked timelines. Administrators use these traces to spot slow third party filter drivers, firmware regressions, or misbehaving prelogon agents that inflate the start time on hardened images.
Fast Startup interacts with storage layout too. On systems that keep the hibernation file on an NVMe device, the resume step often costs only a couple of seconds. On systems that still use a small solid state system drive paired with a mechanical data drive, the hibernation file stays on the fast drive and the win resume remains quick. The feature therefore compounds with modern storage rather than substituting for it.
Rolling Back or Disabling Fast Startup Safely
The cases where disabling Fast Startup helps are narrow but real, and IT departments usually confirm them through diagnostics rather than guesswork. Common reasons include these scenarios:
- Dual boot systems where Linux or another operating system must mount the Windows volume, since a hibernated NTFS partition can be mounted read only or trigger repairs; encrypted volumes whose preboot authentication expects a full hardware reinitialization at every power on; BIOS or firmware updates that require untainted POST cycles for several boots in a row; and troubleshooting paths where support teams want guaranteed cold sessions while reproducing a driver fault.
The toggle itself lives under Control Panel, Hardware and Sound, Power Options, System Settings. The setting is called Turn on fast startup and it sits under the power button definitions, protected by an administrator elevation link. Comparable group policy and Intune configuration service provider settings exist for organizations that prefer centralized management, and the powercfg command accepts a hibernate off switch that removes both hibernation and Fast Startup together.
Whether a fleet keeps the feature enabled or not, the underlying architecture remains the same: UEFI hands control to a Windows bootloader, the bootloader either loads a fresh kernel with winload or restores a saved one with winresume, and the desktop arrives a few seconds later. Understanding that saved kernel session is the key to explaining why modern Windows machines feel nearly instant when the user lifts a laptop lid on Monday morning.