IRQL_NOT_LESS_OR_EQUAL: What 0x0000000A Reports

The machine was running normally, then the screen went blue and the text ended with IRQL_NOT_LESS_OR_EQUAL. The stop code is a rule name, not a diagnosis. It reports that code running at an elevated interrupt request level (IRQL) accessed memory in a way that is not permitted at that level. Windows halts rather than continue with state it cannot trust. The fault is almost always in a driver, in the memory the driver is using, or in a setting that makes the memory unreliable. The stop code tells you which rule was broken; the dump and the events around it tell you who broke it.

What an IRQL is, in one paragraph

Windows assigns every piece of code an interrupt request level. Ordinary application and most driver code runs at PASSIVE_LEVEL, where it can take faults, wait, and touch pageable memory. Code that services an interrupt runs at a higher IRQL, where it must not wait and must not touch memory that could be paged out. When code at a raised IRQL touches an address it is not allowed to touch at that level, the processor raises a page fault that cannot be serviced, and Windows bug-checks with 0x0000000A. The code names the rule, not the driver. The driver is identified from the stack in the crash dump.

Causes, in order of likelihood

1. A faulty or mismatched driver

A driver that was recently installed, updated, or replaced is the most common source. The mismatch can be a version written for a different build of Windows, a driver installed by a device utility, or a driver that was partially updated. The crash often begins after a specific event: a Windows update, a new peripheral, a graphics driver update, or a utility that installed a filter driver.

How to tell: the minidump names a driver in the stack, and the timing correlates with an install or update. Event Viewer may show a pattern of the same driver appearing before the bug check.

2. Unstable memory settings, including XMP

Memory running at an XMP or EXPO profile, or at a manual overclock, can produce intermittent IRQL faults even when the modules are healthy. The failure is in the signalling margin, not in the silicon. This cause is more common than genuinely dead RAM and is frequently missed because the machine passes a short memory test.

How to tell: the faults began after enabling XMP or changing memory settings, or they appear only under load. Disabling XMP and running at the JEDEC default for a period is the test.

3. Genuinely bad RAM

A failing module or an incompatible module produces the same stop code. This is the least common of the three but the most destructive if ignored.

How to tell: Windows Memory Diagnostic reports errors, or faults persist with XMP disabled and with a known-good module.

Diagnosis

Read the minidump

Windows writes a minidump to C:\Windows\Minidump after a bug check. The file is named with the date and a sequence number. Open the most recent one in a kernel debugger such as WinDbg, or use a dump analysis tool that reads the same format. The command !analyze -v in WinDbg prints the bug check parameters and the stack. The line beginning MODULE_NAME or the driver named in the stack is the starting point, not a verdict: a driver can appear in the stack because it was running when another driver corrupted memory.

Check Event Viewer

Open Event Viewer and look under Windows Logs > System for events around the crash time. Event ID 1001 records the bug check code and parameters. Events from a device or driver shortly before the crash are relevant. A pattern of the same source before each crash is stronger evidence than a single occurrence.

Test memory

Run Windows Memory Diagnostic from an elevated command prompt:

mdsched.exe

The tool offers to restart and test. The standard test is quick; the extended test takes longer and is more likely to catch marginal errors. Results appear after the restart in Event Viewer under Windows Logs > System, source MemoryDiagnostics-Results. A pass does not prove the memory is good, particularly with XMP enabled; a failure is strong evidence of a hardware or setting problem.

Use Driver Verifier as a last diagnostic step

Driver Verifier makes drivers fail fast when they break rules, which converts an intermittent fault into a reproducible one. It is a diagnostic, not a repair, and it can cause a boot loop if a driver fails immediately at startup.

Before enabling it, create a restore point. Then, from an elevated command prompt:

verifier /standard /all

Restart. If the machine boot loops, start in Safe Mode and run:

verifier /reset

Then restart normally. The dump produced under Verifier names the driver that violated the rule. Enable Verifier only for as long as it takes to reproduce the fault, and reset it afterwards.

Repairs, least destructive first

Disable XMP and return memory to default

Enter the firmware setup (UEFI/BIOS) at boot and disable the XMP or EXPO profile, or load the default memory settings. This changes no data. If the faults stop, the cause was the memory setting, not the modules. Run at default for long enough to cover the interval between previous faults before concluding.

Roll back or reinstall the named driver

Open Device Manager, locate the device whose driver appears in the dump, open its properties, and use the Driver tab. The Roll Back Driver button is available when a previous driver is stored. If it is not, uninstall the device and restart so Windows reinstalls the inbox driver, then install the vendor driver from the vendor’s site rather than from a utility.

Update or remove the offending software

If the dump names a filter driver from a backup, antivirus, or virtualisation product, update that product to a version that supports the current Windows build, or remove it and use the built-in equivalent. A filter driver written for an earlier build is a common source after a feature update.

Repair system files

Corrupted system files can produce the same stop code. Run, from an elevated command prompt:

sfc /scannow

If SFC reports corruption it cannot repair, run:

DISM /Online /Cleanup-Image /RestoreHealth

Both commands read and write system files; they do not touch personal data. Run SFC again after DISM completes.

Test and replace memory

If Windows Memory Diagnostic reports errors, or faults persist with XMP disabled, test one module at a time in the primary slot. Replace a module that fails. This step destroys no data, but it requires opening the case and observing anti-static precautions.

Check the disk

A failing system disk can produce memory-like faults when pages cannot be read. Run, from an elevated command prompt:

chkdsk C: /scan

This is an online scan and does not dismount the volume. To repair, schedule a check for the next restart with chkdsk C: /f, which requires a restart and may take time. chkdsk can move and repair file system structures; back up important data before running a repair pass on a disk that may be failing.

Reset or reinstall Windows

A reset that keeps files removes installed applications and settings but preserves personal files. A clean install removes everything on the system volume. Both are last resorts after the steps above. Before either, copy personal data to external storage.

What people get wrong

The natural mistake is to treat the stop code as a diagnosis. The text IRQL_NOT_LESS_OR_EQUAL looks like it names a fault in the memory subsystem, so the first response is often to replace RAM or run a memory test, and a pass on that test is taken as proof the memory is fine. The code actually names the rule that was broken, and the same rule is broken by a driver that touches a bad pointer, by memory that is marginal only under load, and by a filter driver written for a different build. Replacing RAM is a natural response because the words suggest memory, and because a memory test is one of the few diagnostics a user can run without additional tools. It is the wrong first step when the fault began after a software change.

The second common mistake is to run Driver Verifier broadly and leave it enabled. Verifier is designed to make a latent driver fault immediate, which is useful during diagnosis and harmful in daily use. Leaving it on after the fault is found produces new bug checks that obscure the original problem.