Windows Stop Code 0x00000080 NMI_HARDWARE_FAILURE – Causes and Troubleshooting

Quick Answer

NMI_HARDWARE_FAILURE (Stop Code 0x00000080) is a Windows blue screen error associated with a Non-Maskable Interrupt (NMI). Microsoft documents this bug check as indicating a hardware malfunction. However, an NMI can also be deliberately triggered through a hardware NMI switch or a supported remote-management interface, so the error does not automatically prove that a component has failed.

To troubleshoot this error, check whether an NMI was intentionally triggered, review recent hardware and driver changes, inspect memory modules for compatibility and stability, run manufacturer-provided hardware diagnostics, and examine available crash dumps. The exact cause can be difficult to determine without additional diagnostic evidence.

What Is NMI_HARDWARE_FAILURE?

NMI_HARDWARE_FAILURE is a Windows bug check with the hexadecimal value 0x00000080. It occurs when Windows receives a Non-Maskable Interrupt and stops normal system execution.

A Non-Maskable Interrupt (NMI) is a special hardware interrupt that cannot be handled like an ordinary maskable interrupt. It is generally used for important hardware notifications and certain system-level diagnostic operations.

Unlike an ordinary software error, an NMI can originate outside the normal application and driver execution flow. Windows may therefore stop the system to prevent it from continuing in an unreliable state or to capture diagnostic information.

What happens when Windows receives an NMI?

1. A hardware device, system controller, or supported management interface generates an NMI.
2. The processor receives the interrupt.
3. Windows processes the interrupt according to its NMI-handling behavior.
4. Windows generates bug check 0x00000080.
5. A blue screen appears, and Windows may create a memory dump before restarting, depending on the recovery configuration.

Microsoft documents this behavior as intentional in supported Windows versions beginning with Windows 8 and Windows Server 2012. In these versions, receiving an NMI results in bug check 0x80 rather than the older configurable behavior.

Common Causes of NMI_HARDWARE_FAILURE

Microsoft identifies multiple possible hardware malfunctions but does not provide a single definitive list of components responsible for this bug check. The following are practical areas to investigate, not confirmed causes in every case.

1. Faulty or incompatible RAM

Unstable or defective memory can cause system instability. Problems may also occur when incompatible memory modules are installed together.

Check for:

• Defective RAM modules.
• Memory modules that are not compatible with the motherboard.
• Mixed memory types or unsupported memory configurations.
• Incorrect memory speed or timing settings.
• Unstable XMP or EXPO memory profiles.
• Poorly seated memory modules.

Microsoft specifically recommends ensuring that all memory modules are of the same type when investigating this bug check. Actual compatibility should also be confirmed against the motherboard or computer manufacturer's specifications.

2. Motherboard or system board problems

The motherboard connects the processor, memory, storage, expansion cards, and other hardware. A hardware fault involving the motherboard or its associated controllers may result in system instability or hardware interrupts.

Possible areas for inspection include memory slots, expansion-card connections, motherboard power connections, and hardware monitoring or interrupt controllers.

3. Processor-related instability

A processor or its supporting platform may become unstable because of hardware defects, excessive temperatures, unsupported operating settings, or unstable overclocking.

Check whether the problem started after changing CPU frequency, voltage, or other firmware-level performance settings.

4. Power supply or power delivery problems

An unstable power supply or faulty power connection can affect the reliability of the computer's hardware components.

Investigate this possibility if the computer also experiences unexpected shutdowns, restarts, instability under heavy workloads, or other power-related symptoms.

These symptoms are diagnostic clues, not proof that the power supply caused bug check 0x80.

5. Graphics card or other expansion hardware

A malfunctioning graphics card, PCIe device, storage controller, or other expansion component may contribute to hardware instability.

Pay particular attention to recently installed hardware and devices that were moved, upgraded, or reconnected before the crashes started.

6. BIOS or UEFI firmware problems

BIOS or UEFI firmware controls important hardware initialization and platform configuration. Outdated, incompatible, or incorrectly configured firmware may contribute to system instability.

Investigate firmware settings if the problem started after a BIOS update, hardware upgrade, memory configuration change, or overclocking adjustment.

7. Recently installed hardware or drivers

