How to fix the "IRQL_NOT_LESS_OR_EQUAL" BSOD caused by ntoskrnl.exe

When a Windows system crashes with the IRQL_NOT_LESS_OR_EQUAL blue screen, IT teams face more than just an interrupted workday. According to IDC, unplanned downtime triggered by system instability costs organizations up to $300,000 per hour in lost productivity. When ntoskrnl.exe appears as the faulting module, it’s even more critical because this kernel-level error doesn’t just force a reboot, it can corrupt filesystems mid-write, damage driver states, and silently erode data integrity with each crash.

The challenge is that the Windows kernel (ntoskrnl.exe) is often just the “witness” to the crime, not the actual culprit. So how can you actually fix it? This guide walks you through the systematic diagnostic and remediation process to identify the real offender and fix it permanently without weakening your security posture or risking further data loss.

What causes IRQL_NOT_LESS_OR_EQUAL errors

The IRQL_NOT_LESS_OR_EQUAL stop code (0x0000000A) occurs when a kernel-mode process or driver attempts to access memory at an incorrect priority level. In plain terms, a piece of software tried to touch data it wasn’t authorized to access at that moment, and Windows immediately halted everything to prevent corruption.

In real-world IT environments, this error typically appears after subtle system changes, such as:

• A network driver that updated automatically overnight
• A memory module degrading under thermal stress
• A “certified” graphics controller attempting to overwrite a memory address protected by the kernel

When you see ntoskrnl.exe listed as the faulting module, it’s almost never the actual problem. The kernel is simply the component that detected the violation and reported it, like a security guard calling out an intruder rather than being the intruder themselves. Device drivers are responsible for the majority of operating system failures, often around 70% with third‑party drivers being especially failure‑prone.

Not all kernel-mode code carries equal risk. Certain drivers like the Network Interface Card (NIC) and Graphics Processing Unit (GPU) are some of the most frequent offenders. These components perform massive, high-speed asynchronous data transfers, making them extremely prone to memory access conflicts.

Additionally, a slight mismatch in a firmware interface can cause an entire fleet of machines to spiral into repeated blue screen loops because the driver attempted to access pageable memory at a forbidden priority level.

Step-by-step guide for fixing the IRQL_NOT_LESS_OR_EQUAL error

Resolving this kernel-level error takes a bunch of steps, starting with safe preparation through diagnosis and then moving through targeted remediation. Skipping steps or jumping straight to “fixes” often leads to wasted time chasing the wrong culprit or introducing new instability while the original problem persists.

Step 1: Prepare your system for safe diagnosis

Before attempting any active remediation, you need to ensure the system is configured to capture diagnostic data and that you have recovery options if something goes wrong. The goal is to create a safety net that lets you investigate aggressively without risking data loss or an unbootable system.

Configure complete memory dumps

Windows creates minidump files by default, but these abbreviated crash reports often lack the detail needed for thorough analysis.

Follow these steps:

1. Press Win + Pause/Break to open System settings (or right-click This PC > Properties > Advanced system settings)

2. Under the Advanced tab, click “Startup and Recovery”

3. In the “Write debugging information” dropdown, select “Complete memory dump” and ensure the dump file location shows %SystemRoot%\MEMORY.DMP

4. Click OK to save, then OK again to close System Properties

This ensures that when the next crash occurs, you’ll have a full snapshot of kernel memory to analyze with WinDbg.

Verify your backup scope and recovery access

Before making driver changes or running diagnostic tools that could trigger additional crashes, confirm that you have current backups of critical data and a verified recovery method.

Follow these steps to verify backup coverage:

1. Open your backup solution (Windows Backup, third-party backup software, or enterprise backup system)

2. Verify the last successful backup timestamp is recent (within 24 hours for critical systems)

3. Check that the backup includes system state data, not just user files

4. If working remotely, confirm you have out-of-band access that doesn’t depend on the OS being stable

For enterprise IT environments, ensure your backup solution has recent snapshots and that you’ve tested restore procedures. You don’t want to discover backup failures while trying to recover from a diagnostic mishap.

Create a System Restore point

While System Restore won’t help with hardware-level IT issues, it provides a quick rollback option if driver updates or system file repairs introduce new problems.

Follow these steps to create a restore point:

1. Type “Create a restore point” in the Windows search bar and press Enter

