⚠ CrashDecoder

0x0000000A IRQL_NOT_LESS_OR_EQUAL

Kernel code runs at different interrupt priority levels, and at the higher ones the machinery that fetches paged-out memory simply cannot run. When a driver reaches for memory that is not resident while running at one of those levels, there is no way to recover - so Windows stops immediately. This is one of the most driver-specific stop codes there is, which makes it unusually tractable.

Updated 2026-07-27Stop errorAlso written: 0xA, IRQL NOT LESS OR EQUAL, 0x000000D1, DRIVER_IRQL_NOT_LESS_OR_EQUAL

What you are looking at

:(

Your PC ran into a problem and needs to restart.

Stop code: IRQL_NOT_LESS_OR_EQUAL

In Event Viewer the matching entries look like this:

Log Name:      System
Source:        BugCheck
Event ID:      1001
Level:         Error

The computer has rebooted from a bugcheck.  The bugcheck was: 0x0000000a (0xffffd8021a4c0000, 0x0000000000000002, 0x0000000000000001, 0xfffff8036b21a4c0).

What the error actually means

Windows assigns every piece of kernel code an Interrupt Request Level, or IRQL. It is a priority scheme: code running at a high IRQL cannot be interrupted by anything at or below its own level. That is what makes it useful for time-critical work like servicing hardware.

It also makes it dangerous. The page fault handler - the component that fetches memory which has been paged out to disk - runs at a relatively low IRQL. Code executing at DISPATCH_LEVEL or above therefore cannot trigger a page fault, because the handler that would resolve it is not allowed to run.

Bugcheck 0xA fires when a driver does it anyway: it referenced memory that was not resident, while at an IRQL where that cannot be fixed. There is no recovery path, so the kernel stops.

The practical value here is that this is a rule about how drivers must behave. Windows itself does not break it. That means the fault almost always belongs to a specific third-party driver - and the dump usually names it.

Reading the parameters

Unusually, all four parameters are directly useful on this one.

ParameterWhat it holds
1The virtual memory address that could not be accessed. Microsoft's rule: a value below 0x1000 is likely a null pointer dereference. Otherwise, run !pool on this address in a debugger - if it reports paged pool or other pageable memory, the IRQL was simply too high to touch it, which is a different bug from a bad pointer.
2The IRQL at the moment of the fault. 2 is DISPATCH_LEVEL and is by far the most common value here.
3A bit field describing the operation, not a simple number. Bit 0 is the read/write flag and bit 3 is the execute flag, giving three combined values in practice: 0x0 a read from the address, 0x1 a write to it, and 0x8 an attempt to execute code from it. The execute case is the informative one - Microsoft attributes it to calling a function that cannot be called at DISPATCH_LEVEL, forgetting to release a spinlock, or marking code pageable when it must be non-pageable.
4The instruction pointer at the time of the fault. Running ln on this address in a debugger gives you the name of the function - which is usually the fastest route to a driver name.

What actually triggers it

The distribution here is lopsided in a way most stop codes are not.

CauseHow oftenDetail
Third-party device driversCommonThe dominant cause. Network adapters and Wi-Fi drivers are frequent offenders, as are storage controllers, VPN virtual adapters and audio interfaces. Anything that services hardware spends time at raised IRQL, which is exactly where this rule applies.
Anti-virus and filter driversCommonSecurity products hook file and network operations at kernel level. A version mismatch after a Windows update produces this reliably.
Failing or misconfigured RAMOccasionalCorrupted memory turns a valid pointer into a garbage one. The driver then dereferences it perfectly correctly and dies - which is why the named driver can be entirely innocent.
Unstable memory profile or overclockOccasionalAn XMP or EXPO profile that is not genuinely stable produces the same effect as failing RAM, intermittently.
Corrupt driver installationOccasionalUpgrading a driver in place over several versions can leave mismatched files behind. Common with graphics and audio stacks.

Narrowing it down

Because this code points so strongly at drivers, the debugger step is worth more here than almost anywhere else.

Get the driver name from the dump

Open the newest file in C:\Windows\Minidump with WinDbg and run:

!analyze -v

Read MODULE_NAME, IMAGE_NAME and the STACK_TEXT block. Parameter 4 resolves to a specific driver, and that is normally your answer in one step.

What it tells you

A third-party .sys file is your suspect. If it names a Microsoft component such as ntoskrnl.exe or tcpip.sys, look further down the stack - a Microsoft driver is often executing on behalf of a third-party one that passed it bad data.

Classify parameter 1, then check parameter 3

Values under 0x1000 indicate a null or near-null dereference. For anything larger, run !pool on the address in WinDbg to find out what kind of memory it was:

!pool <address from Arg1>
!address <address from Arg1>

Then look at parameter 3 - 0x0 read, 0x1 write, 0x8 execute.

What it tells you

A small address is a logic bug in the driver - update or remove it. If !pool reports paged pool, the driver was touching pageable memory at too high an IRQL, which is a pageability bug rather than a bad pointer. A parameter 3 of 0x8 means it tried to execute pageable code at raised IRQL - the same category. A large random-looking address that is not valid pool at all points toward corrupted memory, which shifts attention to RAM.

Correlate with recent changes

Check whether the first crash lines up with a driver update, a Windows feature update, or newly installed software. Reliability Monitor lays this out visually - run perfmon /rel.

What it tells you

A clean correlation gives you the answer without a debugger. Crashes that predate every recent change point at hardware instead.

Fixes, cheapest first

If the dump named a driver, fix that first and skip the rest.

  1. Update or roll back the named driver

    Effort: 20 minutes · Risk: Low

    Get the current version from the hardware vendor rather than Windows Update, which often ships older builds. If the crashes started after an update, install the previous version instead.

    1. Identify the device in Device Manager that owns the named .sys file.
    2. Uninstall it, ticking Delete the driver software for this device.
    3. Reboot and install the vendor's package.
    4. For network drivers specifically, disable any power-saving option under the adapter's Power Management tab.

  2. Remove kernel-level software you do not need

    Effort: 30 minutes · Risk: Low

    Third-party anti-virus, VPN clients, RGB and fan utilities, virtual drive software and old printer packages all install kernel drivers. Uninstall what you are not actively using, then run for a day. Windows Defender alone is a perfectly reasonable configuration while diagnosing.

  3. Return memory to stock and test it

    Effort: Overnight · Risk: None

    Disable XMP, EXPO or any manual memory tuning in UEFI. If the crashes stop, the profile was not stable at those timings.

    Then verify the modules themselves with MemTest86 from a USB stick - at least four passes, ideally overnight. Any error is conclusive; a clean pass is only suggestive.

  4. Run Driver Verifier

    Effort: Several hours · Risk: Medium

    If the dump refuses to name anything useful, Verifier will force the issue. It is particularly effective on this bugcheck, because the IRQL rule it enforces is exactly the one being broken.

    1. Create a restore point, and know how to reach Safe Mode before starting.
    2. Run verifier as administrator and choose custom settings.
    3. Enable Special Pool, Force IRQL checking, Pool Tracking and I/O Verification.
    4. Select only non-Microsoft drivers.
    5. Use the machine until it bugchecks - the dump will name the culprit.
    6. Disable afterwards with verifier /reset.
    Watch out

    Verifier deliberately increases crashes and can cause a boot loop. Run verifier /bootmode resetonbootfail before enabling any checks - it makes Verifier disable itself automatically if the machine fails to start, which removes most of the risk. Your manual exit is Safe Mode followed by verifier /reset. Full settings and the escape route are in the Driver Verifier guide.

When it is the hardware, not Windows

This code is usually software, so hardware signals need to be clearer than average before you change direction:

The second item on that list is the most diagnostic. A genuine driver bug is repetitive - the same module, the same stack, every time. Memory corruption moves around, because whatever gets damaged depends on what happened to be stored there. If you have three dumps naming three different drivers, stop chasing drivers.

Frequently asked

What is the difference between 0xA and 0xD1?

They describe the same rule violation. 0x0000000A is the general form; 0x000000D1 is DRIVER_IRQL_NOT_LESS_OR_EQUAL, raised when the offending code is specifically identified as a driver. The parameters have the same meanings and the troubleshooting is identical. If anything, 0xD1 is the friendlier one, because it removes any doubt about the category.

The dump names ndis.sys or tcpip.sys. Is my network card faulty?

Not necessarily. Those are Microsoft's networking components, and they frequently appear because they were running when a third-party network driver handed them something invalid. Look further down the stack for the adapter's own driver - rt640x64.sys, e1d68x64.sys, a Killer or Intel Wi-Fi module. That is usually the real name.

Can a Windows update cause this?

Indirectly and quite often. Updates change kernel interfaces, and a driver that made assumptions about the old behaviour can start violating IRQL rules afterwards. The fix is almost always an updated driver rather than removing the update - though rolling the update back temporarily is a legitimate way to confirm the connection.