Windows BSOD Error 0x00000111 (RECURSIVE_NMI): Meaning, Causes and Troubleshooting

Quick Answer

The 0x00000111 RECURSIVE_NMI error is a Windows Blue Screen of Death (BSOD) stop code indicating that a non-maskable interrupt (NMI) occurred while another NMI was already being processed.

According to Microsoft, this bug check is associated with an error in System Management Interrupt (SMI) handling. Specifically, an SMI interrupts an NMI and enables interrupts, allowing another NMI to interrupt the NMI that is already in progress.

This is a low-level system interrupt and firmware-related condition, not an ordinary application error. Investigating the system firmware, BIOS or UEFI configuration, hardware environment, and crash dump is more appropriate than immediately reinstalling Windows or replacing device drivers.

Stop code: 0x00000111

Bug check name: RECURSIVE_NMI

Primary documented context: An NMI occurs while a previous NMI is in progress because of an SMI-handling error.

What Is the 0x00000111 RECURSIVE_NMI Error?

RECURSIVE_NMI is a Windows kernel bug check that occurs when the operating system detects a second non-maskable interrupt while an earlier NMI is still being handled.

An NMI is a special type of hardware interrupt that cannot be disabled through the normal processor interrupt-masking mechanism. It is used for certain critical hardware and system-level events that require immediate attention.

Windows uses bug checks to stop the system when it encounters an unrecoverable condition. In this situation, continuing execution could leave the processor or system in an unsafe state.

Microsoft identifies the error using the following bug check value:

• Bug check code: 0x00000111
• Bug check name: RECURSIVE_NMI
• Decimal value: 273
• Error category: Kernel-level interrupt handling failure

Official technical documentation: Microsoft Learn – Bug Check 0x111: RECURSIVE_NMI.

Understanding NMI and SMI

To understand this error, it is useful to distinguish between two low-level interrupt mechanisms: Non-Maskable Interrupts (NMI) and System Management Interrupts (SMI).

What Is a Non-Maskable Interrupt (NMI)?

A Non-Maskable Interrupt is a special processor interrupt that cannot be blocked using the normal interrupt-disable mechanism. It is generally reserved for critical hardware or system events.

Depending on the platform, NMIs can be associated with events such as hardware error reporting, platform diagnostic mechanisms, or other critical conditions.

Because an NMI requires special handling, interrupt processing must follow strict rules. An unexpected second NMI during the first NMI's execution can result in an unrecoverable situation.

What Is a System Management Interrupt (SMI)?

A System Management Interrupt is a processor interrupt used by platform firmware to enter System Management Mode (SMM). This is a special processor execution mode commonly used for hardware and platform management functions.

SMI handling is generally implemented through system firmware, such as BIOS or UEFI firmware, rather than ordinary Windows applications.

Firmware executing in System Management Mode can manage certain hardware operations independently of the normal operating system execution environment.

How Can an SMI Lead to RECURSIVE_NMI?

Microsoft documents a specific interrupt-handling sequence associated with this bug check:

1. An NMI occurs and Windows or the platform begins processing it.
2. An SMI interrupts the NMI-handling process.
3. An error in the SMI code causes interrupts to become enabled.
4. Execution continues with NMIs enabled.
5. Another NMI occurs before the original NMI has finished processing.
6. Windows detects the recursive NMI condition and triggers bug check 0x00000111.

This sequence explains why RECURSIVE_NMI is associated with low-level interrupt and firmware handling rather than a typical software application failure.

Common Symptoms of RECURSIVE_NMI BSOD

A computer experiencing this bug check may exhibit the following symptoms:

• A sudden Blue Screen of Death with the stop code 0x00000111.
• The message RECURSIVE_NMI displayed on the crash screen.
• An unexpected restart after the system encounters a fatal error.
• Loss of unsaved work because Windows cannot continue normal operation.
• Repeated crashes if the underlying platform condition occurs again.
• A crash dump generated during the bug check, if dump collection is configured and succeeds.

The exact symptoms and frequency depend on the circumstances in which the interrupt-handling failure occurs.

Possible Causes and Technical Considerations

Microsoft's documentation specifically associates RECURSIVE_NMI with an error in SMI code that allows another NMI to interrupt an NMI already in progress.

The following areas may therefore be relevant when investigating a system affected by this error. They are investigation targets, not independently confirmed causes of every 0x00000111 crash.

1. System Firmware or BIOS/UEFI Issues

