DRIVER_IRQL_NOT_LESS_OR_EQUAL: Finding the Driver Behind It

A laptop blue-screens twice a week and the stop code names a driver that nobody on the team has heard of. The stop code tells you what went wrong in the kernel, and the dump file usually tells you which driver did it. This guide walks through DRIVER_IRQL_NOT_LESS_OR_EQUAL from the four parameters to the fix, on one PC and across a fleet.

What the Stop Code Means

Windows runs kernel code at priority levels called interrupt request levels, or IRQLs. At the higher levels the kernel can't stop and wait for memory to be read back from disk. So any memory touched at that level has to be resident in RAM, and the address has to be valid.

DRIVER_IRQL_NOT_LESS_OR_EQUAL means a kernel-mode driver broke that rule. Microsoft's reference for bug check 0xD1 describes it as a driver trying to access pageable memory while the IRQL was too high. The usual triggers are a bad or freed pointer, pageable data, or pageable code used at DISPATCH_LEVEL.

Its sibling, IRQL_NOT_LESS_OR_EQUAL, is bug check 0xA. The failure is the same kind, but the fault can sit in Windows itself or in a driver. Microsoft adds a line worth remembering: the error "usually occurs after the installation of a faulty device driver, system service, or BIOS."

The practical difference is small. With 0xD1, Windows is confident a driver did it and often prints the driver's name on the screen. With 0xA, you do more of the digging yourself.

Read the Four Parameters First

Every bug check carries four parameters. You'll find them on the blue screen, in the System log entry for the crash, or at the top of the debugger output. They take ten seconds to read and they narrow the search more than any driver-update tool.

The parameter 1 rule comes from Microsoft's 0xA reference. If the address is below 0x1000, the driver most likely followed a NULL pointer. That's a code bug in the driver, so no amount of cleaning the registry will fix it.

A May 2025 r/sysadmin thread shows the pattern on a real fleet. An admin found ThinkPad E14 laptops crashing every few days, only on machines that had taken recent Windows updates. Every dump named the same Realtek Wi-Fi driver, rtwlane601.sys, with stop code 0xD1 and parameter 1 at 0xf98:

Read those parameters with the table above and the story writes itself. A low address points to a NULL pointer, the IRQL is DISPATCH_LEVEL, and it's a read. The same driver shows up on every machine that took the update. That points at the new driver version.

Get the Dump Into WinDbg

Windows writes a small memory dump to C:\Windows\Minidump after each crash. Copy the folder off the machine first. A second crash or a cleanup tool can overwrite the file you need.

If the folder is empty, check the dump settings before the next crash. In System Properties, under Startup and Recovery, the write debugging information option should be set to small or automatic memory dump, and the page file needs to live on the system drive. Without a page file of a workable size, Windows has nowhere to stage the dump.

Install WinDbg with winget install Microsoft.WinDbg, open the dump, and run three commands:

code
!analyze -v
dx KiBugCheckDriver
lmvm rtwlane601

!analyze -v prints the bug check, the parameters and the stack. For 0xD1, Microsoft documents that the responsible driver's name is stored in KiBugCheckDriver, and dx displays it. lmvm then shows the driver's version and timestamp, which is what you need to match it to an update.

URTechDotCa's walkthrough covers the same flow on a live dump, including symbol setup:

When the Dump Blames ntoskrnl.exe

Sometimes the analysis names ntoskrnl.exe, the Windows kernel, as the cause. That's where the crash landed. The cause is usually further down the stack, so scroll for the last third-party module before the kernel frames. That module is your suspect.

If several dumps each blame a different driver, stop chasing drivers. Random culprits across crashes point at memory, and memory includes overclocked RAM profiles and the page file on a failing SSD. Run the Windows Memory Diagnostic and turn off XMP before you touch another driver.

This r/techsupport thread from August 2026 is a good example. A user had two IRQL_NOT_LESS_OR_EQUAL crashes in one day, both blamed on ntoskrnl.exe, after years of reinstalls. The dump reader's answer was that it looks like memory, and the first test was disabling XMP:

Our guide to XMP in BIOS explains why a RAM profile can pass a memory test and still crash under load.

The Usual Suspects

Microsoft's own remarks for 0xA name the usual categories: a faulty device driver, a system service or a BIOS. New hardware brings its own drivers. A BIOS update changes what every driver sits on.

In helpdesk queues, the names that come up again and again are Wi-Fi and Ethernet drivers, VPN clients and other network filter drivers, security agents, and storage or chipset drivers. They share one trait: they run in the kernel and handle interrupts, so a single bad pointer takes the whole machine down.

Upgrades deserve their own note. If 0xA appears during a Windows feature update, Microsoft points at drivers, services, virus scanners and backup tools that aren't compatible with the new version. Updating or removing the security agent and backup client before the upgrade, then reinstalling the current versions after, is the standard first move when a rollout stalls on this code.

Timing is the cheapest clue you have. If the crashes started the week a driver, agent or BIOS changed, start there. Our guide on updating drivers safely covers rollbacks and how to pin a known-good version.

Driver Verifier, Aimed at One Driver

When the dumps point at a driver but you can't prove it, Driver Verifier makes the driver fail loudly. Microsoft's Driver Verifier guide is blunt about the risk: it can crash the computer, and it belongs on machines you use for testing and debugging.

So aim it. Verify only the suspect, reproduce the crash, and turn it off:

code
verifier /standard /driver rtwlane601.sys
verifier /querysettings
verifier /reset

Restart after enabling and after resetting. A caught violation usually shows up as bug check 0xC4 with the driver named, which is the proof you take to the vendor. If the PC won't boot with Verifier on, our blue screen guide covers the Safe Mode route back out.

Fixing It Across a Fleet

One crash is a ticket. The same driver crashing on thirty laptops is a rollout problem, and the fix is a rollout too.

Start by collecting the evidence from every device instead of one. This PowerShell pulls recent crash events and the installed version of the suspect driver:

powershell
Get-WinEvent -FilterHashtable @{LogName='System'; Id=1001; StartTime=(Get-Date).AddDays(-30)} |
  Where-Object { $_.Message -match 'bugcheck' } |
  Select-Object TimeCreated, Message

Get-CimInstance Win32_PnPSignedDriver |
  Where-Object { $_.DeviceName -like '*Realtek*' } |
  Select-Object DeviceName, DriverVersion, DriverDate

Group the results by model and driver version. If every crashing device runs the same version and the clean ones don't, you have your answer without a debugger. Our list of PowerShell commands covers more ways to query devices remotely.

Then fix it the same way on every device. Roll back to the last good version, and stop Windows Update from reinstalling the bad one until the vendor ships a fix. The OEM's support site often lags behind the chip vendor, as the Realtek thread found, so check both. The Microsoft Update Catalog lets you pull a specific driver version by hand.

If you run OpenFrame, you can run both queries above as a script across a client's devices and collect the output from each one.

What to Do Next

DRIVER_IRQL_NOT_LESS_OR_EQUAL almost always has a name behind it. Read the four parameters, open the dump, and let the stack name the driver before you reinstall anything. When the blame moves around from crash to crash, test memory first.

For the wider picture of stop codes, dump settings and recovery options, read our guide to the Blue Screen of Death.