I’ve chased this exact error across four different machines over the years — two laptops with flaky Wi-Fi drivers and a desktop that turned out to have a single bad RAM stick. The blue screen looks identical every time, but the cause is rarely the same twice. That’s what makes it annoying to search for: most guides give you one fix and hope it sticks.

This one walks through the fixes in the order I actually try them, starting with the least invasive. If a fix earlier in the list doesn’t solve it, move to the next one — don’t skip ahead.

What Actually Causes This Error

IRQL stands for Interrupt Request Level — it’s how Windows decides which processes get priority access to system resources at any given moment. When a kernel-mode driver tries to read or write to a memory address it isn’t cleared to touch at its current priority level, Windows halts everything and throws this stop code rather than risk corrupting data.

A minidump analysis will often point to ntoskrnl.exe as the faulting module. That’s misleading if you’re not used to reading crash dumps — ntoskrnl.exe is the Windows kernel itself, and it’s just the component that catches the error, not the one that caused it. The real culprit is almost always a third-party driver sitting underneath it: a graphics driver, a Wi-Fi adapter driver, a storage controller driver, or occasionally security software hooking into the kernel.

The most common triggers I’ve seen, roughly in order of how often they show up:

• Outdated or corrupted device drivers — graphics and network adapters are the repeat offenders
• Faulty or failing RAM modules
• A recent Windows Update or driver update that shipped with a bug
• Overclocked CPU, GPU, or RAM running unstable
• Antivirus or security software conflicting with kernel-level processes
• A failing hard drive, SSD, or loose SATA/NVMe connection
• Outdated BIOS/UEFI firmware, especially after a CPU or RAM upgrade

Before You Start: Back Up Anything Important

Repeated crashes stress the file system more than people realize, and a hard shutdown mid-write is one of the ways drives end up unreadable. If you store photos or documents locally, it’s worth getting them off the machine before you start driver surgery — if you’re on an iPhone, here’s how to move your photos to a PC without needing iTunes. And if any of your storage is on a memory card that’s started acting strange, check out this guide on fixing a microSD card that’s dropped into RAW file system before you assume it’s unrelated — corrupted storage and IRQL crashes sometimes show up together.

Method 1: Run Windows Memory Diagnostic

I start here because bad RAM produces this exact error message, and it’s the fastest thing to rule out. Open the Windows search bar and type Memory Diagnostic. The Windows Memory Diagnostic desktop app will show up in the results on every supported version of Windows.

Open it and choose Restart now and check for problems. Windows reboots into a diagnostic environment and runs a full memory test automatically — you don’t need to configure anything. Let it finish; it typically takes 10 to 20 minutes depending on how much RAM is installed. Once it’s done, the PC boots back into Windows and you’ll get a notification with the results, or you can check the Event Viewer under Windows Logs → System and search for “MemoryDiagnostics-Results.”

If it flags errors, the fix is physical: reseat the RAM sticks, test them one at a time in different slots, or replace the failing module. If it comes back clean, move to Method 2.

Method 2: Change the Disk Drive Removal Policy

This one sounds unrelated to a driver crash, but it fixes IRQL errors more often than people expect — especially on machines where the crash happens during heavy disk activity. Open Device Manager from the search bar, expand Disk drives, and double-click the disk listed there.

Go to the Policies tab and select Quick removal instead of the default write-caching-enabled option. Click OK. Windows may prompt you to restart to apply the hardware change — accept it. Quick removal disables write caching for that disk, which trades a small amount of write performance for a lot more stability, and it stops several classes of IRQL crashes tied to disk controller drivers.

Method 3: Disconnect Unnecessary Peripheral Devices

If the first two methods don’t resolve it, unplug everything that isn’t strictly required to run the computer — USB flash drives, external speakers, webcams, secondary monitors’ USB hubs, and anything else connected over USB. A single misbehaving peripheral driver can trigger this error even though the device itself looks completely unrelated to memory management.

This isn’t limited to USB sticks either. I’ve seen network-connected devices cause similar driver-level instability — one reader’s setup kept throwing errors that traced back to a flaky print driver, similar to what’s covered in this guide on fixing a printer that keeps going offline on a wireless network. If a device disappearing from the desk makes the crashes stop, you’ve found your culprit — go update or replace that device’s driver specifically.

Method 4: Update or Roll Back Your Drivers

This is the fix that solves it most often, and it’s worth doing properly rather than just clicking “update driver” in Device Manager, which frequently reports “the best driver is already installed” even when it isn’t.

Go directly to the manufacturer’s site — AMD, NVIDIA, or Intel for graphics; Intel, Realtek, or Killer for network adapters — and download the latest driver package manually. During installation, choose the custom or clean install option if it’s offered, since that removes leftover configuration files from the previous driver that can otherwise keep causing conflicts.