New hardware and its associated drivers can introduce compatibility or stability problems. Microsoft recommends removing recently installed hardware or drivers when investigating NMI_HARDWARE_FAILURE.

Consider recently installed graphics drivers, storage controllers, network adapters, expansion cards, and other device drivers.

8. An intentionally triggered NMI

Not every occurrence of this stop code indicates an accidental hardware malfunction.

Some servers and specialized systems provide an NMI switch or remote-management function that administrators can use to deliberately trigger a system crash and collect diagnostic information.

Microsoft confirms that manually triggering an NMI can produce the NMI_HARDWARE_FAILURE blue screen. If the error occurred during maintenance, testing, or remote server administration, verify whether an NMI was intentionally issued before replacing hardware.

Symptoms of NMI_HARDWARE_FAILURE

Depending on the underlying event, users may experience one or more of the following symptoms:

• A sudden blue screen displaying NMI_HARDWARE_FAILURE.
• Stop code 0x00000080 displayed during a system crash.
• Unexpected computer restarts.
• System crashes during gaming, rendering, or other demanding workloads.
• Repeated crashes after installing new hardware.
• Intermittent system freezes or unexpected shutdowns.
• Memory dump files generated after a crash.
• Repeated crashes during system startup or hardware initialization.

These symptoms are not exclusive to this error. Their timing and relationship with hardware or software changes can help narrow the investigation.

Before You Begin Troubleshooting

Before making system changes, collect the following information:

• The exact stop code and any additional blue screen message.
• The computer manufacturer and model.
• The installed Windows version and build.
• Whether the crash happened once or repeatedly.
• Any recently installed hardware, drivers, or firmware updates.
• Whether memory overclocking or CPU overclocking is enabled.
• Whether an NMI switch or remote-management crash command was used.
• Any available crash dump files and relevant system event logs.

If the computer contains important business or personal data, ensure that a current backup exists before attempting hardware changes or firmware updates.

How to Fix NMI_HARDWARE_FAILURE 0x00000080

Follow the troubleshooting procedures in order. Start with the simplest checks and proceed to hardware diagnostics and advanced crash analysis if the error continues.

1. Restart the Computer and Check Whether the Error Repeats

If the blue screen occurred only once, allow Windows to restart and observe whether the computer operates normally.

1. Allow Windows to complete the restart.
2. Check whether the computer reaches the desktop normally.
3. Observe whether the same blue screen appears again.
4. Record the activities being performed immediately before another crash.

A single occurrence following an intentionally triggered NMI may not indicate a persistent hardware problem. Repeated unexplained occurrences require further investigation.

2. Disconnect Recently Added External Hardware

If the problem started after connecting a new external device, disconnect nonessential peripherals and check whether system stability improves.

1. Shut down the computer normally.
2. Disconnect recently added USB devices, external storage, docks, and other nonessential peripherals.
3. Keep essential devices such as the keyboard, mouse, and required display connected.
4. Start Windows and observe whether the problem returns.
5. Reconnect devices individually to identify whether a particular device is associated with the crash.

Do not disconnect internal hardware while the computer is powered on.

3. Check Recently Installed Hardware

If the error appeared after a hardware upgrade, investigate the newly installed component first.

1. Review the date when the new component was installed.
2. Check whether it is supported by the motherboard and Windows version.
3. Verify that the component is properly connected.
4. Consult the manufacturer's hardware compatibility information.
5. If practical, have the newly installed component tested or temporarily removed by a qualified technician.

Microsoft recommends removing recently installed hardware when investigating this bug check. If the problem disappears after removing a component, that provides useful evidence but does not by itself establish whether the component, its connection, or a compatibility issue was responsible.

4. Test RAM for Hardware Errors

Memory instability is an important area to investigate, particularly when the computer crashes unpredictably or the error started after a RAM upgrade.

Use the computer manufacturer's memory diagnostic

Many computer manufacturers provide built-in UEFI diagnostics or bootable hardware diagnostic utilities.

1. Identify the exact computer or motherboard model.
2. Visit the manufacturer's official support website.
3. Locate the memory diagnostic utility for the model.
4. Follow the manufacturer's instructions to run the memory test.
5. Record any reported errors and diagnostic codes.

Some systems also provide extended memory testing, which may take longer but can be useful when intermittent memory problems are suspected.

