IRQL_NOT_LESS_OR_EQUAL (0xA) Blue Screen: Driver or RAM?

IRQL_NOT_LESS_OR_EQUAL (bug check 0xA) means kernel code tried to touch a memory address it wasn’t allowed to touch at that moment. Windows was running at a raised interrupt request level (IRQL), where code may only use memory that can’t be paged out to disk, and the address was either paged out or simply invalid. Everything below applies to Windows 11 and Windows 10; recent Windows 11 builds may show a black stop screen instead of blue, with the same stop code.

In plain terms, something followed a bad pointer. Microsoft says the error usually appears after installing a faulty device driver, system service or BIOS. Failing or unstable RAM, including XMP/EXPO and overclock settings, is the usual hardware suspect, because a flipped bit turns a good pointer into a bad one.

The fastest way to decide which: check what changed first. Reliability Monitor (perfmon /rel) lists drivers, updates and programs installed day by day beside each crash, and whatever arrived just before the crashes began is the prime suspect. If nothing changed, look past ntoskrnl.exe to the first third-party driver in two or three crash dumps: the same one each time means update or remove it, while a different module each time means test the memory first.

0xA vs 0xD1: same mistake, different place

You may see either of two closely related codes:

• DRIVER_IRQL_NOT_LESS_OR_EQUAL (0xD1): the bad access happened in a driver’s own code. When Windows can identify that driver, Microsoft says its name is printed on the 0xD1 blue screen, so this one is usually quicker to solve.
• IRQL_NOT_LESS_OR_EQUAL (0xA): the bad access can happen inside Windows’ own code, often because a driver handed it a bad pointer. The dump frequently blames ntoskrnl.exe, which is where it broke, not who broke it.

For you they mean the same thing: find the driver that used a bad address, or prove the memory is flipping bits. With a 0xD1 dump open in WinDbg, dx KiBugCheckDriver prints the driver Windows identified.

Match the crash to what you were doing

IRQL crashes tend to repeat under the same conditions, and the trigger narrows the suspect list quickly:

Decode the four parameters

If the timeline and trigger haven’t named a suspect, the dump’s four parameters can. Read them as Parameter 1 to Parameter 4 in Reliability Monitor (in hex, without the 0x) or Arg1 to Arg4 in WinDbg; our blue screen of death guide shows where to find them.

Two worked readings

A 0xD1 with parameter 1 = 0x0000000000000010, parameter 3 = 0x0, and ln on parameter 4 landing in a Wi-Fi driver. On a 0xA, the same driver usually shows up a few lines down STACK_TEXT instead, below the kernel function it called. A read from address 0x10 is a null pointer plus a small offset: the driver used a structure that was never set up. That’s almost certainly a bug in that driver, so update or roll it back; a memory test is unlikely to help unless the module and address start changing between crashes.

Three dumps, three different parameter 1 values that look like valid kernel addresses, and three different modules. No single driver is following the same bad path; something is corrupting memory underneath them all, either failing RAM or a driver overwriting memory it doesn’t own. Run the memory checks below first; if the RAM passes, Driver Verifier (the last driver step below) can catch the culprit.

Fix the driver side

1. Identify the file. Take the name from the screen or the dump’s IMAGE_NAME, then run lmvm plus the module name without its extension (the dump’s MODULE_NAME) for its version and date: lmvm nvlddmkm, not lmvm nvlddmkm.sys. Two you’ll often meet: nvlddmkm.sys is NVIDIA’s display driver, and Netwtw*.sys files are Intel Wi-Fi drivers.
2. Look past Windows’ network stack. If the dump blames ndis.sys, tcpip.sys or netio.sys, those are Windows networking components; the real cause is usually a network adapter, VPN or firewall driver plugged into them. Microsoft’s own worked example of an NDIS crash was resolved by disabling the network device.
3. Roll back or update. If a driver changed just before the crashes started, use Roll Back Driver on the device’s Driver tab in Device Manager. Otherwise install the current version from the PC maker, which is tested for your model even if it trails the chip maker’s release.
4. Confirm by disabling. Right-click the suspect device in Device Manager and choose Disable device for a day. No crashes means you’ve found it.
5. Test without third-party security, VPN and backup software. Uninstall rather than just turning it off, because the drivers keep loading otherwise. On a work PC, ask whoever manages it first; company antivirus, EDR or VPN may be required by policy. Keep your license details for the reinstall, and confirm Microsoft Defender Antivirus is on in Windows Security > Virus & threat protection.
6. Rule out a background service. Microsoft lists faulty system services alongside drivers. Run msconfig, select Hide all Microsoft services on the Services tab, then Disable all, and restart. If the crashes stop, re-enable half the services at a time to find the culprit; if they don’t, look at drivers or hardware, because a clean boot still loads drivers. Select Normal startup on the General tab afterward.
7. Still nothing? Driver Verifier’s standard settings include Force IRQL Checking, which exists to catch exactly this bug. It crashes the PC on purpose when a verified driver breaks a rule and can stop Windows reaching the desktop, so back up, have your BitLocker recovery key, verify only the suspect third-party drivers, and turn it off afterward with verifier /reset (from Safe Mode if needed). The Driver Verifier steps in the blue screen of death guide linked above cover the full precautions.

Crashed during a Windows upgrade? Prepare before retrying

Microsoft singles out upgrades, including the move from Windows 10 to Windows 11 and between Windows 11 versions: stop code 0xA during the upgrade is often a device driver, system service, virus scanner or backup tool that isn’t compatible with the new version. Windows normally rolls back on its own, so you can prepare a cleaner second attempt.

