The Off-Key Bard
Technology

What Happens When You Press the Power Button on Your Computer?

Or: how a computer goes from a silent collection of electronics to a working operating system. The machine has to run software before it can load the software that runs its software.

Or: How a Computer Goes From a Silent Collection of Electronics to a Fully Functioning Operating System

You sit down, press the power button, and the familiar sequence plays out. Fans spin, lights come on, a manufacturer's logo appears, and eventually Windows shows its sign-in screen. It seems simple. You pressed a button and the computer turned on.

Inside the machine, a lot has happened. Power has been enabled and checked, the processor has started executing instructions, memory has been prepared, hardware has been discovered, firmware has found a bootable operating system, and Windows has loaded what it needs to manage everything from your keyboard to your graphics card.

The strange part is that the computer has to run software before it can load the operating system that normally runs its software. How does it know what to do before Windows, Linux, or anything else is there to tell it? The answer is a sequence of layers, each doing just enough to make the next one possible.

The Computer Isn't Completely Off

When you shut down a desktop, the processor stops running ordinary instructions, memory may lose its contents, and most fans stop. That doesn't mean every circuit is dead. If the power supply is plugged into a live outlet with its rear switch on, a typical ATX supply keeps a small standby rail, commonly called 5VSB, powering selected motherboard circuits. That's why some boards show a little LED even when Windows has shut down. The machine isn't running normally, but part of its power-management system is awake, able to notice the button, support wake-up features, and coordinate the move to full power.

The button itself is usually a plain momentary switch wired to the motherboard. It doesn't route hundreds of watts to the processor; it just changes a signal the standby circuitry can detect, telling the board you want to change power state. That's why one button can turn the machine on, wake it from sleep, or request a controlled shutdown.

Power Supply Handshake

On a conventional ATX desktop, the motherboard tells the power supply to start by pulling a control line called PS_ON# low. LTT Labs' explanation of ATX timing describes it as a signal from the motherboard to the power supply, active low, where a low level near 0 volts means "on." The supply then brings up its main rails, including the 12-volt rail that modern components lean on heavily, by converting household AC into regulated DC through switching transistors, transformers, filters, feedback, and protection circuits.

The motherboard can't just assume that went well. The supply watches its own outputs and, once they've settled, raises a second signal called PWR_OK, or Power Good. The same article describes it as telling the motherboard that the output rails are within specification and ready for load, and notes the supply waits a deliberate delay after the rails settle before asserting it. Wikipedia's page on the power good signal adds the reason: under ATX the signal reaches the circuitry that controls the processor's reset line, so the processor is held in reset until the voltages are trustworthy. It also gives typical timing, with assertion normally coming a fraction of a second after the supply is switched on, and notes that cheap supplies sometimes skimp on the monitoring behind the signal.

That is why a failing supply can produce confusing symptoms: fans may twitch and lights flash without the machine ever finishing startup. Turning on and booting are different events.

The Processor Needs Somewhere to Begin

A processor can't start executing from an arbitrary place. After reset, an x86 PC's processor starts in a defined state and fetches its first instructions from a location associated with the system firmware. The details have evolved across processor generations, but the principle holds: the CPU needs an initial instruction source. At this point Windows isn't running, no applications are loaded, and the computer has no full operating environment. The processor is following a small, fundamental set of instructions supplied by firmware.

That solves the chicken-and-egg problem. The computer needs software to initialize hardware and load an operating system, but can't load the operating system until enough hardware works to reach the storage device holding it. Firmware is the way out. It's software stored in nonvolatile memory, usually flash on the motherboard, which keeps its contents without power, so the instructions needed to start the machine are available before anything has been loaded from a drive. It initializes essential hardware, sets up early execution facilities, and eventually finds a bootable operating-system loader.

Older PCs used the Basic Input/Output System, or BIOS. Modern PCs generally use the Unified Extensible Firmware Interface, UEFI, which provides standardized interfaces for boot applications, device access, and handing over to the operating system, plus modern boot management and Secure Boot. People still call UEFI settings "the BIOS," but they're different firmware architectures, and Windows 11 boots through UEFI.

POST, Beeps, and the Long Black Screen