If the crashes started right after a driver update, go the other direction: open Device Manager, right-click the device, choose Properties → Driver tab, and use Roll Back Driver if the option is available. One thing worth flagging: if your download of the new driver installer keeps failing or stalling partway through, that’s usually a browser issue rather than a driver problem — this guide on fixing downloads that stop midway in your browser covers the fix.

Method 5: Run SFC and DISM Scans

Corrupted system files can produce the same symptoms as a bad driver. Open Command Prompt as administrator and run:

Run sfc /scannow first — it checks and repairs protected system files. Then run the DISM command, which repairs the underlying Windows image that SFC pulls its replacement files from. Restart once both finish.

Method 6: Use Driver Verifier to Catch the Exact File

If you’ve made it this far and it’s still crashing, stop guessing and let Windows tell you exactly which driver is at fault. Search for Verifier in the search bar, run it, and select Create custom settings → select all the standard checks → choose Automatically select all drivers installed on this computer. Restart.

Driver Verifier stresses every driver on the system, which forces an unstable one to crash faster and produces a minidump that names the actual file responsible. Once you’ve got the crash (usually within one to three reboots), turn Verifier back off by running verifier /reset from an elevated Command Prompt — running it long-term slows the system down noticeably.

Method 7: Undo Overclocks and Check BIOS Updates

If you’ve overclocked your CPU, GPU, or RAM (including enabling XMP/DOCP memory profiles), reset everything to stock speeds in the BIOS and see if the machine stabilizes. Unstable overclocks are a frequent, underreported cause of this exact stop code because the instability shows up as random memory access violations rather than an obvious crash pattern.

Separately, check your motherboard manufacturer’s site for a newer BIOS/UEFI version, particularly if you’ve recently upgraded RAM or a CPU. An outdated BIOS can misreport memory timings to Windows in a way that produces IRQL errors even on otherwise healthy hardware.

Method 8: Clean Boot to Rule Out Background Software

Third-party antivirus tools and startup apps sometimes hook deep enough into the kernel to trigger IRQL faults. Open System Configuration (type msconfig in the search bar), go to the Services tab, check Hide all Microsoft services, then click Disable all. Restart.

If the crashes stop, re-enable services in small batches to isolate the one causing it. This is also a good moment to trim your startup apps in general — background apps that auto-launch, like Spotify constantly relaunching itself, add unnecessary load during boot. If that’s been bugging you separately, here’s how to stop Spotify from opening automatically on Windows startup.

Method 9: System Restore or Clean Install (Last Resort)

If nothing above works, a System Restore to a point before the crashes started can undo whatever changed. If you don’t have a usable restore point, a clean install of Windows wipes out any corrupted drivers or system files that survived every other fix. It’s disruptive, but it’s a genuinely reliable last step — reinstalling gives you a known-good baseline instead of guessing at what’s still broken.

Which Fix Should You Try First?

Here’s how the methods stack up on time investment and how often each one actually resolves the crash, based on the order I run through them:

Watch: Diagnosing BSOD Crashes

If you’d rather watch someone walk through minidump analysis and driver troubleshooting instead of reading through it, this is a solid companion to the steps above:

FAQ

What does DRIVER_IRQL_NOT_LESS_OR_EQUAL actually mean?

It means a driver running in kernel mode tried to access a memory address it wasn’t permitted to access at its current interrupt priority level. Windows stops the system immediately rather than risk memory corruption, which is why it shows as a blue screen instead of a slower failure.

Is this always a hardware problem?

No. Most cases are software — an outdated or buggy driver — rather than failing hardware. Bad RAM and failing drives cause a smaller share of cases, which is why running Memory Diagnostic early saves time by ruling that path in or out quickly.

Why does the crash dump point to ntoskrnl.exe?

ntoskrnl.exe is the core Windows kernel file, and it’s frequently listed in the crash simply because it’s where Windows caught the illegal memory access — not because it’s the actual cause. Use Driver Verifier if you need the specific driver named.

Will these fixes work every time?

No single method resolves every case, since the underlying cause varies from machine to machine. Working through the methods in order — starting with memory and disk checks, then moving to drivers, then Driver Verifier — resolves the large majority of cases without needing a full reinstall.

How do I read a minidump file myself?

Windows saves crash dumps in C:\Windows\Minidump. Free tools like WinDbg (from the Microsoft Store) or BlueScreenView can open them and show which driver file was active when the crash happened, which speeds up diagnosis considerably compared to trial and error.

Conclusion

DRIVER_IRQL_NOT_LESS_OR_EQUAL is frustrating precisely because it can come from so many different places, but it’s also one of the more fixable blue screens once you work through the list methodically. Start with the memory test, tweak the disk removal policy, and get your drivers current — that combination clears the majority of cases I’ve come across. If it’s still happening after that, Driver Verifier will do the detective work for you instead of leaving you guessing.

These methods won’t resolve every single instance of this error — a small percentage come down to failing hardware that needs physical replacement — but they cover the cases you can fix yourself without a repair shop.