IRQL_NOT_LESS_OR_EQUAL: Causes and How to Fix It

IRQL_NOT_LESS_OR_EQUAL is bug check 0x0000000A. A kernel-mode driver tried to read memory that wasn’t there while running at a raised interrupt request level. It is a driver fault far more often than a hardware fault, and the driver is usually network, graphics or audio.

What the stop code is actually saying

Kernel code runs at different interrupt request levels. Above a certain level the memory manager can’t service a page fault, so code there may only touch memory guaranteed to be resident in RAM. Reach for pageable memory anyway, or follow a pointer to an address that no longer exists, and Windows stops the machine rather than let it corrupt itself.

Microsoft’s reference for bug check 0xA records four parameters with each crash:

Parameter	What it is	Why it matters
1	The memory address that couldn’t be accessed	A value below `0x1000` points to a null pointer dereference
2	The IRQL at the moment of the fault	A value of 2 means the fault happened at DISPATCH_LEVEL
3	Whether the operation was a read, a write or an execute	An execute fault means pageable code was called at too high an IRQL
4	The instruction pointer at the time of the fault	This address resolves to the offending function

Nothing inside Windows repairs that code. The job is to find the driver and roll it back, replace it or remove it.

Step 1: Read the blue screen before it disappears

Windows prints the stop code at the bottom of the blue screen, and when it can attribute the crash to a single binary it adds a What failed line naming the file. That .sys name is the strongest free clue you will get, so photograph it. If the screen clears too fast, do what you would when chasing a Start menu crash on a machine that keeps rebooting: let it happen once more and be ready.

File named	Belongs to	Typical trigger
`nvlddmkm.sys`, `amdkmdag.sys`, `igdkmd64.sys`	NVIDIA, AMD, Intel graphics	Gaming, video playback, waking from sleep
`ndis.sys`, `netio.sys`, `tcpip.sys`	The networking stack	Large downloads, joining Wi-Fi, a VPN connecting
`e1d68x64.sys`, `rt640x64.sys`	Intel and Realtek Ethernet	Wake-on-LAN, transferring large files
`ntoskrnl.exe`	The Windows kernel itself	Almost never the real culprit

If Windows names ntoskrnl.exe, it has failed to identify the guilty driver. The kernel was just the last thing on the stack. Treat that as “unknown”, not as “Windows is broken”.

Step 2: Open the minidump

Windows writes a small crash dump on every bug check, and Microsoft documents that these small memory dump files are kept in %SystemRoot%Minidump with the crash date encoded in each filename.

NirSoft’s free BlueScreenView reads that folder without a debugger and lists each crash with its bug check code and, in the lower pane, the modules that were on the call stack. Ignore the “Caused By Driver” column when it reads ntoskrnl.exe and look at the highlighted third-party .sys files instead. If the same non-Microsoft driver shows up across three or four dumps, you have your suspect.

To see who ships a file you don’t recognise, run this as administrator:

pnputil /enum-drivers

It lists every third-party driver package with its provider and version.

Step 3: Check Event Viewer for what happened just before

The dump says what crashed. The System log says what was happening at the time. Open Event Viewer, expand Windows Logs, select System, then use Filter Current Log and tick Critical and Error. Look either side of the crash for a driver that timed out or a device that reset.

The same query from PowerShell, run as administrator:

Get-WinEvent -FilterHashtable @{LogName='System'; Level=1,2; StartTime=(Get-Date).AddDays(-7)} |
    Select-Object TimeCreated, Id, ProviderName, Message |
    Format-List

Two entries always follow a bug check: one from BugCheck repeating the stop code and dump path, and a critical Kernel-Power entry for the unclean reboot. What sits immediately before them is the interesting part.

Which situation are you in?

Pattern	Most likely cause	Go to
Started right after a driver or Windows update	The new driver package	Fix 1
Only crashes in games or under GPU load	Graphics driver, or an unstable GPU overclock	Fix 1, then Fix 4
Crashes when a VPN connects or during downloads	Network or VPN filter driver	Fix 2, then Fix 3
Crashes on wake from sleep or on shutdown	Chipset, storage or network power management	Fix 2
Random, several different `.sys` names in the dumps	Memory, or an unstable RAM profile	Fix 4
Started after installing security software	Antivirus filter driver	Fix 3

Work down from the row that matches. Changing six things at once tells you nothing about which one mattered.

Fix 1: Roll back or clean-install the graphics driver

Roll back if the trouble began after an update. In Device Manager, expand Display adapters, right-click the GPU, choose Properties, then the Driver tab, then Roll Back Driver. If that button is greyed out, Windows has no previous package stored.

Clean-install if rollback isn’t available. Take the driver from AMD, NVIDIA or Intel directly rather than from Windows Update, and use the clean or factory-reset option in the vendor’s installer. That strips the old installation’s leftovers instead of layering a new driver over a damaged one, which is why an ordinary reinstall so often changes nothing. If one release broke things, install the previous stable version from the vendor’s archive.

Fix 2: Get chipset, network and audio drivers from the manufacturer

Windows Update ships generic, conservative driver packages, and bundled driver-pack utilities are worse still because they install versions never validated against your hardware. For chipset, Wi-Fi, Ethernet and audio, the version on the manufacturer’s support page is usually newer and always better matched to your board.