Once firmware is running it has to prepare what the boot needs, some of it before system memory is even usable. Many people know part of this as POST, the Power-On Self-Test: startup checks that help decide whether essential hardware can support booting. It isn't a full diagnostic. A machine can pass POST and still have bad storage or memory that's unstable under load. If something essential fails, firmware may stop before Windows ever loads.

Older computers reported POST failures with beep codes, and some modern boards use diagnostic LEDs labeled CPU, DRAM, VGA, and BOOT instead. They show roughly where startup stopped, but a lit LED is a clue, not a diagnosis.

Memory is often the reason for a long black screen. DRAM isn't ready the instant power arrives, and on modern DDR systems the platform runs memory training, calibrating timing and signaling because high-speed memory has very little margin. After new RAM, a firmware update, or cleared settings, the first boot may train more extensively, and DDR5 can be noticeably slow at it. A slow first boot after a memory change doesn't mean the RAM is bad, though repeated restarts can point to compatibility problems.

XMP and EXPO profiles make this more delicate: if the faster configuration is unstable, the machine may fail to boot or fall back to safer settings, which is why a no-display problem after changing memory settings is usually fixed by returning to a stable configuration.

From Firmware to Windows Boot Manager

As initialization continues, firmware identifies the hardware it needs for the next stages, like storage controllers and graphics, without bringing every device to its final Windows state. The logo it may show is not Windows. It's drawn by firmware and often stays up as control passes between layers, so a machine stuck on the logo could have a firmware, device-detection, or boot-manager problem. The logo alone doesn't name the culprit.

Next firmware needs something bootable. UEFI keeps boot options that identify operating-system loaders or other boot applications, and it follows its boot order to start one. That's why changing boot order decides whether the machine starts Windows, a USB installer, or another system. On a typical Windows install, one entry points to the Windows Boot Manager. The entry isn't just a hint that Windows files exist somewhere; it names the application the firmware should run.

Finding that application depends on the disk layout, which ties back to yesterday's file-system article. A modern UEFI Windows install ordinarily uses a GUID Partition Table, and one of its partitions is the EFI System Partition, which holds boot files. On a typical Windows system it uses a FAT-family file system, which is why a simple, widely understood format survives in the pre-boot world, and it contains Microsoft's boot application at a path like \EFI\Microsoft\Boot\bootmgfw.efi. That file isn't Windows. It's an executable that runs inside UEFI and helps start Windows. The partition is normally hidden from File Explorer, sensibly, since changing it carelessly can stop the machine from starting.

UEFI systems can also support Secure Boot, which uses cryptographic verification to help ensure that only authorized boot applications load, making it harder for malware to insert itself into early startup. It doesn't encrypt the drive and is separate from the Trusted Platform Module.

The Windows Side

After firmware launches Windows Boot Manager, the process becomes Windows-specific. Boot Manager reads Boot Configuration Data, or BCD, which can describe operating-system installations, boot options, and recovery environments. With multiple Windows installations it may show a menu. On a single-install system it moves on automatically to the operating-system loader, on a modern UEFI system commonly \Windows\System32\winload.efi. The loader prepares what the kernel needs: it loads the Windows kernel, important system components, and drivers required early, and sets up memory structures and configuration. The kernel can't simply be launched like a desktop program, so the loader does the preparation before the operating system takes charge.

UEFI provides services during this period that boot applications can use to access devices, allocate memory, and talk to firmware. Those aren't meant to remain in charge once the operating system is running. The UEFI specification describes boot services as available until a UEFI OS loader loads enough of its own environment to take control, at which point it terminates them by calling ExitBootServices(). The call is, in the specification's words, "intended for use by the operating system to indicate that its loader is ready to assume control of the platform and all platform resource management." After that, only runtime services remain callable, and the loader and OS must preserve the memory those services need. It's a real architectural boundary: control has moved from firmware to operating system.

Now the kernel, centered on ntoskrnl.exe, initializes memory management, interrupt handling, and process scheduling, the foundations that let many programs share hardware without each controlling every component. Your desktop still isn't there, but the infrastructure that makes it possible is.

Drivers are how Windows learns to work with particular hardware. Some, like the storage driver, must load very early, and because drivers run with significant privileges, a serious fault can force a blue screen. A blue screen during startup doesn't prove the installation is corrupted. The stage where it happens is a diagnostic clue.

