IRQL_NOT_LESS_OR_EQUAL

IRQL_NOT_LESS_OR_EQUAL is a Windows blue screen that stops the machine with a stop code such as 0x0000000A. It means that code — almost always a driver — accessed memory at a moment when it was not allowed to. Windows raises the “interrupt request level” (IRQL) to protect routines that must not be interrupted; a process running at a raised IRQL may only touch memory that is resident and safe at that level. When it reaches for something else, Windows detects the violation and halts with IRQL_NOT_LESS_OR_EQUAL to avoid corrupting the system.

What it means

Interrupt request levels are priority bands for processor work. Normal threads run at the lowest level, PASSIVE_LEVEL, where they may be paged out and wait for disk or network I/O. As the level rises, the code is given less freedom: at DISPATCH_LEVEL it can no longer be paged and may not wait on anything. Drivers use these levels to service hardware quickly and hand work back to the system safely.

The bug check fires when a routine running at a high level tries to touch memory that is only valid at a low level — for example, reading a page that has been swapped to disk while interrupts are masked. Because paging is illegal there, the reference cannot be satisfied and the whole machine stops. The message names the fault precisely: a reference (memory access) occurred at an IRQL that was not less than or equal to the required level.

The culprit is nearly always a third-party driver, not Windows itself. That is because drivers are the components that run at raised IRQL, and a single coding mistake in one — a missing bounds check or access to a freed buffer — is enough to trigger the halt. Faulty RAM makes the same crash more likely, because a single flipped bit can corrupt a driver's pointer and send it to the wrong address.

Common causes

• A buggy or outdated kernel driver, most often for graphics, network, Wi-Fi or storage hardware.
• Faulty or unstable RAM, including memory run with an aggressive overclock or XMP/EXPO profile.
• A newly installed program, antivirus or virtualisation tool that added a driver hook into the kernel.
• Corrupt system files or a failing disk that damages the code loaded into memory.
• Overheating or inadequate power delivery that makes an otherwise fine driver behave unpredictably.

How to fix it

1. Find the faulting driver. Read the dump. In Event Viewer check Windows Logs › System for the bug check, and open the memory dump (in C:\Windows\Minidump) with a tool such as WinDbg to see the module named by the !analyze -v command. That module is your prime suspect.
2. Update or roll back that driver. Install the latest version from the hardware vendor, or use Device Manager to roll back a driver that changed just before the crashes began. Perform a clean install for graphics drivers.
3. Test the memory. Run Windows Memory Diagnostic or MemTest86, testing each module separately. Disable any overclock or XMP/EXPO profile and retest before blaming software.

   mdsched.exe
   sfc /scannow
   DISM /Online /Cleanup-Image /RestoreHealth

4. Remove recent changes. If the BSODs began after installing a program or update, uninstall it, or use System Restore to go back to a point before the crashes started.
5. Repair and check the disk. Run sfc /scannow and DISM /Online /Cleanup-Image /RestoreHealth, then chkdsk to rule out file system and disk faults.

How to prevent it

Keep drivers on a short leash. Install them from the hardware vendor rather than from generic update bundles, and treat every new kernel-level program — antivirus, firewall, virtualisation, RGB or monitoring utilities — as something to add one at a time so a regression is easy to trace. Enable driver verifier only when you are actively hunting a fault, since it deliberately stresses drivers and can itself trigger blue screens.

On the hardware side, use memory and power supplies that are properly rated, keep the case clean and well cooled, and avoid pushing memory timings or clocks beyond what the platform is certified for. Enable Windows' automatic memory dump so that if a crash happens you keep the evidence, and let Windows Update finish before you install heavy low-level software. A stable, stock configuration prevents the great majority of these bug checks.