2. Under the System Protection tab, select your C: drive and click Configure

3. Ensure “Turn on system protection” is selected

4. Adjust the disk space usage slider to at least 5% – 10% of drive capacity

5. Click OK, then click the Create button at the bottom of the window

6. Provide a clear description like “Pre-IRQL Diagnostics – [Today’s Date]”

7. Click Create and wait for confirmation

Step 2: Analyze memory dumps to identify the culprit

With preparation complete, the next phase focuses on identifying which component is actually causing the IRQL violation. Remember that ntoskrnl.exe is almost never the real problem, so your job is to find what triggered it.

Install and configure WinDbg

WinDbg (Windows Debugger) is the industry-standard tool for kernel crash analysis. You’ll need to download and install it before analyzing dump files:

1. Open the Microsoft store and search for “WinDbg”, then click Get

2. Open the tool from the Microsoft Store or Start menu

3. Click File > Start debugging > Open dump file

4. Navigate to C:\Windows\MEMORY.DMP (or C:\Windows\Minidump\ if using minidumps) and select the most recent .dmp file

5. Click Open and wait for WinDbg to load the dump (this may take several minutes for complete memory dumps)

6. Once loaded, type !analyze -v in the command window at the bottom and press Enter

7. Wait for the automated analysis to complete

NOTE: If no dump files exist, your system hasn’t captured crash data yet, or dump files were automatically cleaned up. Skip to “Test for physical memory failure” and continue with other diagnostic steps.

The !analyze -v output provides detailed information about what caused the crash. You need to identify third-party drivers in the stack trace.

Follow these steps to identify the culprit:

1. Scroll through the analysis output to find the “STACK_TEXT” section

2. Look for third-party .sys files (anything not from Microsoft) in the stack. Common culprits include:

• nvlddmkm.sys (NVIDIA graphics driver)
• rt640x64.sys or rtwlane.sys (Realtek network drivers)
• igdkmd64.sys (Intel graphics driver)
• e1d68x64.sys (Intel network driver)
• Driver files from antivirus or VPN software

3. Note the exact driver filename and any manufacturer information shown

4. Search online for “[driver filename] IRQL_NOT_LESS_OR_EQUAL” to see if others have reported similar issues

Step 3: Use Driver Verifier to stress-test suspected drivers

Once you’ve identified potential problem drivers from minidump analysis, Driver Verifier forces those drivers to operate under stricter scrutiny, exposing flaws that might only appear intermittently under normal conditions.

Driver Verifier is a built-in Windows tool that stresses kernel-mode drivers to expose bugs. It’s extremely effective at catching IRQL violations but can make your system unstable if configured incorrectly.

Follow these steps to enable Driver Verifier:

1. Press Win + R, type verifier.exe, and press Enter

2. Select “Create custom settings (for code developers)” and click Next

3. Check these options and click next:

• Special Pool
• Force IRQL Checking
• Pool Tracking
• Deadlock Detection

4. Select “Select driver names from a list” and click Next

Important warning: Do NOT select “Automatically select all drivers installed on this computer” or “Automatically select drivers built for older versions of Windows.” Verifying all drivers at once can make the system completely unstable and difficult to recover.

5. In the driver list, find and check only the specific driver(s) identified in your WinDbg analysis (for example, if you identified nvlddmkm.sys, check only NVIDIA drivers)

6. Click Finish

7. Restart your computer when prompted

With Driver Verifier enabled, use your computer normally to see if the problematic driver triggers a crash with clear attribution.

Follow these steps to test:

1. After restarting with Driver Verifier active, use your computer as you normally would

2. Perform activities that previously triggered crashes (gaming, video playback, high network usage, sleep/wake cycles)

3. If the driver has an IRQL flaw, Driver Verifier will trigger an immediate crash with the specific driver clearly identified in the blue screen

4. If the system remains stable for 24 – 48 hours with Verifier active, the driver is likely not the cause

Once you’ve completed testing, you must disable Driver Verifier or your system will continue operating under strict verification rules, impacting performance.

» Here’s how to restart a remote computer using Windows

Step 4: Check Device Manager for driver conflicts

Device Manager provides a quick visual way to identify problematic drivers and recent changes that might correlate with crash patterns.

Follow these steps to check for driver issues:

1. Press Win + X and select Device Manager