Find your machine by model number on the laptop maker’s support site, or by motherboard model for a desktop. Install chipset first, then network, then the rest. Chipset drivers register the bus and power management behaviour the others sit on, so installing them last wastes the effort.

Sound deserves its own pass. Realtek, Nahimic and vendor audio enhancement services install kernel filter drivers that sit directly in the audio path, and they turn up in 0xA dumps more often than people expect. If you have already been fighting a flaky audio driver here, that is a strong hint.

Fix 3: Remove antivirus, VPN and other filter drivers

Filter drivers insert themselves into the file system, network or audio stack and inspect everything passing through. They are the most under-suspected cause of 0xA on healthy machines, and Microsoft’s guidance for this bug check names virus scanners and backup tools as things to disable and test.

The usual suspects:

Third-party antivirus and endpoint security suites
VPN clients, particularly ones that install their own virtual adapter
Anti-cheat drivers installed by games
Virtual audio cable and streaming software
RGB, fan control and monitoring utilities that read hardware sensors directly

Uninstalling from Settings often leaves the kernel driver behind, so use the vendor’s removal tool where one exists. Remove one product at a time and give each change a couple of days.

Fix 4: Take the overclock off and test the memory

Set the firmware back to stock: CPU multiplier, any manual voltage or undervolt curve, the GPU overclock in whatever tool applies it, and the memory profile. XMP and EXPO profiles are overclocks whatever the marketing calls them, and an unstable one produces this exact bug check with a different driver each time.

Press Win + R and enter mdsched.exe for the built-in memory test. It catches only obvious faults, so a clean pass is not proof the RAM is good. If crashes are random and the named driver keeps changing, run a longer overnight test or pull one stick.

Fix 5: Driver Verifier, and how to switch it back off

This finds the driver when nothing else has. It will also leave your PC in a reboot loop if you enable it without a plan.

Microsoft states plainly that running Driver Verifier can cause the computer to crash, and that it should only be run on machines used for testing and debugging. That warning is not decoration. Verifier stresses drivers until one misbehaves, then bug checks the system on purpose. If the failing driver loads at boot, Windows crashes during startup.

Do two things first. Create a restore point, and make sure you know how to reach Safe Mode, because that is where you will be undoing this. Then set the safety net, from an administrator Command Prompt:

verifier /bootmode resetonbootfail

Microsoft documents that mode as disabling Driver Verifier for subsequent reboots if the system failed to start, which turns a permanent boot loop into one bad restart.

Now run verifier on its own to open Driver Verifier Manager, choose Create custom settings, and select drivers from the list. Pick only the non-Microsoft ones: verifying everything adds enormous overhead and buries you in results you cannot act on. Restart, use the machine, and the next dump will name the driver that failed.

Switch it off the moment you have an answer:

verifier /reset

Restart afterwards. If Windows will not boot, start in Safe Mode, open an administrator Command Prompt, run the same command and restart. verifier /querysettings confirms nothing is still armed.

Fixes that don’t do what people think

sfc /scannow and DISM. Worth running, but neither touches third-party drivers. They repair Windows component files, and a driver-caused 0xA survives both.
Increasing the page file. Unrelated to interrupt request levels. This bug check is about memory that isn’t resident, not memory that has run out.
Disabling Fast Startup. It sometimes shifts the timing enough to hide a crash on wake. The bad driver is still loaded.
Registry cleaners. No mechanism exists by which these repair a kernel-mode memory fault.
Reinstalling Windows. It clears a software-caused 0xA, but only until you reinstall the same driver. Treat a clean Windows reinstall as a reset rather than a fix. For the other codes, see our guide to every Windows stop code and what it means.

Common questions

Is IRQL_NOT_LESS_OR_EQUAL a RAM problem or a driver problem?

It is a driver problem in most cases. Bug check 0xA fires when kernel-mode code accesses an invalid address at a raised interrupt request level, which is a pointer or pageability fault. Faulty RAM and unstable memory overclocks produce the same symptom, so test memory after ruling out drivers.

What does IRQL stand for?

IRQL means interrupt request level, the priority at which a piece of kernel code is running. The stop code name refers to the check that failed: the IRQL was not less than or equal to the level required to safely touch that memory. Higher levels forbid access to pageable memory.

Can I fix IRQL_NOT_LESS_OR_EQUAL without reinstalling Windows?

Usually yes. Identify the driver from the minidump files in %SystemRoot%Minidump, then roll it back, clean-install it from the manufacturer, or uninstall the software that installed it. Reinstalling Windows removes the driver too, but the crash returns as soon as you reinstall that driver.

How do I turn off Driver Verifier if Windows will not boot?

Start Windows in Safe Mode, open Command Prompt as an administrator, run verifier /reset, then restart normally. Setting verifier /bootmode resetonbootfail before you enable Verifier tells Windows to disable it automatically after a failed startup, which avoids the boot loop entirely.

Why does the minidump blame ntoskrnl.exe?

Ntoskrnl.exe is the Windows kernel, and it appears near the top of nearly every crash stack because it is the code that raises the bug check. It is almost never the real cause. Look further down the stack for third-party .sys files instead.

Find the driver before you change anything: two or three minidumps naming the same .sys file will save you a week of guesswork.