System firmware is responsible for various platform-level hardware management functions, including SMI handling. A firmware implementation defect may result in incorrect interrupt handling.

Check whether the computer has a newer BIOS or UEFI release from its manufacturer, particularly if the crash started after a firmware update, hardware change, or platform configuration change.

2. Firmware Compatibility or Configuration Problems

Changes to firmware settings or platform configuration may be relevant when investigating an interrupt-related failure.

For example, recent changes to CPU, memory, power-management, or hardware-related firmware settings should be documented and reviewed. However, the stop code alone does not identify a particular setting as responsible.

3. Hardware or Platform-Level Problems

Because NMIs are associated with low-level system events, hardware and platform conditions may be relevant to the investigation.

Depending on the system and available diagnostic evidence, technicians may examine:

• Processor and motherboard operation.
• Memory stability and hardware configuration.
• Power delivery and system stability.
• Recently installed or replaced hardware.
• Platform-specific hardware diagnostic records.

These are diagnostic areas rather than a list of proven direct causes of this specific bug check.

4. Firmware Changes or Updates

If the crash began immediately after a BIOS or UEFI update, firmware configuration change, or hardware modification, the timing may provide useful diagnostic evidence.

Compare the firmware version and configuration before and after the change. Do not assume that every firmware update or recent hardware modification is responsible without additional evidence.

How to Troubleshoot Windows Stop Code 0x00000111

Because RECURSIVE_NMI is associated with low-level interrupt handling, troubleshooting should focus on collecting reliable crash evidence and investigating the system platform.

Follow the steps below in order, starting with evidence collection and non-disruptive checks.

Step 1: Record the BSOD Information

Before making any changes, record the information displayed on the Blue Screen of Death.

• Stop code: 0x00000111.
• Bug check name: RECURSIVE_NMI.
• Date and time of the crash.
• What the computer was doing when the crash occurred.
• Any recent BIOS, firmware, hardware, or Windows configuration changes.
• Whether the crash occurred once or repeatedly.

This information helps establish a timeline and makes it easier to compare the crash with system logs and diagnostic records.

Step 2: Check Windows Event Viewer

Windows Event Viewer can provide information about unexpected shutdowns and recorded bug checks.

1. Press Windows + R.
2. Type eventvwr.msc and press Enter.
3. Expand Windows Logs.
4. Select System.
5. Look for events around the time of the crash.
6. Review relevant entries from sources such as BugCheck, Kernel-Power, and EventLog.

Pay particular attention to the following event IDs when present:

• Event ID 1001: Windows Error Reporting or bug check information, which may include the stop code and dump-file location.
• Event ID 41: Kernel-Power event indicating that Windows restarted without a clean shutdown.
• Event ID 6008: Event Log entry indicating that the previous shutdown was unexpected.

Event ID 41 and Event ID 6008 do not independently identify the root cause. They indicate an unexpected shutdown and must be interpreted alongside other evidence.

Step 3: Locate the Windows Crash Dump

Crash dump files can preserve information about the system state when Windows encounters a bug check.

Check the following locations:

• C:\Windows\Minidump – Contains small memory dump files when configured and successfully generated.
• C:\Windows\MEMORY.DMP – Common location for a kernel or complete memory dump, depending on the configured dump type.

If no dump file exists, check the Windows startup and recovery settings, available disk space, paging-file configuration, and whether dump collection was able to complete.

To review dump settings:

1. Open System Properties.
2. Select the Advanced tab.
3. Under Startup and Recovery, select Settings.
4. Review the Write debugging information option.
5. Check the configured dump type and dump-file location.

Do not delete existing crash dumps before preserving copies that may be required for technical analysis. Memory dumps can contain sensitive information, so store and share them securely.

Step 4: Analyze the Crash Dump Using WinDbg

Windows Debugger (WinDbg) is a Microsoft debugging tool that can be used to examine Windows crash dump files.

Install WinDbg from the official Microsoft source:

Microsoft Learn – Windows Debugging Tools.

To perform an initial dump analysis:

1. Open WinDbg.
2. Select the option to open a dump file.
3. Browse to the relevant .dmp file.
4. Allow the debugger to load the dump and initialize its symbols.
5. Enter the following command in the debugger command window:

!analyze -v

The command requests a detailed analysis of the crash dump.

Review the following information where available:

• Bug check code and parameters.
• Exception and processor context information.
• Available stack information.
• Loaded modules and relevant system components.
• Additional diagnostic information reported by the debugger.