2. Look for any devices with yellow exclamation marks (⚠️) indicating driver problems

3. Expand these categories to inspect more closely:

• Network adapters
• Display adapters
• Storage controllers
• System devices

4. For each device in these categories, right-click and select Properties

5. Click the Driver tab and note the Driver Date

If crashes started after a specific date, drivers updated around that time are prime suspects. Pay special attention to devices showing “Code 43” errors or those that appear to be working but have recent driver updates from Windows Update rather than manufacturer-specific versions.

6. If you locate a problematic driver, click “Roll Back Driver” if the option isn’t greyed out

7. Select a reason from the list and click Yes to confirm

8. Restart your computer after the rollback completes

Note: Driver rollback is only available if Windows has preserved the previous driver version. If the “Roll Back Driver” button is greyed out, you’ll need to manually download an older driver version from the manufacturer’s website.

Additionally, if you have the option, consider updating your drivers since outdated drivers can also cause numerous problems. If you need help, see our guide to updating drivers and our list of the best driver updater software.

» Here’s how to disable Windows updates and manually re-enable Windows updates

Step 5: Perform a clean boot to isolate third-party software

A clean boot determines whether third-party services or startup programs are triggering the IRQL error, helping you differentiate between kernel-mode driver issues and user-mode software conflicts.

Follow these steps:

1. Press Win + R, type msconfig, and press Enter

2. Click the Services tab

3. Check the box for “Hide all Microsoft services” at the bottom and click “Disable all” to disable all non-Microsoft services

4. Click the Startup tab > Open Task Manager

5. In Task Manager’s Startup tab, right-click each enabled startup item and click Disable

6. Close Task Manager

7. Back in System Configuration, click OK

8. Click Restart when prompted

After booting into clean boot mode, test whether the IRQL crashes continue by following these steps:

1. Use your computer normally for several hours or perform activities that previously triggered crashes

2. If crashes stop, a third-party service or startup program is the culprit

3. If crashes continue, the issue is a kernel-mode boot-start driver (like disk or network drivers), not a user-mode service

4. To identify which service is responsible, open msconfig again

5. Go to the Services tab, hide Microsoft services, then enable half of the disabled services

6. Restart and test

7. If crashes return, the culprit is in the enabled half. Disable half of those and test again

8. If crashes don’t return, the culprit is in the still-disabled half. Enable half of those and test

9. Continue this binary search process until you’ve isolated the specific service

Important limitation: Clean boot only tests user-mode services and startup programs. It doesn’t disable boot-start kernel drivers (like disk controllers or network drivers), so if crashes continue in clean boot mode, you’re dealing with a deeper kernel-mode driver issue.

» Learn more about managing Windows startup programs

Step 6: Toggle Windows Security settings for compatibility testing

Windows Security’s Core Isolation and Memory Integrity features protect the kernel but can conflict with older drivers that don’t comply with modern memory handling standards.

Follow these steps to check if VBS features are causing conflicts:

1. Press Win + I to open Settings

2. Navigate to Privacy & Security > Windows Security

3. Click Device security

4. Click Core isolation details

5. Note whether “Memory integrity” is turned On or Off

6. If it’s On and your crashes started after a recent Windows update, toggle it to Off

7. Restart your computer

8. Test the system for several hours

If crashes continue, Memory integrity isn’t the cause. Re-enable it for continued kernel protection and proceed to the next steps. If crashes stop after disabling Memory Integrity, the driver is non-compliant with modern security standards.

From here, you have a few options:

• Contact the hardware manufacturer for an updated, VBS-compliant driver
• Replace the hardware with something that has compliant drivers
• Make a risk-based decision to keep Memory Integrity disabled for this specific system (not recommended for production environments)

Step 7: Repair system files with SFC and DISM

System file corruption can trigger IRQL violations if kernel components are damaged. These command-line tools repair Windows system files using official Microsoft sources.

DISM (Deployment Image Servicing and Management) must run first because it repairs the component store that SFC uses as a reference. Follow these steps:

1. Open Command prompt as an admin

2. Enter this command: DISM /Online /Cleanup-Image /RestoreHealth

3. Wait for the process to complete (this can take 15 – 30 minutes depending on your internet speed and system state)

4. Then enter this command: SFC /scannow

5. Wait for the scan to complete (typically 10 – 20 minutes)

6. Read the final results:

• “Windows Resource Protection did not find any integrity violations” = no corrupted files found
• “Windows Resource Protection found corrupt files and successfully repaired them” = corruption was fixed
• “Windows Resource Protection found corrupt files but was unable to fix some of them” = manual intervention needed

If SFC found but couldn’t repair files, you need to review the log to identify which files are problematic. Follow these steps:

1. In Command Prompt, enter this command: findstr /c:"[SR]" %windir%\Logs\CBS\CBS.log > "%userprofile%\Desktop\sfcdetails.txt"

2. Navigate to your Desktop and open sfcdetails.txt with Notepad

3. Search for lines containing “[SR] Cannot repair” to identify which system files are damaged

4. Note these filenames for potential manual replacement from known-good systems or Windows installation media

» Struggling? Learn more about using the DISM command correctly

Step 8: Use PowerShell to audit and remediate drivers at scale

For organizations managing multiple endpoints, PowerShell allows you to audit driver status across a fleet and enforce corrective actions remotely.

Follow these steps:

1. Open PowerShell as an admin

2. Paste this command: Get-WindowsDriver -Online -All | Export-Csv -Path "$env:USERPROFILE\Desktop\AllDrivers.csv" -NoTypeInformation

3. Wait for the command to complete, then open the CSV file on your Desktop with Excel or other spreadsheet application

4. Note: This command can hang on slower systems. If you wait a significant amount of time and don’t get any results, try this command instead: driverquery /FO CSV /SI > "C:\Users\Public\Desktop\AllDrivers.csv"

5. Review the Driver column to see all installed drivers, their versions, dates, and providers

6. Identify unsigned or legacy drivers (since they’re prime suspects for IRQL violations because they haven’t undergone rigorous memory-handling testing) with this command: driverquery /SI /FO TABLE

7. Scroll through the output and look for any entries showing “FALSE” in the “IsSigned” column

8. Note the Module Name and Inf Name of any unsigned drivers

9. Cross-reference these with your earlier WinDbg analysis or Device Manager inspection to prioritize suspects

For example, unsigned entries from gaming peripherals (like wireless receiver drivers), VPN software, or older hardware are common findings and frequent IRQL culprits. Cross-reference any FALSE entries against the crash timeline you documented in Step 1 to determine whether they’re likely suspects.

10. Then get the exact InstanceId of the device with the problematic driver: Get-PnpDevice | Where-Object {$_.FriendlyName -like "[partial device name]"}

Replace [partial device name] with part of the driver name from your earlier analysis (“Realtek” or “lightspeed”, for example).

11. Disable the device using its InstanceId with this command: Disable-PnpDevice -InstanceId "[paste InstanceId here]" -Confirm:$false

» Here’s the real cost of legacy IT

Step 9: Perform offline driver removal (when the system won’t boot)

When Windows crashes before you can log in, you need to identify and remove the problematic driver from outside the operating system using Windows Recovery Environment (WinRE).

To access WinRE if you have installation media:

1. Insert the USB drive or DVD and restart your computer

2. Press any key when prompted to boot from media

3. Select your language preferences and click Next

4. Click “Repair your computer” in the bottom-left corner

To access WinRE if you don’t have installation media:

1. Force shutdown your computer three times quickly while it’s trying to boot up to trigger automatic WinRE

2. Wait for “Preparing Automatic Repair” to appear

3. Click “Advanced options” when the recovery screen appears

4. Navigate to Troubleshoot > Advanced options > Command Prompt

In the recovery environment, drive letters are often different from normal Windows. You need to find which drive contains your Windows installation.

Follow these steps to identify the Windows drive:

1. Enter this command: diskpart

2. From the disk partitioning tool, type: list volume

3. Note the drive letter of the volume either labeled “Windows” or with a size matching your Windows installation (typically 100GB – 500 GB for the OS partition)

4. Type: exit