First open Settings > Windows Update. If the new version isn’t offered and the page says it’s on its way, Microsoft has placed a safeguard hold on your PC for a known compatibility problem, and recommends not upgrading manually, such as with installation media, until it’s released. If the upgrade is offered, prepare like this:

1. Uninstall third-party antivirus, VPN and backup software. Reinstall versions that support the new Windows after the upgrade.
2. Install the PC maker’s latest BIOS, chipset, storage, network and graphics drivers for your model. Before the BIOS update, back up, save your BitLocker recovery key, suspend BitLocker and keep a laptop plugged in: an interrupted BIOS update can leave the PC unable to start.
3. Disconnect docks, USB hubs, card readers and any other non-essential devices for the upgrade.
4. Try again, and if it fails at the same point, note the module named on the screen or in the dump: that’s the driver to replace before the next attempt.

If the upgrade succeeds but 0xA starts in the following days, Settings > System > Recovery > Go back returns to the previous version, usually for 10 days. It keeps your personal files but removes apps and drivers installed since the upgrade and undoes settings changes, so back up first. In an office, upgrade one PC of each model first and let it run a week before the rest follow.

Crashes at startup or in a restart loop

If 0xA hits before you can sign in, or within minutes of every start, get into Safe Mode using the recovery-environment steps in the blue screen of death guide linked above, with your BitLocker recovery key ready. What the result means for 0xA:

• Stable in Safe Mode: a third-party driver or service is responsible, most often the network, VPN, USB or utility driver from the trigger table above. Roll it back or disable it in Device Manager, then restart normally.
• Crashes in Safe Mode too: few third-party drivers are left to blame, so go straight to the memory checks below.

If every start ends on the repair screen instead, our automatic repair loop guide covers Uninstall Updates and System Restore in a data-safe order before resetting Windows.

Rule memory in or out

Bad RAM produces IRQL crashes because a single flipped bit turns a valid pointer into garbage. Suspect it when the faulting module and parameter 1 change from crash to crash, or when 0xA alternates with MEMORY_MANAGEMENT or PAGE_FAULT_IN_NONPAGED_AREA.

1. Turn off XMP or EXPO profiles and any overclock in the BIOS/UEFI setup, then use the PC for a day.
2. Run Windows Memory Diagnostic (mdsched.exe) and choose Restart now and check for problems. When the test starts, press F1, set Test Mix to Extended and press F10; it takes much longer than the default Standard pass.
3. On PCs with removable RAM, test one module at a time in the same slot to separate a bad module from a bad slot.

Our memory management blue screen guide covers RAM testing in depth, including why one clean pass isn’t proof.

When it’s hardware, and when to stop

• Any memory test error: replace the module. Avoid saving important work on that PC in the meantime, because bad RAM can silently corrupt files as they’re written.
• Crashes only with one physical device attached, even after driver and firmware updates: the device or its port may be faulty.
• Intel 13th or 14th Gen Core desktop processor, crash details that keep changing, RAM tests that pass: possibly the instability Intel has confirmed in some 13th and 14th Gen desktop chips. Install the latest BIOS, with the precautions above; our clock watchdog timeout guide covers Intel’s current microcode and warranty guidance.

If you’d rather not do this yourself, this is a typical $59 remote fix: with your permission, a technician connects, decodes the dumps, tells you whether it’s a driver or memory, and updates or rolls back the right driver. Failing memory has to be replaced in person. See how remote support works.

Common questions

Is IRQL_NOT_LESS_OR_EQUAL a hardware or software problem?

Usually software. Microsoft describes the cause as kernel-mode drivers using improper addresses, typically after a faulty driver, system service or BIOS was installed. Hardware enters through RAM, where a flipped bit corrupts a pointer. If the same third-party driver appears in every crash, it’s software; if the module and address change every time, test the memory.

What does IRQL mean?

IRQL stands for interrupt request level, the priority a processor is running at. At raised levels, such as DISPATCH_LEVEL, code can’t wait for memory to be loaded from disk, so it may only touch memory that can’t be paged out. The stop code means some kernel code broke that rule or used an address that was invalid altogether.

Why does the crash dump blame ntoskrnl.exe?

ntoskrnl.exe is the Windows kernel, and with 0xA the bad access often happens inside a kernel routine that a driver called with a bad pointer. The kernel is where the fault surfaced, rarely its cause. Look further down STACK_TEXT for a third-party driver and compare several dumps. If no driver repeats, test the RAM.

Can a Windows update cause IRQL_NOT_LESS_OR_EQUAL?

Yes, indirectly. An update can deliver a new driver that misbehaves on your hardware, or a feature update can expose an old driver, antivirus or backup tool that isn’t compatible with the new version. Check Reliability Monitor for what installed that day and roll back that driver first. Uninstall a Windows update only as a last resort, because that also removes its security fixes, and reinstall it as soon as a fixed driver or update is available.

Does IRQL_NOT_LESS_OR_EQUAL mean my RAM is bad?

Not necessarily; drivers are the more common cause. RAM becomes the lead when crashes are random, the faulting module keeps changing, other memory-related stop codes appear, or the crashes began after adding memory or enabling XMP/EXPO. A single error in an extended memory test at default memory settings, with XMP/EXPO off, is enough reason to replace the module.

Why do I get IRQL_NOT_LESS_OR_EQUAL while installing Windows from a USB drive?

During a clean install almost only Windows’ own drivers are running, so a third-party driver bug is unlikely. A 0xA at this stage points more strongly to memory, a memory or CPU overclock, or another hardware fault. Turn off XMP or EXPO and any overclock in the BIOS setup, run the PC maker’s built-in hardware diagnostics, and test one memory module at a time if you can before trying different installation media.