RECURSIVE_NMI is a specialized bug check. A normal dump analysis may not identify the firmware component or exact platform-level condition responsible for the failure.

Do not assume that a driver or module appearing in the dump is automatically the root cause. Additional hardware and firmware investigation may be required.

Step 5: Check the Computer Manufacturer's BIOS or UEFI Updates

Since Microsoft identifies an SMI-handling error in the documented failure sequence, system firmware is an important area to investigate.

1. Identify the exact computer model or motherboard model.
2. Check the currently installed BIOS or UEFI version.
3. Visit the manufacturer's official support website.
4. Compare the installed firmware version with the available releases.
5. Review the manufacturer's release notes and installation instructions.
6. Determine whether an applicable firmware update addresses platform stability or related hardware issues.

Only install firmware intended for the exact system model and hardware revision.

Important precautions:

• Back up important data before a firmware update.
• Use a reliable power source and follow the manufacturer's instructions.
• Do not interrupt the firmware update process.
• Do not install firmware intended for a different motherboard or computer model.
• Do not attempt an unofficial BIOS downgrade or firmware modification without manufacturer guidance.

A firmware update may help if a relevant platform defect has been corrected, but it is not a guaranteed solution for every RECURSIVE_NMI crash.

Step 6: Review Recent Hardware and Firmware Changes

Consider whether the crash started after a hardware installation, component replacement, or firmware configuration change.

1. Identify recently installed hardware components.
2. Review any recent CPU, memory, motherboard, or expansion-card changes.
3. Check whether the hardware is supported by the computer or motherboard manufacturer.
4. Review any firmware settings that were changed before the first crash.
5. If appropriate, consult the manufacturer before reverting a configuration change.

For a desktop computer, technicians may also inspect physical connections and hardware installation, following appropriate electrostatic-discharge precautions.

Avoid repeatedly changing firmware settings because this can introduce additional variables and make diagnosis more difficult.

Step 7: Run Manufacturer Hardware Diagnostics

Use the computer manufacturer's built-in or downloadable diagnostic tools to examine the hardware.

Depending on the system, available tests may include:

• Memory diagnostics.
• Processor and system-board diagnostics.
• Storage health checks.
• Power and thermal diagnostics.
• Platform-specific extended hardware tests.

Record diagnostic results and any reported error codes. A successful diagnostic test does not necessarily rule out intermittent hardware or firmware problems.

Step 8: Review Windows and Driver Updates

Although the documented RECURSIVE_NMI failure mechanism involves SMI and NMI handling, reviewing recent Windows and driver changes can still help establish whether the system environment changed before the crash.

1. Open Settings.
2. Navigate to Windows Update.
3. Check the update history.
4. Identify updates installed shortly before the first crash.
5. Review relevant hardware-driver updates through the computer manufacturer's support resources.

Install applicable stable updates using official sources. If a crash clearly started after a specific update, investigate that update using supported recovery or rollback procedures.

Do not randomly remove drivers or use third-party driver-update utilities as a substitute for identifying the actual cause.

Advanced Troubleshooting for IT Professionals

When the 0x00000111 error occurs repeatedly, especially on business-critical systems, a deeper platform-level investigation may be necessary.

1. Compare Crash Dumps

Compare multiple crash dumps to determine whether the same bug check and similar processor or system context appear consistently.

Repeatedly occurring failures under similar conditions may provide useful evidence for identifying a platform-level problem.

2. Review Firmware Release Notes

Check the system manufacturer's firmware documentation for relevant stability, processor, chipset, or platform-management fixes.

Do not assume that a release note mentioning general system stability necessarily addresses RECURSIVE_NMI. Confirm applicability with the manufacturer when necessary.

3. Examine Hardware and Platform Diagnostic Records

Review available manufacturer diagnostic logs and platform hardware records. On supported systems, Windows Hardware Error Architecture (WHEA) records may also provide additional hardware error information.

However, the presence or absence of WHEA events does not independently confirm or rule out the SMI-handling failure described by Microsoft.

4. Engage the Hardware Manufacturer

If the crash continues after basic investigation, provide the system manufacturer or hardware support team with:

• Computer or motherboard model.
• BIOS or UEFI version.
• Windows edition, version, and build.
• Crash timestamps and bug check parameters.
• Available memory dump files.
• Event Viewer records around the crash.
• Hardware diagnostic results.
• Details of recent firmware and hardware changes.

For enterprise systems, contact the server or hardware vendor before making disruptive changes to production equipment.

What Not to Do When RECURSIVE_NMI Occurs

