0x000000D1 DRIVER_IRQL_NOT_LESS_OR_EQUAL
A kernel-mode driver reached for an address that was either paged out or completely invalid, while running at an interrupt level where neither is survivable. Of all the driver-fault stop codes this is the most tractable, because Windows can usually identify which driver did it and prints the name on the screen.
What you are looking at
Your PC ran into a problem and needs to restart.
Stop code: DRIVER_IRQL_NOT_LESS_OR_EQUAL
What failed: rt640x64.sys
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: 0x000000d1 (0xfffff808add27150, 0x0000000000000002, 0x0000000000000000, 0xfffff808adc386a6).What the error actually means
Kernel code runs at an interrupt request level, and at DISPATCH_LEVEL or above the machinery that fetches paged-out memory cannot run. A driver that touches non-resident memory at that level has asked for something the system cannot deliver, and there is no recovery path.
Microsoft documents three ways a driver gets here: dereferencing a bad pointer - null or already freed - at or above DISPATCH_LEVEL, accessing pageable data at that level, or executing pageable code at that level.
What separates this code from its close relative 0xA is attribution. Where Windows can identify the responsible driver, it prints the name on the blue screen and stores it in memory. In a debugger:
dx KiBugCheckDriverThat is often the entire diagnosis, available in one command.
Microsoft states it plainly: in the majority of cases of this type of bug check, the issue is not the IRQL level, but rather the memory that is being accessed.
The IRQL is the condition that made the access fatal rather than merely slow. The bug is the address. Read parameters 1 and 4, not parameter 2.
Reading the parameters
Parameters 1 and 4 are where the diagnosis lives. Note that parameter 3's encoding here is a plain value list, unlike the bit field used by bugcheck 0xA.
| Parameter | What it holds |
|---|---|
| 1 | The memory address referenced. A value under about 0x1000 is a null pointer with an offset - a plain logic bug. Anything larger is worth running !pool against: if it reports paged pool, the driver was touching pageable memory at too high a level, which is a different bug from a bad pointer. |
| 2 | The IRQL at the time of the reference. 2 is DISPATCH_LEVEL and is what you will almost always see. Informative for context, but rarely the thing to fix. |
| 3 | The operation attempted: 0 read, 1 write, 2 execute, 8 execute. An execute value means the driver tried to run pageable code at raised IRQL - a specific and distinct mistake from touching pageable data. |
| 4 | The address that referenced the memory. Run ln on this in a debugger to get the function name - which is usually the fastest route to naming the driver when the screen did not. |
What actually triggers it
Driver-dominated to an unusual degree. Microsoft's own summary is that this bugcheck is usually caused by drivers using improper memory addresses.
| Cause | How often | Detail |
|---|---|---|
| Network adapter drivers | Common | The single most frequent category. Wi-Fi and Ethernet drivers do substantial work at raised IRQL servicing interrupts, which is exactly where this rule bites. Realtek, Killer, Intel and Broadcom adapter drivers all appear regularly. |
| A driver calling into another that was unloaded | Common | Microsoft lists this specifically: the call was made to a function in another driver, and that driver was unloaded. The address is valid-looking but the code behind it is gone. |
| Anti-virus and filter drivers | Common | Security products hook operations at kernel level by design. A version mismatch after a Windows update produces this reliably. |
| A function pointer that was invalid | Occasional | Another cause Microsoft names directly. Produces a wild address in parameter 1 rather than a small offset. |
| Code marked pageable that should not be | Occasional | A driver function marked pageable and then executed while holding a lock or at elevated IRQL. This is the case parameter 3 flags with an execute value. |
| Failing RAM | Occasional | Corrupted memory turns a valid pointer into garbage, and the driver dereferences it perfectly correctly. This is why a driver named only once should be treated as a hypothesis rather than a verdict. |
| Unstable memory profile | Occasional | An XMP or EXPO profile beyond what the controller sustains produces the same effect as failing memory, intermittently. |
Narrowing it down
Start with the name, and only reach for the debugger if you did not get one.
Read the driver name
Photograph the blue screen if you can - the What failed line names the file. If you missed it, open the newest minidump in WinDbg and run:
!analyze -v
dx KiBugCheckDriverA third-party .sys file is your suspect and Microsoft's advice is to disable or remove it. If it names a Microsoft framework component such as ndis.sys or Wdf01000.sys, that is the layer the offending driver was calling through - look further down the stack for the device's own driver.
Classify parameter 1
Take the first parameter, then in a debugger:
!pool <address from Arg1>
!address <address from Arg1>A small value near zero is a null-pointer bug - update or remove the named driver and hardware is not implicated. If !pool reports paged pool, the driver was touching pageable memory at too high a level, which is a pageability bug rather than a bad pointer. An address that is not valid pool at all leans toward corrupted memory.
Name the function with ln
When the screen gave you nothing, parameter 4 usually will:
ln <address from Arg4>This resolves to the function that made the reference, which identifies the module even when !analyze declines to blame anything.
Compare the named driver across crashes
Open three or four dumps and see whether the same module appears each time.
The same driver every time is a genuine bug in that driver. A different one each time is memory corruption wearing a driver's name - and no amount of driver work will help. Go to memory testing instead.
Fixes, cheapest first
If you have a name, the first fix is usually the only one you need.
Replace the named driver
Remove it properly rather than upgrading in place, which leaves the old files behind.
- Find the device that owns the named file in Device Manager - Properties, Driver, Driver Details.
- Uninstall the device, ticking Delete the driver software for this device.
- Reboot and install the vendor's current package, downloaded directly rather than via Windows Update.
- For network adapters, also open the adapter's Properties, Power Management tab, and clear Allow the computer to turn off this device to save power.
Watch outIf the crashes started after a driver update, install the previous release instead. Regressions are common and newer is not automatically better.
Remove kernel-level software you do not need
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 - use the vendor's dedicated removal tool for security products, since standard uninstallers routinely leave drivers behind.
Return memory to stock and test it
Disable XMP or EXPO, then run MemTest86 from USB for at least four passes. Particularly worth doing if the named driver changes between crashes or parameter 1 held a wild address. See the memory testing guide.
Run Driver Verifier
Effective on this bugcheck because Force IRQL checking enforces exactly the rule being broken. Use it when no driver is named and the dumps are unhelpful.
Watch outVerifier deliberately increases crashes and can cause a boot loop. Run
verifier /bootmode resetonbootfailbefore 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 byverifier /reset. Full settings and the escape route are in the Driver Verifier guide.
When it is the hardware, not Windows
Usually software, so hardware signals need to be clear:
- The named driver differs between crashes.
- Parameter 1 is consistently a large random-looking address rather than a small offset.
- MemTest86 reports errors at stock settings.
- Other unrelated stop codes appear in the same period.
- Crashes continue after a clean Windows install with only vendor drivers.
WHEA-Loggerentries appear around the same timestamps.
The first item does most of the work. A genuine driver bug is repetitive - same module, same stack, same shape of faulting address. Corruption moves around, because what gets damaged depends on what happened to be stored there. Three dumps naming three different drivers is a stronger signal than any single dump could give you.
Frequently asked
What is the difference between 0xD1 and 0xA?
They describe the same rule violation - memory touched at an interrupt level too high to fault on. 0xA is the general form; 0xD1 is raised when the offending code is specifically identified as a driver.
Practically, 0xD1 is the friendlier one: it removes any doubt about the category and Windows more often prints the driver name on screen. One small difference worth knowing - parameter 3 on 0xA is a bit field, while on 0xD1 it is a plain value list.
The screen names ndis.sys or Wdf01000.sys. Is that the faulty driver?
No - those are Microsoft frameworks. ndis.sys is the network driver framework and Wdf01000.sys is the Windows Driver Framework, and they appear because the actual offender was calling through them. Look further down the stack for the device's own driver, or run ln on parameter 4 to get the function name.
Should I try to lower the IRQL somehow?
There is nothing for you to lower - IRQL is an internal scheduling concept, not a setting. And Microsoft says directly that the IRQL is usually not the issue anyway; the memory being accessed is. The name of the stop code is misleading in that respect. Focus on which driver, not on the interrupt level.
It only happens when I use Wi-Fi or transfer large files.
That points squarely at the network adapter driver, which is the most common cause of this bugcheck anyway. Network stacks do heavy work at raised IRQL, and load makes a marginal driver fail sooner. Get the current driver from the adapter vendor rather than the laptop maker or Windows Update, and turn off the adapter's power-saving option while you test.
Related errors
- 0x0000000AIRQL_NOT_LESS_OR_EQUALA driver accessed memory at an interrupt level too high to survive the fault. Nearly always a driver.
- 0x0000003BSYSTEM_SERVICE_EXCEPTIONA kernel fault during a system call. Usually a driver, sometimes memory, occasionally a dying board.
- GuideDriver Verifier: How to Find a Bad Driver Without Bricking Your BootThe tool that names a bad driver. Plus the boot-fail flag that makes it safe to use.