5. Then type (replace “D” with the correct drive letter: dism /image:D:\ /get-drivers

6. Press Enter and wait for the list to generate

7. Review the output for the driver identified in your earlier WinDbg analysis

8. Note the “Published Name” (looks like oem##.inf where ## is a number)

9. Then remove the driver with this command (replace “D” with your Windows drive letter and “oem##.inf” with your actual driver filename): dism /image:D:\ /remove-driver /driver:oem##.inf

10. Once the process has finished, restart your computer.

Step 10: Adjust BIOS/UEFI firmware settings

If you’ve exhausted driver updates, system file repairs, and clean boot diagnostics without resolving crashes, the issue may lie at the hardware-firmware boundary. Only proceed to firmware changes after confirming software-level fixes have failed.

Follow these steps:

1. Access BIOS/UEFI by restarting your PC, then mashing the BIOS key repeatedly during startup (the key varies by manufacturer, but will typically be one of these: Delete, F2, F10, F12, or Esc)

2. If you hit the OS screen, you were pressing the wrong key and went too far. The BIOS menu should look something like this:

After each step, save and exit your BIOS and test the system to see if the crashes stopped. If they haven’t, move on to the next BIOS change.

Disable XMP/DOCP/EXPO memory profiles

XMP (Extreme Memory Profile) and DOCP (Direct Overclocking Profile) push RAM beyond standard specifications and are more unstable, which can cause IRQL violations if the memory controller can’t maintain stability.

Follow these steps:

1. In BIOS setup, navigate to the Overclocking, Advanced, or AI Tweaker section (varies by manufacturer)

2. Locate the setting labeled “XMP,” “DOCP,” “EOCP,” or “Memory Profile”

3. Change it from “Enabled” or “Profile 1” to “Disabled” or “Default”

4. Verify that memory frequency shows JEDEC standard speeds (DDR4-2133, DDR4-2400, or DDR5-4800)

If the crashes continue, then RAM wasn’t the problem and you can re-enable XMP or DOCP.

Disable hardware virtualization

Conflicts between CPU virtualization features and certain drivers can trigger IRQL errors, particularly with older network cards or GPU drivers. Follow these steps to disable virtualization (if you aren’t using VMs like Hyper-V or Windows Sandbox):

1. Navigate to the CPU Configuration, Advanced, or Security section

2. Locate “Intel Virtualization Technology” (Intel VT-x) or “SVM Mode” (AMD-V)

3. Change it to Disabled

4. Also disable “Intel VT-d” or “AMD IOMMU” if present

Adjust PCIe power management (ASPM)

Aggressive power management can cause hardware to wake up from low-power states inconsistently, leading to IRQL violations when drivers attempt to communicate with hardware that hasn’t fully initialized.

Follow these steps to disable it:

1. Navigate to Advanced > PCIe Configuration or Chipset Configuration

2. Locate “ASPM” (Active State Power Management)

3. Change it from “Auto” or “L1” to “Disabled”

4. Test the system’s sleep/wake cycles

Disable CPU C-states for testing

CPU power-saving states can cause wake timing issues that trigger IRQL violations. Follow these steps to disable C-States:

1. Navigate to Advanced > CPU Configuration or Power Management

2. Locate “CPU C-States” or “Enhanced C-States” or “Global C-state Control”

3. Change to Disabled

Update BIOS/UEFI firmware (last resort)

Outdated motherboard firmware can cause communication failures between the OS and hardware.

Critical warning: BIOS updates carry risk. If interrupted during flashing (power loss, system crash), the motherboard can become unbootable. Only perform BIOS updates when you’ve exhausted other options and the release notes specifically address stability issues matching your symptoms.

Additionally, see our comprehensive guides to firmware updates and updating your BIOS to ensure you know what you’re doing.

Take control of BSOD errors with Atera

Fixing IRQL_NOT_LESS_OR_EQUAL errors caused by ntoskrnl.exe is rarely straightforward, but it becomes more manageable when you treat it as a systematic investigation rather than a guessing game. That means proper preparation, methodical diagnosis, and working from safest to most complex interventions.

For IT teams managing dozens or hundreds of endpoints, running through these steps manually on every affected machine isn’t realistic. Atera’s all-in-one platform gives technicians the tools to tackle IRQL issues at scale, such as getting AI Copilot to generate comprehensive PowerShell scripts from natural language queries, remotely executing PowerShell driver audits across an entire fleet with the RMM platform, tracking BIOS versions to correlate firmware with crash patterns, and setting threshold alerts to catch interrupt anomalies before they become blue screens.

When kernel-level instability strikes across multiple endpoints simultaneously, having a centralized platform that brings diagnostics, remote access, and automated remediation together in one place is the difference between a managed response and a full-scale crisis.

» Try Atera for free to see how it can streamline your operations