Because this error involves a low-level interrupt-handling condition, generic Windows repair procedures may not address the underlying problem.

Avoid the following actions unless supported by diagnostic evidence or manufacturer instructions:

• Do not immediately reinstall Windows: The documented error involves SMI and NMI handling, which may require firmware-level investigation.
• Do not randomly modify BIOS settings: Unnecessary firmware changes can introduce further instability.
• Do not flash an unrelated BIOS: Incorrect firmware can make the computer unusable.
• Do not replace RAM or the motherboard without testing: The stop code alone does not identify a defective component.
• Do not delete crash dumps: These files may be important for identifying the failure.
• Do not assume every driver is responsible: The documented failure mechanism is more specific than a general driver-related crash.

How to Prevent RECURSIVE_NMI Errors

It may not be possible for users to prevent every firmware-level interrupt failure, but good system maintenance can reduce avoidable configuration and stability problems.

• Keep BIOS or UEFI firmware updated using the computer manufacturer's supported releases.
• Install hardware components supported by the system manufacturer.
• Follow recommended firmware configuration settings.
• Avoid unnecessary firmware modifications and unofficial firmware images.
• Maintain reliable power and appropriate system cooling.
• Keep Windows and relevant hardware drivers updated through trusted sources.
• Preserve crash dumps and diagnostic records when investigating recurring crashes.
• Maintain regular backups of important business and personal data.

Frequently Asked Questions

1. What does stop code 0x00000111 mean?

Stop code 0x00000111 is named RECURSIVE_NMI. It indicates that a non-maskable interrupt occurred while another NMI was already being processed.

2. Is RECURSIVE_NMI a hardware or software error?

Microsoft documents this bug check in connection with an error in System Management Interrupt (SMI) code. Because SMI handling is generally performed by platform firmware, firmware-level investigation is particularly relevant. Hardware and software evidence may also be useful during diagnosis.

3. Can a BIOS update fix the 0x00000111 error?

A BIOS or UEFI update may help if the manufacturer has corrected a relevant firmware problem. However, a firmware update is not guaranteed to resolve every occurrence. Check the exact system model, firmware release notes, and manufacturer instructions before updating.

4. Is RECURSIVE_NMI related to RAM failure?

The stop code does not directly identify faulty RAM. Memory diagnostics may be included in a broader hardware investigation, but RAM should not be replaced solely because Windows reports 0x00000111.

5. Can outdated device drivers cause RECURSIVE_NMI?

Drivers may be relevant to a broader system stability investigation, but Microsoft's documented explanation specifically describes an SMI-handling error that allows a second NMI to occur during an existing NMI. A driver should not be blamed without supporting evidence.

6. Where can I find the RECURSIVE_NMI crash dump?

Check C:\Windows\Minidump for small memory dumps and C:\Windows\MEMORY.DMP for a configured kernel or complete memory dump. The actual location depends on the Windows dump configuration and whether the dump was successfully written.

7. Does reinstalling Windows resolve RECURSIVE_NMI?

Reinstalling Windows is not an established universal fix for this error. Since the documented failure involves SMI and NMI handling, investigate the firmware, platform configuration, and crash dump before considering an operating system reinstallation.

8. When should I contact technical support?

Contact the computer or motherboard manufacturer if the error repeatedly occurs, particularly after firmware or hardware changes, or if crash dump analysis cannot identify the underlying condition. Provide the firmware version, crash information, diagnostic results, and available dump files.

Key Takeaways

• 0x00000111 RECURSIVE_NMI indicates that a second NMI occurred while an earlier NMI was still in progress.
• Microsoft documents an SMI-handling error as the mechanism associated with this bug check.
• System firmware and platform-level interrupt handling are important investigation areas.
• Crash dumps, Event Viewer records, manufacturer diagnostics, and firmware release notes can help with diagnosis.
• A BIOS update may be relevant when an applicable firmware correction is available, but it is not a guaranteed solution.
• Avoid unnecessary operating system reinstalls, random firmware changes, and unsupported hardware replacements.

Official References

• Microsoft Learn – Bug Check 0x111: RECURSIVE_NMI – Official explanation of the stop code and its documented SMI/NMI failure mechanism.
• Microsoft Support – Troubleshooting Windows Unexpected Restarts and Stop Code Errors – General guidance for investigating Windows crashes and unexpected restarts.
• Microsoft Learn – Windows Debugging Tools – Documentation for WinDbg and Windows crash dump analysis.