With the kernel and essential drivers up, Windows builds the environment for user-mode processes, starting with the Session Manager (smss.exe), then services, security, and sessions. The sign-in screen means much of the work is done, but not all: when you sign in, Windows loads your profile, shell, startup applications, and sync tools. The operating system was already running; the desktop is just the graphical environment you use to interact with it.

Fast, Ready, and Not the Same Thing

Boot time and readiness are different measurements. Windows might reach the desktop in twelve seconds, then OneDrive, a game launcher, and security software pile on and leave the machine sluggish for another half minute. The core boot finished fine; the delay is work done afterward, and trimming startup programs can help more than any hardware change.

An SSD helps because booting involves many small reads that a mechanical drive pays a seek delay for. But it can't speed up what happens before storage matters, like memory training and hardware detection, and once storage latency is low, upgrading from SATA to NVMe often helps little. A box's peak sequential speed isn't startup performance.

Here's one of Windows' more surprising behaviors. With Fast Startup enabled, a shutdown and power-on is not a full fresh boot. Microsoft's documentation says that when it's on and a user shuts down, all sessions are logged off and the computer enters hibernation: the kernel session isn't closed but is saved, along with device drivers, to hiberfil.sys. The next power-on can restore that instead of a complete kernel initialization. Restart is different. Microsoft states that Fast Startup doesn't apply to Restart, because restarting usually means you want a completely new Windows state, so it performs a full boot cycle. That's why Restart can fix problems that survive a shutdown. Fast Startup is enabled by default on many Windows installations, although its availability and behavior depend on the system's configuration. Microsoft generally recommends using Restart when you need a completely fresh Windows startup rather than disabling Fast Startup solely for troubleshooting.

When It Goes Wrong

The startup sequence is a map for diagnosis, because each failure points at a stage. Nothing at all when you press the button suggests power delivery or the button circuit. Fans spinning but no POST points to hardware initialization, especially memory. "No bootable device" suggests boot order, drive detection, damaged boot files, or a missing firmware entry, and it doesn't automatically mean the SSD died, so check whether firmware detects it before buying a replacement. A crash after Windows begins loading points to the kernel, drivers, or storage, and a desktop that drags points to startup applications. Troubleshoot in order: can firmware initialize the hardware, can it find the bootloader, and only then focus on Windows.

Windows may enter Automatic Repair after repeated failures, launching the Windows Recovery Environment. That doesn't mean the cause is identified, only that the machine initialized enough to run recovery. And holding the power button for several seconds forces a hardware-level power-off, which is useful for a frozen system but not a controlled shutdown, since applications can't save and file-system protections can't guarantee unsaved data survives.

The framework covers other cases too. A USB installer doesn't bypass any of this; firmware still initializes hardware and then picks a boot application from the USB drive, which is why the stick needs boot structures the firmware recognizes. Linux follows a broadly similar path, with a loader such as GRUB preparing the kernel. Secure Boot, Windows integrity mechanisms, and a TPM serve different purposes, but together they show that startup is a series of trust handoffs.

The Bard's Take

Pressing the power button doesn't simply turn on Windows. It starts a coordinated relay across electrical engineering, firmware, and operating-system design. Standby circuitry notices the press and asks the supply for power. The supply raises its rails and, once they're stable, signals Power Good. The processor begins executing firmware, which configures memory, discovers hardware, and checks that the machine can proceed. Then it follows its boot configuration to a loader, Windows Boot Manager picks the installation, and the Windows loader prepares the kernel and essential drivers. Firmware hands control to the operating system, the system services start, and eventually you reach a sign-in screen and a desktop, with startup programs possibly still working in the background.

It also explains why startup failures look so different. Unstable memory may never reach the bootloader. A missing boot entry can stop Windows even when the SSD is healthy. A bad driver can crash the system after the kernel loads. Too many startup applications can make a healthy installation feel slow. A computer that powers on hasn't necessarily booted, and one that reaches the desktop hasn't necessarily finished.

Each stage does just enough to make the next possible. The power supply makes electrical operation possible, firmware makes the hardware usable, the bootloader makes the operating system reachable, the kernel makes general-purpose computing possible, and the desktop makes it accessible to you. All of it begins with two electrical contacts briefly touching. The remarkable thing isn't that your computer takes a few seconds to start. It's how much happens in those seconds that we never notice.

Sources

← Back to the Desk — Technology