IRQL_NOT_GREATER_OR_EQUAL (0x00000009): Meaning and Windows Troubleshooting

Quick Answer

IRQL_NOT_GREATER_OR_EQUAL is a Windows bug check with the value 0x00000009. Microsoft states that this stop code appears very infrequently and recommends using the !analyze debugger extension to investigate the crash. Microsoft Learn

The code alone does not identify a faulty driver, application, or hardware component. If the computer crashes repeatedly, record the stop-screen details, inspect recent hardware and driver changes, test in Safe Mode, review Event Viewer, and analyze an available memory dump with WinDbg.

What IRQL means

IRQL, or interrupt request level, is a Windows kernel mechanism that controls which operations can run and which events can interrupt them. Kernel-mode drivers must perform specific operations at permitted IRQLs. Incorrect IRQL handling can destabilize the operating system and trigger a bug check.

IRQL_NOT_GREATER_OR_EQUAL identifies an invalid IRQL-related condition. Microsoft’s public page does not provide a general consumer repair or a single confirmed cause. It is primarily a programmer and driver-debugging reference. Microsoft Learn

This code is different from IRQL_NOT_LESS_OR_EQUAL (0xA), even though the names are similar. Do not substitute the diagnosis or parameter interpretation for 0xA.

What the stop code does not prove

The code does not automatically mean:

• The CPU is defective.
• A particular process caused the crash.
• All drivers must be replaced.
• The computer has a malware infection.
• Windows must be reinstalled.
• Changing BIOS interrupt settings will fix the problem.

A driver or module shown in a dump is an investigation lead. It may have exposed corruption caused by another component.

Possible contributing areas

A recurring 0x00000009 crash may involve:

• A defective or incompatible kernel-mode driver.
• Graphics, storage, network, security, or virtualization software.
• A recently installed or updated driver.
• Firmware or chipset compatibility issues.
• Unstable memory or memory corruption.
• Hardware instability.
• A Windows issue affecting a particular build or configuration.

These are possible areas to investigate, not guaranteed causes.

Symptoms

You may see:

• A blue or black stop screen.
• An unexpected restart.
• IRQL_NOT_GREATER_OR_EQUAL or 0x00000009.
• Four hexadecimal bug-check parameters.
• A filename after “What failed.”
• Crashes during startup, device use, sleep or wake, gaming, virtualization, or security scanning.
• A restart loop if the affected driver loads during boot.

Record the exact text and any filename shown.

Record the crash details

Before changing the system, record:

1. The stop-code name and value.
2. All four bug-check parameters.
3. Any “What failed” filename.
4. The crash date and time.
5. What the computer was doing immediately beforehand.
6. Recent Windows, driver, firmware, hardware, security, or virtualization changes.
7. Whether the same activity reproduces the crash.
8. Whether a dump exists in C:\Windows\Minidump or C:\Windows\MEMORY.DMP.

Bug-check parameters can be obtained from the Event Viewer System log or from a generated dump. Microsoft documents gathering this stop-code data for analysis. learn.microsoft.com

Initial troubleshooting

Back up important data

Confirm that important data is backed up before making hardware changes or using recovery options. Some Windows recovery operations can remove applications, settings, or files. support.microsoft.com

Check recent hardware

If a new device or internal component was installed before the first crash:

1. Shut down the computer.
2. Disconnect or remove the recently added hardware where safe.
3. Restart Windows.
4. Repeat the activity that previously caused the crash.

Microsoft includes removing newly added hardware in its general stop-error guidance. support.microsoft.com

If the error stops, check the manufacturer’s driver, firmware, and compatibility information.

Inspect Device Manager

Open Device Manager by right-clicking Start and selecting Device Manager.

Look for:

• A yellow warning icon.
• A device added or updated before the problem began.
• Device-status errors.
• A device that repeatedly disconnects or reconnects.
• A driver version that matches the beginning of the crashes.