Check Windows Memory Diagnostic

Windows includes a built-in memory testing utility called Windows Memory Diagnostic.

1. Press Windows + R.
2. Enter the following command:

mdsched.exe

1. Select Restart now and check for problems (recommended) if you can safely restart the computer.
2. Allow the memory diagnostic to complete.
3. After Windows restarts, check the diagnostic result.

Important: Save open files and close applications before starting the test. The computer will restart to perform the diagnostic.

A memory test that reports errors provides evidence of a memory subsystem problem. A test that reports no errors does not completely rule out intermittent RAM, motherboard, memory-controller, or configuration problems.

5. Check RAM Compatibility and Installation

If the computer has multiple memory modules, verify that they are compatible and installed according to the motherboard manufacturer's recommendations.

Check the following:

• All installed modules are supported by the motherboard.
• The memory type and specifications are compatible.
• The modules are installed in the recommended slots.
• The modules are properly seated.
• No memory module or slot shows visible physical damage.
• Memory frequency and timing settings are supported.

If memory was recently upgraded, consult the motherboard manual for the recommended DIMM configuration.

6. Check CPU Temperature and System Cooling

Excessive temperatures can contribute to system instability. Check whether the computer is experiencing overheating, especially if crashes occur during demanding workloads.

Use the computer manufacturer's hardware monitoring utility or supported firmware monitoring interface to inspect CPU temperatures and cooling status.

Check for:

• Cooling fans that are not operating correctly.
• Blocked air vents or dust accumulation.
• Unusual fan noise.
• Cooling system or heatsink problems.
• Temperature readings outside the manufacturer's recommended operating range.

Do not assume that overheating caused the NMI_HARDWARE_FAILURE error solely because the computer becomes hot. Confirm the temperature readings and investigate other possible causes.

7. Update or Roll Back Device Drivers

Although Microsoft identifies this bug check as hardware-related, recently installed drivers should also be investigated, particularly when the problem began immediately after a driver update or hardware installation.

Update drivers

1. Right-click the Start button.
2. Select Device Manager.
3. Locate the relevant hardware category.
4. Right-click the device and select Update driver.
5. Follow the available update options or install the appropriate driver from the manufacturer's official website.
6. Restart Windows if required.

Prioritize drivers associated with recently installed hardware. Avoid installing unrelated third-party driver packages or utilities that promise automatic driver repairs.

Roll back a recently updated driver

If the problem started immediately after a driver update, restoring the previous driver may help determine whether the update is involved.

1. Open Device Manager.
2. Right-click the affected device and select Properties.
3. Open the Driver tab.
4. Select Roll Back Driver if the option is available.
5. Follow the instructions and restart Windows if prompted.

Administrator permissions are required. The rollback option may be unavailable if Windows does not have a previous driver version available.

8. Check BIOS or UEFI Settings

If the error started after changing firmware settings, investigate those changes before attempting a firmware update.

Pay particular attention to:

• CPU overclocking and voltage settings.
• XMP or EXPO memory profiles.
• Manual memory frequency and timing settings.
• Recently changed hardware configuration options.
• Firmware settings related to power management.

If the computer was overclocked, consider returning the affected settings to manufacturer-supported defaults.

If necessary, use the motherboard manufacturer's documented procedure to restore default firmware settings.

9. Update BIOS or UEFI Firmware When Appropriate

If the manufacturer has released a firmware update addressing hardware compatibility, stability, or a relevant platform issue, installing it may be appropriate.

1. Identify the exact computer or motherboard model and revision.
2. Visit the manufacturer's official support website.
3. Review the firmware release notes and supported update procedure.
4. Confirm that the update applies to the installed hardware.
5. Follow the manufacturer's update instructions exactly.
6. Allow the firmware update to complete without interrupting power.

Do not install firmware from another motherboard model or use unofficial firmware packages. A failed firmware update can prevent the computer from starting.

A firmware update should not be treated as a guaranteed fix for NMI_HARDWARE_FAILURE. Perform it only when there is a relevant reason to do so.

10. Inspect Windows Event Logs

Windows Event Viewer can provide additional information about system crashes, unexpected restarts, and hardware-related events.

1. Press Windows + R.
2. Enter:

