Hey Investigator,
Have you ever felt confused by Windows booting? Don't worry—it's one of the most misunderstood topics in forensics. To most, it's just a spinning circle on a screen. To us, it's a high-stakes relay race where critical files and firmware phases must "hand over" control perfectly.
This guide is designed to take you from the very first spark of power to the moment you see your desktop, clarifying every technical "trap" along the way—even if you've never heard of these terms before.
1. The Big Picture: What is "Booting"?
So let's start at the very beginning. Before we hunt a single artifact, you and I need one shared picture of what "booting" even is — because every clue later in this guide sits somewhere on that timeline.
Booting is like a chef walking into a cold, dark kitchen. Before any cooking happens, they flip on the lights, fire up the stove, and lay the tools on the counter. Windows does the same: it copies itself out of the slow pantry (your disk) onto the fast counter (RAM) so the CPU can finally start cooking.
The Golden Rule: The main and overall idea for all versions of Windows booting is to find and start a program that will start the Windows loading operation (by the NTLDR or Winload.exe).
The Types of "Starts":
- Cold Boot: Starting from a total "Power Off" state. The hardware goes through a full initialization.
- Warm Boot (Restart): The computer restarts without a full power cycle. It's faster because the hardware doesn't have to "wake up" from scratch.
- Hybrid Shutdown (Fast Startup): The Windows 8+ default for "Shut down." Windows logs the users off but then hibernates the kernel session (Session 0) to
C:\hiberfil.sysinstead of fully powering down. The next "boot" simply restores that image — so it is not a true cold boot. (A Restart, by contrast, always performs a full cold boot.)
In this guide, when we say "Boot," we mean a true Cold Boot — but as an investigator, always ask which kind actually happened.
Why Fast Startup matters to an investigator
- "Shut down" ≠ powered-off state. The last-boot timestamp can be days old because the kernel was only resumed, not re-initialised — your uptime/boot timeline can mislead you.
hiberfil.sysis memory evidence. It holds a compressed image of kernel memory (full image after true hibernate, kernel-only after Fast Startup) — recover it for offline memory analysis.- Imaging caution. Fast Startup can leave NTFS in a "dirty"/locked state and the volume not cleanly dismounted. Fully power off (or do a real Restart) before live imaging, or note the dirty bit.
- Also collect
C:\pagefile.sysandC:\swapfile.sys— additional spill of volatile data.
2. The Core Vocabulary (No Knowledge Assumed)
A boot involves the same handful of characters over and over. If we learn their names now, the rest of the story reads itself — skip them and the later sections feel like alphabet soup.
Think of this as the cast list at the front of a play. You don't have to memorise it; just know who's who when they walk on stage.
POST (Power-On Self-Test) — The Health Check
The very first diagnostic test run by your computer. It checks if your CPU is working, if your RAM is present, and if your hardware is responding. If the POST fails, the computer will stop booting immediately.
NVRAM (Non-Volatile RAM) — The Motherboard's Memory
The firmware's "Settings Store" that survives power-off — it remembers your Boot Order and Secure Boot keys. On modern UEFI these live in the motherboard's flash chip; the little coin-cell battery you see on the board mainly keeps the real-time clock (and legacy CMOS settings) ticking.
File Systems — The Disk's Language
A File System is the "Grammar" of your disk. It organizes raw data into a human-readable structure.
Universal and simple. Used for the ESP (EFI System Partition) because every firmware speaks FAT32.
Used for the Windows (C:) Partition. Supports security permissions, large files, and "Journaling" (recovering from crashes).
UEFI (Unified Extensible Firmware Interface) — The Mini-OS
The modern replacement for BIOS. It's much smarter and more powerful. It understands FAT32 and can verify "Digital Signatures" to ensure the code hasn't been tampered with. It also enforces Secure Boot.
GPT (GUID Partition Table) — The Map
The modern replacement for MBR. It tells the computer exactly where each partition starts and ends. It is much safer because it keeps a backup of itself at the end of the disk.
BCD (Boot Configuration Data) — The Boot Registry
A structured database (similar to the Windows Registry) that tells the Boot Manager everything: which OS to load, where to find it, and which security settings are active.
Forensic Role: Attackers may disable integrity checks inside the BCD to load unsigned or malicious drivers. Always inspect it.
ESP (EFI System Partition) — The Launch Pad
A small FAT32 partition (~100–300 MB) that UEFI can read. It holds the firmware-launched boot loaders, most importantly \EFI\Microsoft\Boot\bootmgfw.efi and the BCD.
Forensic Role: The ESP is normally invisible to the user — a prime hiding spot for UEFI bootkits. Mount it and check for rogue or unsigned .efi files outside \EFI\Microsoft\Boot\.
TPM & Measured Boot — The Notary
The Trusted Platform Module is a secure chip that records a cryptographic hash of each boot component into PCRs (Platform Configuration Registers) as the system starts — this is Measured Boot. BitLocker can "seal" its key to those PCRs so the disk only unlocks if the boot chain is unchanged.
Forensic Role: A BitLocker prompt on a previously-silent machine, or failed remote attestation, can signal boot-component tampering. PCR values are an integrity baseline.
Quick BCD commands for investigators:
bcdedit /enum all show all boot entries
bcdedit /enum firmware show UEFI boot entries
bcdedit /enum {bootmgr} show boot manager settings
3. The Evolution: Why did the Boot Process Change?
Now that you've met the players, here's why we pause on history: on the job you'll meet both worlds — old BIOS/MBR machines and modern UEFI/GPT ones — and knowing why it changed tells you what's normal on each (and what's a relic an attacker is quietly abusing). Three pressures drove the change: Capacity, Security, and Speed.
The "Old Guard" (BIOS + MBR) — Legacy Flow:
- The 2.2TB Wall: MBR couldn't address disks larger than 2.2TB.
- The Security Gap: BIOS had no way to verify if the code was "Good" or a "Virus." Attackers used Bootkits to infect the MBR.
Contains executable code to load boot sector
4 entries × 16 bytes each
Standard: 0x55AA
The "Modern Guard" (UEFI + GPT) — Modern Flow:
- Supports disks larger than 2.2TB.
- Enforces Secure Boot via valid cryptographic signatures.
- GPT keeps a backup partition table for easier recovery.
Fake MBR to prevent legacy tools from corrupting GPT disk
Contains: Disk GUID, partition table location, CRC32 checksums
128 partition entries (Name, GUID, Type)
Actual user data and OS files (ESP, Windows, Recovery)
Duplicate for redundancy
Mirror of primary header
Bootkits: then vs now — where to look
Each era moved the boot code, and attackers followed it. Knowing the era tells you where a bootkit can hide:
Bootkits overwrite sector 0 (MBR) or the VBR/IPL of the boot partition (e.g. TDL4/Olmasco, Rovnix, Petya). Carve and hash the first sectors and compare against a known-good MBR.
Bootkits live in the ESP as rogue .efi files or in SPI-flash firmware (BlackLotus, ESPecter, MoonBounce, CosmicStrand). Mount the ESP, enumerate every .efi, and verify Secure Boot state.
4. Inside UEFI: SEC → PEI → DXE → BDS
Here's the part most people skip right over — so let's slow down. Before a single Windows file runs, the firmware quietly runs four phases of its own. We care because this is the lowest place malware can hide; if you ever chase a "there's-nothing-on-disk" infection, this is where it can be living.
SEC — Security Phase
The CPU reset vector. Establishes the firmware root of trust and sets up temporary memory (Cache-as-RAM, since main RAM isn't initialised yet). Hands off to PEI.
PEI — Pre-EFI Initialization
Small modules (PEIMs) bring up the CPU, chipset and main system RAM, and detect whether this is a normal boot or an S3 (sleep) resume. Builds the Hand-Off Blocks for DXE.
DXE — Driver Execution Environment
The bulk of firmware work. Loads the many DXE drivers, initialises devices and buses, and produces the UEFI Boot Services & Runtime Services that the OS loader will call.
BDS — Boot Device Selection
Reads the boot policy from NVRAM (BootOrder, Boot####), applies Secure Boot, and launches the selected loader — normally \EFI\Microsoft\Boot\bootmgfw.efi on the ESP.
Forensic Note: the firmware layer
These phases run from SPI flash, below the OS and even the hypervisor — the home of the deepest implants (malicious DXE or SMM drivers, e.g. LoJax, MoonBounce, CosmicStrand).
- Each phase is measured into TPM PCRs 0–7 — an unexpected PCR change is a tamper signal.
- Inspect NVRAM boot variables (
BootOrder/Boot####) for rogue or reordered entries. - Firmware-level analysis needs a flash dump + tooling such as CHIPSEC / UEFITool — OS tools can't see here.
5. Deep Dive: The OS Loaders (Legacy vs. Modern)
The firmware has done its job and pointed at a loader. We dwell on it because this is the one referee that decides which kernel runs and whether to trust it — tamper with the loader and every signature check after it becomes a lie. So let's meet the bridge between firmware and kernel, in both its old all-in-one form and the strict modern split.
The loader is the airport gate agent: it checks the boarding pass (the digital signature) before it lets the kernel onto the plane.
A. NTLDR (The Legacy All-in-One) — XP and Earlier
In older systems, NTLDR (NT Loader) performed multiple roles at once:
Role 1: Boot Manager
It read the boot.ini file to show you a menu of which OS to start.
Role 2: Hardware Detector
It ran a program called NTDETECT.COM to find basic hardware like your keyboard and mouse.
Role 3: Loader
It loaded the kernel (ntoskrnl.exe) and the HAL (Hardware Abstraction Layer) into memory together.
boot.ini: The Legacy GPS
What is it? A simple text file in the root of the C:\ drive. It tells NTLDR where Windows partitions are using ARC (Advanced RISC Computing) paths.
Forensic Role: If you see a modified boot.ini, an attacker might be trying to redirect the boot process or load a hidden OS.
NTDETECT.COM: The Legacy Scout
What is it? A 16-bit "Real-Mode" program used by NTLDR. Its only job is to scan hardware (Keyboard, Mouse, Disk, Video) and pass that "Hardware Map" back to NTLDR, which then gives it to the Kernel.
B. Winload.exe / Winload.efi (The Modern Bouncer) — Vista to Win 11
In modern Windows systems (Vista through Windows 11), the boot responsibilities are strictly split. While bootmgfw.efi acts as the manager, Winload is specifically the OS Loader. It acts as the final gatekeeper before the Kernel takes over.
The Bouncer: Signature Verification
Its primary job is KMCS (Kernel Mode Code Signing). Winload verifies the digital signature of every driver that is set to start at boot. If a driver is unsigned or the signature is invalid, Winload will block it from loading. This is a critical defense against rootkits that try to insert themselves into the boot process.
The Messenger: Loader Parameter Block
It prepares a massive, complex data structure called the LOADER_PARAMETER_BLOCK. Think of this as a "briefcase" passed to the Kernel containing the memory map, the SYSTEM registry hive, and the list of boot drivers.
Forensic Note: Winload Analysis
Winload.efi (UEFI) and Winload.exe (Legacy BIOS) both exist on modern systems. On a UEFI system, the presence of winload.exe in the BCD as the primary loader is highly suspicious and could indicate an attempt to bypass Secure Boot via legacy emulation.
Investigation: A modified Winload can be patched to silently disable KMCS, allowing malicious unsigned drivers to load. Always verify the hash of winload.efi against a known-good baseline for that specific Windows build.
Interactive Boot Explorer
Want to see exactly where these files live on the disk? Explore our interactive partition map to see the relationship between the ESP, the Windows partition, and the boot-critical files.
Open Disk ExplorerSecure Boot — The Gatekeeper
What is it? UEFI feature that cryptographically verifies every .efi binary before allowing execution.
How it works: UEFI stores trusted certificate keys in NVRAM. It checks the signature of bootmgfw.efi or winload.efi against those keys.
Forensic Role: Attackers bypass it by enrolling rogue certificates, exploiting signed-but-vulnerable bootloaders (BootHole), or disabling it entirely.
Investigator Check: Look for unexpected keys in the Secure Boot database or a disabled state in UEFI/NVRAM dumps.
C. After Winload: ELAM and the Driver Load Order
Before normal drivers load, Windows gives anti-malware the first move, then loads drivers in a strict, registry-defined order — a sequence investigators can audit.
ELAM — Early Launch Anti-Malware
A special, Microsoft-signed AV driver that Windows loads before any other boot-start driver. It classifies each subsequent boot/system driver as Good, Bad, or Unknown, and policy decides whether "bad/unknown" drivers are allowed to load — the earliest software defence against bootkits/rootkits.
Forensic Role: ELAM decisions are recorded; a disabled ELAM or a "bad" driver that loaded anyway is a strong tampering signal.
winresume.efi — The Resume Path
If a valid hiberfil.sys exists (true hibernate or Fast Startup), the Boot Manager runs winresume.efi instead of winload.efi — it rehydrates the saved memory image rather than booting the kernel fresh.
Forensic Role: A resume means no clean cold boot occurred — pair this with the hiberfil.sys analysis from Section 1.
Driver load order = service Start value
Every driver/service has a Start value under HKLM\SYSTEM\CurrentControlSet\Services\<name> that fixes when it loads:
- 0 — Boot: loaded by
winloadbefore the kernel initialises (disk, file-system, ELAM). - 1 — System: loaded during kernel initialisation.
- 2 — Automatic: started by the Service Control Manager at logon.
- 3 — Manual · 4 — Disabled.
Investigator Check: A malicious driver set to Start=0/1 (BYOVD / rootkit) gains control extremely early. Diff the Services key and verify each boot/system driver is signed.
6. BitLocker & Encryption at Boot
A short but crucial detour before the kernel wakes up. Why now? Because if the drive is encrypted, none of what follows can even be read until it's unlocked — and on a real case this single fact can decide whether you walk away with evidence or with noise. So the volume must be unlocked before winload touches a single Windows file.
The disk is a locked safe, and the TPM chip is a careful keyholder who only hands over the key if the room looks completely untouched. No key, no peek.
Unlock Methods (Key Protectors)
TPM-only (transparent — no prompt), TPM + PIN, TPM + startup key (USB), or the 48-digit recovery key. Each is a "protector" that can release the volume key.
The Unlock Flow
The Boot Manager asks the TPM to unseal the VMK (Volume Master Key) — released only if the boot-measurement PCRs match. The VMK then decrypts the FVEK (Full-Volume Encryption Key), and only now can winload read C:.
Key Hierarchy & Escrow
Data ← FVEK ← VMK ← protector. Recovery keys are commonly escrowed in Active Directory, Entra ID, or MBAM/Intune — your first place to look for a key.
Forensic implications
- No key = no evidence. A BitLocker volume can't be imaged or mounted offline without a protector or the recovery key — capture it (or a live RAM image) before shutdown.
- Suspended BitLocker writes a "clear key" to disk — the volume is effectively unprotected until re-enabled. Note it.
- While unlocked, the VMK is in RAM — recoverable by live memory capture (and historically cold-boot / DMA attacks).
- An unexpected recovery prompt means the measured boot chain changed (PCR mismatch) — possible boot tampering or a firmware/config change.
manage-bde -status encryption + protection state manage-bde -protectors -get C: list protectors / recovery ID repair-bde recover data with a key/package
7. Kernel Initialization: Inside ntoskrnl.exe
This is the moment the kernel finally takes the wheel — Winload slides it a "briefcase" (the LOADER_PARAMETER_BLOCK) and steps aside. We slow down here because this is where the "rules of the house" get set: which drivers load and in what order. Knowing that order tells you how early a malicious driver could have slipped in.
The kernel is the building manager who arrives first: switches on the power and water (core services), reads the rulebook (the SYSTEM registry hive), lets the approved staff in (drivers), then unlocks the front door for everyone else — its first hire being smss.exe.
Phase 0 — Bare Minimum
Runs with interrupts disabled. Brings up the HAL, bootstraps the Memory Manager, and builds the core kernel data structures needed before anything else can run.
Phase 1 — Building the OS
Initialises the Executive subsystems (Object, Process, Memory, Security Reference Monitor, I/O, PnP, Power), loads the SYSTEM registry hive, starts boot-start then system-start drivers, and brings up win32k.
Hand-off to User Mode
The kernel creates the Session Manager (smss.exe). smss runs autochk via BootExecute, sets up sessions, and the user-mode world begins.
Forensic Note
The SYSTEM hive loaded here is the configuration-of-record: services, their Start values, and driver load order all come from it. Boot-start (Start=0) and system-start (Start=1) drivers gain control before most defences — verify each is signed and expected.
8. The Protection Rings: Who Can Touch the Hardware?
Let's pause the timeline for a moment, because almost every privilege-escalation and rootkit story you'll ever read is really a story about rings. Grab this one picture and a huge chunk of Windows security suddenly clicks into place. Everything you've just watched was a controlled descent inward — firmware and the kernel earn Ring 0, then hand you a tightly-fenced Ring 3.
It's a castle with nested walls. Visitors stay out in the courtyard (Ring 3); only the most trusted reach the keep at the centre (Ring 0). Attackers spend their whole lives trying to sneak one wall further in. Click a ring to dissect it.
The key fact: the x86 architecture defines four rings (0–3), but Windows uses only Ring 0 (kernel mode) and Ring 3 (user mode) — Rings 1 & 2 are left unused for portability. Modern security then adds layers beneath Ring 0 (hypervisor, firmware, management engine), informally called the "negative" rings.
What is a privilege ring?
A protection ring is a hardware-enforced privilege level baked into the CPU. The lower the number, the more the code is trusted and the more it can do — touch physical memory, talk to devices, run privileged instructions. Crucially it is the CPU and OS that decide which ring code runs in, not the program itself: an application cannot simply promote itself to Ring 0.
Think of concentric security fences — the kernel sits in the guarded core, your apps live on the outer ring, and every request to move inward is checked at the gate.
Crossing the boundary: the system call
Because Ring 3 code can't touch hardware, opening a file or sending a packet means asking the kernel. The app calls a Windows API, which funnels through ntdll.dll into a single SYSCALL (x64) or SYSENTER (x86) instruction. The CPU jumps to a fixed kernel entry point, switches to Ring 0, does the work, then returns to Ring 3 with SYSRET / SYSEXIT / IRET.
Forensic angle: EDR products hook this boundary to watch behaviour, so malware increasingly uses direct syscalls (Hell's Gate / Halo's Gate) to slip past user-mode hooks.
How the CPU actually enforces rings
Rings aren't a software convention — they are checked in silicon on every instruction and memory access. A handful of CPU fields and instructions make it work:
| Mechanism | What it does |
|---|---|
| CPL Current Privilege Level | The low 2 bits of the CS (code segment) register hold the ring the CPU is running in right now — 0 to 3. Checked on every privileged instruction and memory access. |
| DPL Descriptor Privilege Level | The privilege level stamped on a segment / call-gate descriptor — the ring required to use that memory or gate. |
| RPL Requested Privilege Level | The low 2 bits of a selector. Lets the kernel deliberately act with a caller's lower privilege, preventing "confused deputy" attacks. |
| SYSCALL / SYSRET | The fast Ring 3 → Ring 0 entry and return pair on x64. Legacy x86 used SYSENTER/SYSEXIT or the software interrupt int 2Eh. |
| IDT interrupts & exceptions | Hardware IRQs and CPU faults vector through the Interrupt Descriptor Table into Ring 0 gates — another controlled path inward. |
| VMEXIT VT-x / AMD-V | Traps even Ring 0 down to the hypervisor ("Ring −1"); execution resumes with VMRESUME. This is how VBS isolates VTL1. |
| SMI → SMM | A System Management Interrupt drops the CPU into SMM ("Ring −2"); state is saved in SMRAM and execution returns with the RSM instruction. |
🏢 9. The User-Mode Builders: SMSS and Winlogon
And here's where the machine finally becomes "Windows" as you know it. The kernel spawns its very first child — smss.exe — and the user-mode world springs up behind it, one careful process at a time. Why memorise these few? Because they're your baseline: once you know the normal family by heart, a fake lsass or a wrong-parent winlogon screams at you.
These are the opening-shift staff who unlock the shop, switch on the tills, and set everything up before customers arrive. If a stranger is suddenly doing their job, you notice instantly.
smss.exe: The "First Citizen" of User Mode
Responsibilities: Sets up the session environment (environment variables, paging files, KnownDLLs), runs anything in BootExecute, then starts the Windows subsystem (csrss.exe) and winlogon.exe. The kernel-mode GUI driver win32k.sys is brought up by that subsystem.
Forensic Tip: SMSS should never have a parent other than System (PID 4). If it does, it's likely malware.
Open smss.exe in the Process Treewin32k.sys: The Artist
What is it? Kernel-mode driver that manages the Windows GUI, window management, GDI, and mouse/keyboard input.
Forensic Role: If hooked, attackers can capture screenshots or keystrokes at a very low level, invisible to user-mode security tools.
winlogon.exe: The Key-Master
Responsibilities: Handles interactive user logon/logoff, listens for Ctrl+Alt+Del (the Secure Attention Sequence), and launches LogonUI.exe.
Forensic Tip: Multiple instances for a single session or a non-System32 directory path are high-confidence malware indicators.
Open winlogon.exe in the Process TreeWindows Sessions & Session 0
A Session is the isolated workspace Windows builds for one logon — its own desktop, window station, processes and object namespace. Sessions are numbered in the order they are created.
Session 0 is the very first, created at boot for the operating system itself: all services and system processes live here, and since Windows Vista it has no interactive desktop. The first human to sign in gets Session 1; later users get 2, 3, …
Keeping services off the user's desktop (Session 0 isolation) blocks "shatter" attacks, where a low-privilege app sent window messages to a high-privilege service that shared its desktop.
Forensic Role: Note each process's Session ID. An interactive GUI process in Session 0, or a "service" running in Session 1, is abnormal and worth a closer look.
Persistence smss runs before anyone is watching
Before services or the shell exist, smss.exe reads two Session Manager keys — prime, low-noise persistence spots an investigator must check:
- BootExecute —
HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\BootExecute. Native (NT) apps run at boot before the Win32 subsystem. The legitimate default is justautocheck autochk *; any extra entry is a red flag (T1547). - KnownDLLs —
…\Session Manager\KnownDLLs. The trusted, pre-mapped system DLLs; tampering here enables stealthy DLL hijacking across the whole OS. - Pending file ops —
…\Session Manager\PendingFileRenameOperations. Malware queues renames/deletes that execute at the next boot, before AV loads.
The Relay Doesn't Stop Here — It Becomes the Process Tree
The instant smss.exe spawns, the linear "boot relay" turns into a living family tree of processes. smss.exe launches csrss.exe + wininit.exe (Session 0) and csrss.exe + winlogon.exe (Session 1) — and from there services.exe, lsass.exe, userinit.exe, and finally explorer.exe (your desktop) all descend.
The companion Eye-Describe page maps exactly who spawns whom, when each process runs, and what each is responsible for — the full "Know Normal, Find Evil" baseline.
Explore the Windows Process Genealogy10. Boot Modes & Recovery
Everything so far assumed a clean, normal boot — but not every boot is the boot. The same machine can start down very different roads, and attackers love the ones defenders forget (the security guards are often off-duty there). Your job is to spot which road was actually taken.
Same house, different doors. The front door is the normal boot; the side doors (Safe Mode, the recovery console) skip some of the locks — incredibly handy for repairs, and just as handy for burglars.
Safe Mode
Boots a minimal set of drivers and services — variants: Minimal, Network, and Alternate Shell (Command Prompt). Selected via the boot menu or bcdedit /set {default} safeboot …; state lives at HKLM\SYSTEM\CurrentControlSet\Control\SafeBoot.
Forensic Role: Many EDR/AV agents don't start in Safe Mode, so attackers force a Safe-Mode boot to disable defences (MITRE T1562.009). Malware that adds itself under the SafeBoot keys to survive there is a strong red flag.
WinRE — Recovery Environment
A mini-OS (winre.wim) on the Recovery partition, launched after two failed boots or via Shift+Restart (BCD recoverysequence). Offers Startup Repair, Reset, System Restore, and a Command Prompt.
Forensic Role: Abused for the "utilman/sethc" cmd-swap to get SYSTEM at the lock screen, by ransomware to stage outside the OS, or via a tampered winre.wim. Inspect the Recovery partition and reagentc /info.
Last Known Good (LKG)
Windows keeps numbered control sets and a "Last Known Good" pointer at HKLM\SYSTEM\Select. Booting LKG rolls back to the control set from the last successful logon — undoing a bad driver/service change.
Tells you which ControlSet00x was active — important when parsing the SYSTEM hive offline.
Advanced Startup / Boot Menu
The modern recovery menu (and legacy F8) exposes debugging, driver-signature-enforcement toggles, boot logging, and the firmware (UEFI) settings — all driven by the BCD.
Forensic Role: A BCD set to nointegritychecks / testsigning, or DSE disabled, lets unsigned drivers load — check it (see §2).
Investigator checklist
- Confirm which mode actually booted (event log +
SafeBoot/ BCD state) — a normal user rarely runs Safe Mode. - Check the
SafeBoot\Minimal&\Networkkeys for malware-added entries. - Mount and inspect the Recovery partition; hash
winre.wimagainst known-good; reviewreagentc /info. - Note the active ControlSet from
HKLM\SYSTEM\Selectbefore parsing the SYSTEM hive.
📂 11. The Cast of Characters: Key Files & Handovers
We've followed the relay all the way from power to desktop. Now let's lay every key player and hand-off on one table — because in the heat of a real exam you won't reread the whole story, you'll want one page that answers "what is this file and who launched it?"
This is the recap card at the end of the tour: every file, where it lives, and who passes the baton to whom.
| Handover Phase | The "Briefcase" (Data Shared) | Why it Matters |
|---|---|---|
| Firmware → Boot Manager | UEFI System Table | Rootkits can "hook" this table to hide themselves. |
| Boot Manager → Winload | BCD Settings | If security checks are OFF in the BCD, the system is at risk. |
| Winload → Kernel | LOADER_PARAMETER_BLOCK | The most critical handover. Contains the registry hive and driver list. |
| Kernel → SMSS.exe | Handover to User Mode | Transition from "Ring 0" (Kernel) to "Ring 3" (User). |
📁 Key Artifact Locations — Quick Reference
| Artifact | Location | Notes |
|---|---|---|
| BCD | \EFI\Microsoft\Boot\BCD (on ESP) |
Use bcdedit to inspect |
| bootmgfw.efi | \EFI\Microsoft\Boot\ (on ESP) |
The UEFI Boot Manager |
| winload.efi | C:\Windows\System32\ |
Modern OS Loader |
| winresume.efi | C:\Windows\System32\ |
Resume from hibernation |
| ntoskrnl.exe | C:\Windows\System32\ |
The Windows Kernel |
| smss.exe | C:\Windows\System32\ |
First user-mode process |
| winlogon.exe | C:\Windows\System32\ |
Logon manager |
| boot.ini (legacy) | C:\boot.ini |
XP and earlier only |
| NTLDR (legacy) | C:\NTLDR |
XP and earlier only |
| NTDETECT.COM (legacy) | C:\NTDETECT.COM |
XP and earlier only |
| hiberfil.sys | C:\hiberfil.sys |
Hibernation / Fast-Startup memory image — analyse it |
| pagefile / swapfile | C:\pagefile.sys, C:\swapfile.sys |
Spilled volatile data — collect with the image |
| bootstat.dat | C:\Windows\bootstat.dat |
Boot-status / recovery state across reboots |
| Boot Prefetch | C:\Windows\Prefetch\NTOSBOOT-*.pf |
What was loaded during boot (+ layout.ini) |
| Amcache | C:\Windows\AppCompat\Programs\Amcache.hve |
Executed-binary evidence incl. drivers (hashes) |
| ShutdownTime | HKLM\SYSTEM\CurrentControlSet\Control\Windows\ShutdownTime |
Last clean shutdown (FILETIME) |
| BootExecute / KnownDLLs | HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\ |
Early boot persistence — verify defaults |
🕒 Boot & Shutdown Event-Log IDs — Build the Timeline
These IDs (mostly the System log) let you reconstruct exactly when the machine started, stopped, and whether it was clean or unexpected.
| Log / ID | Meaning |
|---|---|
| System 12 | Kernel started (OS boot) — carries the boot timestamp. |
| System 13 | Kernel shutting down (OS stop). |
| System 6005 / 6006 | Event Log started (boot) / stopped (clean shutdown). |
| System 6008 | Unexpected shutdown (dirty / crash / power loss). |
| System 6013 | System uptime (logged ~daily) — sanity-check the timeline. |
| System 1074 | Shutdown/restart initiated by a user or process (who & why). |
| System 41 (Kernel-Power) | System rebooted without a clean shutdown — crash or power cut. |
| System 27 (Kernel-Boot) | Boot type / ELAM & boot-driver status on this boot. |
| Security 4608 / 4609 | Windows starting up / shutting down (audit subsystem). |
| Security 4616 | System time changed — watch for anti-forensic clock tampering. |
12. Forensic Master Class: Where to Hunt?
Theory's over — this is where it all becomes muscle memory. We've built the map; now here's the exact sequence I run through whenever a boot is in question, so nothing obvious slips past under pressure.
It's your pre-flight checklist. Tick each item top to bottom and you won't forget to lower the landing gear.
- ✓ The ESP Partition: Mount it and check for rogue
.efifiles outside of\EFI\Microsoft\Boot\. - ✓ The BCD: Run
bcdedit /enum alland look fornointegritychecks = Yesortestsigning = Yes. - ✓ Secure Boot State: Check if Secure Boot is disabled via PowerShell (
Confirm-SecureBootUEFI) or NVRAM dumps. - ✓ SMSS.exe: Check the process tree. It must be a direct child of the System process (PID 4).
- ✓ winlogon.exe: Check for multiple instances per session or non-System32 directories.
- ✓ Legacy Systems: Check
boot.inifor unexpected ARC paths and verifyNTDETECT.COMhasn't been replaced. - ✓ Fast Startup: Confirm whether the last "shutdown" was a hybrid shutdown. Fully power off (or true Restart) before imaging, or record the NTFS dirty bit.
- ✓ Memory on disk: Recover and parse
hiberfil.sys(andpagefile.sys) for offline memory evidence. - ✓ Boot timeline: Pull System log IDs 12/13, 6005/6006/6008, 6013, 1074 and Kernel-Power 41 to reconstruct every start/stop and spot unexpected reboots.
- ✓ Boot drivers: Review services with
Start=0/1and verify each is signed — a malicious boot/system driver (BYOVD) loads before defences. - ✓ ELAM: Confirm Early-Launch Anti-Malware is enabled and that no "bad/unknown" driver was allowed to load.
- ✓ MBR & ESP: Hash MBR sector 0 / VBR against known-good; enumerate every
.efiin the ESP for rogue bootloaders. - ✓ TPM / Measured Boot: Check Secure Boot state and PCR values; unexpected BitLocker recovery prompts can mean boot tampering.
- ✓ Early persistence: Audit
BootExecute,KnownDLLsandPendingFileRenameOperationsunder Session Manager. - ✓ Clock tampering: Watch Security 4616 (system-time changed) — a classic anti-forensic move that corrupts timelines.
13. The Complete OS Cycle: Power → Desktop
You made it — so let's zoom all the way out and watch the entire journey as a single line, from the first spark of power to your living desktop. Every boot is just one turn of this same wheel: firmware hands to the loader, the loader to the kernel, the kernel to user mode, and user mode keeps spawning until the desktop is alive.
The handoff in detail: the boot phase you just read ends at smss.exe. From there the chain branches into Session 0 (services & security) and Session 1 (the interactive user) — too many parents and children to fit on one line. The Process Genealogy page picks up exactly at that handoff and expands the entire user-mode tree, with each process's path, parent, session, instance count, timing, and forensic baseline.
Continue the Cycle in the Process TreeRun this whole checklist in minutes with Crow-Eye
Everything in this guide — BCD & Secure Boot state, boot-start drivers, hiberfil.sys, the boot/shutdown event timeline, and BootExecute persistence — Crow-Eye collects and parses for you, so you can triage a boot in minutes instead of hours.