For a relevant device, open Properties > Driver. Use Windows Update or the manufacturer’s official support site. If the problem began after an update and Roll Back Driver is available, record the current version, roll it back, restart, and test.

Install updates

Install applicable updates through Settings > Windows Update and restart when prompted. Also check the computer manufacturer for:

• BIOS or UEFI updates.
• Chipset drivers.
• Graphics, storage, and network drivers.
• Docking-station firmware.
• Compatibility updates for security and virtualization software.

Apply firmware updates with reliable power and do not interrupt them.

Check disk space

Windows needs free space for paging, updates, temporary files, and crash dumps. Microsoft includes checking available disk space among its general stop-error steps. support.microsoft.com

Open Settings > System > Storage and inspect the system drive. Remove only known unnecessary files or move backed-up personal data.

Test in Safe Mode

Safe Mode loads a limited set of drivers and services. It can help determine whether a third-party component contributes to the problem.

From the Windows Recovery Environment, use:

Troubleshoot > Advanced options > Startup Settings > Restart

Then select the appropriate Safe Mode option. Microsoft documents Startup Settings for startup troubleshooting. support.microsoft.com

If the system is stable in Safe Mode, focus on third-party drivers, startup services, graphics components, endpoint protection, virtualization, and hardware-monitoring utilities.

If the system crashes in Safe Mode too, investigate memory, firmware, hardware, or a deeper Windows problem.

Review Event Viewer

Open Event Viewer and select:

Event Viewer (Local) > Windows Logs > System

Review entries around the crash time. Look for:

• The BugCheck event and parameters.
• Driver or device errors before the crash.
• Storage or file-system errors.
• Firmware and power-management events.
• Security or virtualization driver events.
• Kernel-Power events indicating an unexpected restart.

An event written after the restart may describe the consequence, not the original cause.

Analyze a crash dump with WinDbg

A crash dump preserves part of the kernel state and is usually more useful than generic repair attempts.

Locate or configure a dump

Check:

C:\Windows\Minidump
C:\Windows\MEMORY.DMP

The configured dump type and location are available under:

System Properties > Advanced > Startup and Recovery > Settings

Small dumps may not contain enough context to identify the original driver. If no useful dump exists, configure Write debugging information for a future crash. Microsoft documents small and kernel-mode dump handling. Windows Client

Analyze the dump

Open the dump in WinDbg. Microsoft documents analyzing kernel-mode dumps using WinDbg and the -z dump-file option. learn.microsoft.com

Run:

!analyze -v

Useful supporting commands include:

.bugcheck
!analyze -show
lm N T

Review:

• The four bug-check parameters.
• The failing thread and stack.
• Any third-party module near the failure.
• Driver versions and timestamps.
• Whether symbols loaded correctly.
• Signs of memory or stack corruption.
• Whether the same module appears in multiple dumps.

Microsoft specifically recommends !analyze for 0x00000009. Microsoft Learn

Treat Probably caused by as a lead, not final proof. Confirm it with the stack, module data, event timeline, driver history, and repeatability.

Technical guidance for driver developers

Drivers must follow IRQL rules for interrupt handlers, dispatch routines, deferred work, synchronization, and cleanup.

Review:

• The IRQL at entry and exit from every routine.
• Whether pageable code or data is accessed at elevated IRQL.
• Whether locks are acquired and released at permitted levels.
• Whether interrupt and deferred work are synchronized.
• Whether IRQL is restored on all success and error paths.
• Driver unload, cancellation, and timeout logic.
• Shared data accessed by multiple processors.

Use checked or instrumented test environments and analyze a complete dump when possible. Do not modify or delete a third-party driver binary.

Driver Verifier considerations

Driver Verifier can stress selected drivers and intentionally trigger additional stop errors when it detects violations. It is an advanced diagnostic tool, not a routine repair.

Use it only when:

• Basic troubleshooting is complete.
• A qualified administrator can recover the system.
• A restore or recovery plan exists.
• The test is controlled and documented.