eventvwr.msc

1. Expand Windows Logs.
2. Select System.
3. Look for events recorded immediately before and after the blue screen.
4. Review the event source, ID, timestamp, and detailed message.
5. Compare the event timeline with the time of the crash.

Pay attention to relevant hardware, firmware, driver, and bug-check records. Event ID 1001 may contain bug-check information, while Kernel-Power event ID 41 may record that Windows restarted without a clean shutdown.

Important: Kernel-Power event ID 41 records an unexpected shutdown or restart. It does not independently identify the underlying cause.

Look for recurring events that consistently occur immediately before the crash rather than assuming that every nearby warning or error caused the problem.

11. Analyze the Windows Crash Dump Using WinDbg

For repeated or unexplained crashes, memory dump analysis can help an IT technician investigate the system state at the time of the bug check.

Microsoft recommends using the WinDbg debugging tools and the !analyze extension to investigate crash dumps.

Locate the crash dump file

Windows may store crash dump files in the following locations:

The actual file location depends on the configured dump type and system settings. A dump file may not exist if Windows could not complete the dump operation or memory dump collection was not configured.

Configure automatic memory dump collection

1. Open Windows Search.
2. Search for Advanced system settings.
3. Open the Advanced tab in System Properties.
4. Under Startup and Recovery, select Settings.
5. Under Write debugging information, select Automatic memory dump.
6. Confirm the changes and restart the computer if necessary.

Ensure that the Windows system drive has sufficient free space and that the required page file configuration is maintained. Crash dump collection is not guaranteed if the system fails before it can write the dump.

Analyze the dump file

1. Download and install WinDbg from Microsoft's official documentation or supported distribution.
2. Open WinDbg.
3. Select File > Open dump file.
4. Select the relevant .dmp file.
5. Allow the debugger to load the dump and available symbols.
6. Enter the following command in the debugger command window:

!analyze -v

This command requests a detailed analysis of the crash dump.

Review the following information where available:

• Bug check code and bug-check details.
• Stack trace and relevant system activity.
• Loaded driver and module information.
• Hardware-related diagnostic information.
• Any additional evidence that helps identify the component involved.

Important limitation: Microsoft documents that bug check 0x80 has no parameters. Therefore, there are no bug-check parameters to decode for this error. Also, a dump may not contain enough information to identify the exact hardware component that generated the NMI. The absence of a clearly identified driver does not prove that the hardware is defective.

For additional information, refer to Microsoft's documentation on analyzing a kernel-mode dump file using WinDbg.

12. Perform Advanced Hardware Diagnostics

If the error continues after basic troubleshooting, perform a more detailed hardware investigation.

Depending on the computer configuration, this may include:

• Extended RAM testing and individual memory module testing.
• Motherboard and memory slot diagnostics.
• CPU stability and thermal diagnostics.
• Power supply and power delivery testing.
• Graphics card and PCIe device diagnostics.
• Storage controller and other hardware diagnostics.

Use manufacturer-supported diagnostic tools wherever available. If a test reports a hardware failure, record its diagnostic code and provide it to the hardware manufacturer or service technician.

For business servers and workstations, review the hardware management controller logs and any manufacturer-specific hardware event records. Some enterprise systems record more detailed information about memory errors, watchdog events, and hardware interrupts than Windows alone.

Advanced Troubleshooting for IT Support Technicians

When basic troubleshooting does not identify the cause, IT support technicians can use a structured investigation approach.

Verify whether the NMI was intentional

Check whether the computer or server supports an NMI switch or remote-management NMI operation. Review maintenance records, management-controller logs, and administrator activity around the crash timestamp.

This check is particularly important on enterprise servers because an intentionally triggered NMI may generate the same 0x80 stop code.

Correlate crash dumps with hardware event records

Compare the crash timestamp with relevant system logs and hardware-management records. Repeated memory error reports, watchdog events, or other platform-specific hardware alerts may provide useful evidence.

Do not treat an isolated Windows event or a module name in a dump as definitive proof of the failing component.

Use WinDbg and Microsoft debugging documentation

For systems that repeatedly crash, examine available dump files and compare their analysis results. A recurring pattern across multiple crashes may help narrow the investigation.

Useful Microsoft references include:

• Bug Check 0x80: NMI_HARDWARE_FAILURE
• !analyze WinDbg command reference
• Analyze bug check and stop code error data

Driver Verifier is another advanced Windows diagnostic utility, but it should not be the first troubleshooting step for this particular hardware-oriented bug check. It deliberately stresses driver behavior, can generate additional crashes, and may make a system difficult to start. Use it only when there is specific evidence suggesting a third-party driver problem and an experienced technician can manage recovery.

How to Verify Whether the Problem Is Resolved

After completing the relevant troubleshooting procedure, monitor the computer for recurring errors.

• Confirm that Windows starts and operates normally.
• Check whether the same 0x00000080 stop code appears again.
• Run the relevant memory or hardware diagnostics again if indicated.
• Review Event Viewer for new hardware-related errors.
• Check whether the system remains stable during the workload that previously triggered the crash.
• Confirm that firmware and driver changes have not introduced additional problems.

A successful restart alone does not establish that the underlying problem has been resolved. For recurring hardware instability, longer observation and appropriate diagnostic testing may be necessary.

When Should You Contact a Hardware Technician?

Contact the computer or component manufacturer, an authorized service centre, or a qualified hardware technician when:

• The blue screen continues to appear after basic troubleshooting.
• Memory diagnostics report errors.
• The computer experiences repeated unexpected shutdowns.
• There are signs of motherboard, CPU, or power supply instability.
• BIOS or firmware updates fail or cause startup problems.
• The system cannot boot into Windows reliably.
• Crash dump analysis does not provide enough evidence to identify the problem.

Provide the technician with the computer model, Windows version, stop code, diagnostic results, crash dump files, and a timeline of recent hardware or software changes.

Frequently Asked Questions

1. What does NMI_HARDWARE_FAILURE 0x00000080 mean?

It is a Windows bug check associated with a Non-Maskable Interrupt. Microsoft documents it as indicating a hardware malfunction, although an intentionally triggered NMI can also produce the same error.

2. Is NMI_HARDWARE_FAILURE always caused by faulty RAM?

No. RAM is one possible area to investigate, but the error can involve various hardware malfunctions. Motherboard, processor, expansion hardware, firmware, and other platform-related issues may also need investigation.

3. Can a driver cause NMI_HARDWARE_FAILURE?

A recently installed or incompatible driver should be investigated, particularly when the problem started after a driver change. However, the 0x80 bug check itself does not establish that a driver is responsible.

4. Can NMI_HARDWARE_FAILURE occur without a hardware failure?

Yes. An administrator can deliberately trigger an NMI through supported hardware or remote-management functionality. Windows may then generate bug check 0x80 as part of its documented NMI-handling behavior.

5. Does NMI_HARDWARE_FAILURE mean I need to replace my motherboard?

No. The stop code alone does not identify the motherboard as the failed component. Hardware diagnostics, crash dump analysis, and manufacturer testing should be used to establish whether motherboard replacement is necessary.

6. Does this error cause data loss?

An unexpected system crash can result in loss of unsaved work. Files being written at the time of the crash may also be affected. Maintain regular backups, particularly when the error occurs repeatedly.

7. Can updating BIOS fix NMI_HARDWARE_FAILURE?

A relevant BIOS or UEFI update may address a documented firmware or hardware compatibility problem. However, updating firmware is not a guaranteed solution. Check the manufacturer's release notes and update instructions before proceeding.

8. What is the difference between NMI_HARDWARE_FAILURE and a normal blue screen error?

NMI_HARDWARE_FAILURE is specifically associated with a Non-Maskable Interrupt. Many other blue screen errors are associated with particular driver, memory-management, operating-system, or device operations. The diagnostic approach should therefore be based on the specific stop code and available evidence.

Sources

• Microsoft Learn – Bug Check 0x80: NMI_HARDWARE_FAILURE
• Microsoft Learn – NMI_HARDWARE_FAILURE Error When an NMI Is Triggered on Windows
• Microsoft Learn – Advanced Troubleshooting for Stop Code Errors
• Microsoft Learn – Analyze a Kernel-Mode Dump File by Using WinDbg
• Microsoft Learn – Analyze Bug Check (Stop Code Error) Data
• Microsoft Support – Update Drivers Through Device Manager in Windows