What Is a Kernel? The Code That Can Crash Every PC at Once

Updated: October 2026

Every app on your laptop has to ask permission before it touches the disk, the network or the memory of another program. The kernel is the part of the operating system that says yes or no, and the handful of programs allowed to run beside it can take the whole machine down with them. Here's what the kernel is, why drivers and security agents live there, and what one bad file showed IT teams about it.

What Is a Kernel?

A kernel is the core of an operating system. It sits between software and hardware, decides which program gets the processor next, hands out memory, and talks to devices through drivers. Every app reaches the hardware through the kernel, never around it.

The operating system is the bigger package: the kernel plus everything built on top, like the desktop, settings, file explorer and built-in apps. Windows runs on the Windows NT kernel (the file is ntoskrnl.exe). Android and every Linux distribution run on the Linux kernel. Macs and iPhones run on XNU.

You never see the kernel directly. You see what happens when it's unhappy, which on Windows is a blue screen.

Kernel Mode vs User Mode

A processor running Windows works in two modes, and the difference between them explains most of this post.

Apps run in user mode. Microsoft's driver documentation describes each app getting its own private slice of memory, so one app can't touch another's data. If an app crashes, it doesn't affect other apps or the operating system. Chrome dies, you reopen Chrome.

The kernel and the code loaded into it run in kernel mode. Here, everything shares a single memory space, with no walls between pieces. Microsoft puts the consequence plainly: if a kernel-mode driver crashes, the entire operating system crashes.

That's the trade. Kernel mode gets full access and pays for it with zero isolation. This short explainer walks through the same split with diagrams.

Drivers: The Guests That Live in the Kernel

A driver is the translator between the kernel and a piece of hardware: a graphics card, a network adapter, a storage controller, a printer. Many drivers need kernel mode, because they deal with hardware at a level user mode can't reach.

That's why a bad driver is the classic cause of a blue screen. The driver shares the kernel's memory, so one wrong write takes everything down. Our guide to the blue screen of death covers reading the stop code and the dump.

Keeping drivers current is the other half. The guide to updating drivers covers rolling them out across a fleet without surprises.

How much code lives in the kernel depends on its design. A monolithic kernel, like Linux, keeps drivers and core services inside. A microkernel keeps only the bare minimum inside and pushes the rest out to user mode. Windows and macOS use hybrid designs somewhere in between.

Why Security Agents Want Kernel Access

Endpoint security tools, like antivirus and EDR, have loaded parts of themselves into the kernel for years. There are three reasons.

They see everything. From the kernel, an agent watches every process start, every file open and every network connection, not just the ones an app chooses to report. They start early. A kernel driver can load during boot, before most malware gets a chance to run. And they're hard to kill. Malware running as a normal program can't simply switch off something that sits beneath it.

The cost is the one every driver carries. A security agent in the kernel isn't isolated either. If its code reads memory it shouldn't, the machine crashes, and because the agent loads at boot, it can crash again on every restart.

July 19, 2024: One File, 8.5 Million PCs

On Friday, July 19, 2024, CrowdStrike pushed a routine content update for its Falcon sensor at 04:09 UTC and pulled it at 05:27 UTC, 78 minutes later. Windows machines that were online and received it in that window crashed.

The first reports landed on r/sysadmin within minutes, with one admin watching 20 to 40 machines blue screen almost at once and replies adding servers and domain controllers to the list.

The mechanism was small. CrowdStrike's root cause analysis (August 6, 2024) says the update's template defined 21 input fields, while the sensor code supplied only 20. When the sensor's content interpreter reached for the 21st value, it read memory outside the array. In user mode, that bug would have killed one program. In kernel mode, it killed Windows, and because the sensor loads at boot, many machines went straight into a boot loop.

Microsoft estimated the damage the next day: 8.5 million Windows devices, less than 1% of all Windows machines. The share was small. The machines weren't: airline check-in desks, hospital systems, bank terminals and help desk laptops.

How Teams Got Machines Back

The fix was simple and slow. Boot each machine into Safe Mode or the recovery environment, delete the bad channel file (C-00000291*.sys in the CrowdStrike drivers folder), and restart. On a machine that won't stay up, no remote tool can reach it, so the first days meant hands on keyboards.

A few days in, CrowdStrike offered an opt-in cloud remediation. Because the sensor loads early in boot, it could quarantine the bad file on machines that came up long enough to check in. This thread from July 22, 2024 is where many admins first heard about it.

BitLocker made the manual fix slower. Getting to the files from the recovery environment needs the drive's recovery key, so teams that had keys escrowed and searchable moved faster than teams hunting through old spreadsheets.

What Microsoft Changed

The incident pushed Microsoft to rethink who gets to run in the Windows kernel. In its Windows Resiliency Initiative update on June 26, 2025, Microsoft said security products like antivirus and endpoint protection "can run in user mode just as apps do", with a private preview of the new Windows endpoint security platform going to security partners in July 2025.

The same update covers Quick Machine Recovery, a way for Microsoft to push targeted fixes to PCs that can't restart, through the Windows recovery environment. It's on by default for Windows 11 Home, and IT admins control it on Pro and Enterprise.

Moving security tools out of the kernel won't happen overnight, and vendors still need deep visibility. But the direction is clear: less third-party code where a single mistake stops the machine.

What It Means for IT Teams

You can't move your security agent out of the kernel yourself. You can shrink the blast radius when something in the kernel goes wrong.

1. Know what runs in your kernel. List every agent and driver that loads at boot on your fleet: security, backup, VPN, monitoring.
2. Ask vendors how updates roll out. Find out whether content updates are staged, and whether you can hold a group of machines back.
3. Keep BitLocker recovery keys reachable. Escrowed, searchable, and readable when the primary console is down.
4. Plan for machines that won't boot. Decide who gets hands on which devices, and in what order, before the day comes.
5. Turn on Quick Machine Recovery where it fits, once you've tested it on a pilot group.

The same caution applies to the changes you push yourself. OpenFrame runs scripts and bulk operations across devices with approval gates and rollback controls, so a risky change needs a tech's sign-off first and can be undone. For how the security tool involved compares in day-to-day use, our CrowdStrike Falcon review covers the product itself.

The kernel is the one place on a PC where there's no second chance. Know what you've let in there, and have a plan for the day it misbehaves.