Do not enable aggressive verification for every driver on a production system without a recovery plan. If it creates a boot loop, use Safe Mode or Windows Recovery Environment to disable it.

What not to do

Avoid these actions without evidence:

• Changing BIOS or interrupt settings at random.
• Replacing the CPU solely because the error mentions IRQL.
• Deleting driver files manually.
• Installing generic driver-updater utilities.
• Disabling security software permanently.
• Updating every driver simultaneously.
• Reinstalling Windows before collecting a dump.
• Running Driver Verifier without a recovery plan.
• Treating the process or module name as conclusive proof.

Make one targeted, reversible change at a time and record the outcome.

Verification after a change

After a targeted change:

1. Restart if required.
2. Repeat the activity that previously caused the crash.
3. Check whether the same stop code returns.
4. Preserve any new dump.
5. Record the driver, firmware, or software version tested.

If different stop codes begin appearing, preserve all dumps and stop making unrelated changes. A changing set of bug checks can indicate memory corruption, unstable hardware, or a driver damaging kernel state.

When to escalate

Escalate when:

• The crash repeats after updates and driver rollback.
• The system crashes in Safe Mode.
• Multiple unrelated stop codes appear.
• Memory or hardware diagnostics report errors.
• No dump can be created.
• WinDbg identifies a third-party driver requiring vendor analysis.
• The affected computer is a server or production workstation.
• Windows enters a restart loop.
• Important data may be at risk.

Provide the exact stop code, four parameters, dump file, Windows build, computer model, recent changes, and troubleshooting results.

Frequently asked questions

Is IRQL_NOT_GREATER_OR_EQUAL the same as IRQL_NOT_LESS_OR_EQUAL?

No. They are separate bug checks with different values and documentation. 0x00000009 should be analyzed as its own stop code; do not assume guidance for 0xA applies automatically.

Is a faulty driver always responsible?

No. A driver is an important investigation target, but memory corruption, hardware instability, firmware, and Windows defects can also contribute.

Does this mean the processor is defective?

No. The code describes an invalid IRQL-related kernel condition. It does not prove processor failure.

Can Windows Update fix the problem?

It may help if the underlying issue is corrected in Windows or a supplied driver. Microsoft does not document one universal update that fixes every 0x00000009 crash.

Should I use Driver Verifier?

Only for controlled, advanced diagnosis with a recovery plan. It can cause additional crashes and should not be treated as a routine repair.

Should I reinstall Windows?

Not as the first step. Reinstallation may remove software causes but will not necessarily resolve a driver, firmware, memory, or hardware problem. Collect dump and event evidence first.

Why is this stop code rare?

Microsoft states that IRQL_NOT_GREATER_OR_EQUAL appears very infrequently. A precise dump, driver history, and event timeline are therefore more useful than generic fixes. Microsoft Learn

Conclusion

IRQL_NOT_GREATER_OR_EQUAL (0x00000009) is a rare Windows kernel stop code associated with an invalid interrupt request level condition. It does not identify a particular driver, process, or hardware component.

For recurring crashes, record the parameters and circumstances, inspect recent changes, check Device Manager and Event Viewer, test in Safe Mode, and analyze a crash dump with WinDbg. Driver developers should audit IRQL transitions, pageable-code access, synchronization, and cleanup paths. Base any repair on evidence from the affected system.

Sources

• Microsoft Learn, Bug Check 0x9: IRQL_NOT_GREATER_OR_EQUAL. Microsoft Learn
• Microsoft Support, Troubleshooting Windows unexpected restarts and stop code errors. support.microsoft.com
• Microsoft Learn, Analyze a kernel-mode dump file by using WinDbg. learn.microsoft.com
• Microsoft Learn, Read small memory dump files. Windows Client
• Microsoft Learn, Kernel-mode dump files. Windows drivers
• Microsoft Support, Windows startup settings. support.microsoft.com