NO_EXCEPTION_HANDLING_SUPPORT (0x0000000B): Meaning and Windows Troubleshooting

Quick Answer

NO_EXCEPTION_HANDLING_SUPPORT is a Windows bug check with the value 0x0000000B. It indicates that Windows encountered an exception condition for which the required handling support was unavailable or could not continue safely. Microsoft states that this bug check appears very infrequently and recommends using the !analyze debugger extension to investigate it. learn.microsoft.com

The code alone does not identify a specific driver, application, or hardware component. If it repeats, record the crash details, investigate recent hardware and driver changes, test in Safe Mode, review Event Viewer, and analyze a memory dump with WinDbg.

What exception handling means

An exception is an event that interrupts normal execution because an operation could not continue in the expected way. Windows and its drivers use exception-handling mechanisms to catch, process, and recover from certain faults.

NO_EXCEPTION_HANDLING_SUPPORT means Windows reached an exception state without the support needed to handle it safely. This is a kernel-level stop condition, not a normal application message such as an application crash dialog.

Microsoft’s code-specific page is intended for programmers and does not provide a general consumer repair. learn.microsoft.com

What the stop code does not prove

The code does not automatically mean:

• A particular application is defective.
• The computer has a virus.
• The CPU or memory is faulty.
• Windows must be reinstalled.
• The module shown in a dump caused the original corruption.
• All drivers need to be replaced.

The process or module active at the time of the stop error is evidence to investigate. It is not final proof of responsibility.

Possible contributing areas

A recurring 0x0000000B crash may involve:

• A defective or incompatible kernel-mode driver.
• Security, storage, graphics, network, or virtualization software.
• A recently installed or updated driver.
• Firmware or chipset compatibility problems.
• Memory corruption or unstable RAM.
• Hardware instability.
• A Windows defect affecting a particular build and configuration.

These are investigation categories, not confirmed causes for every crash.

Symptoms

You may see:

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

Record the exact stop-screen text and any filename shown.

Record the crash details

Before changing the computer, record:

1. The stop-code name and hexadecimal value.
2. All four bug-check parameters.
3. Any “What failed” filename.
4. The date and time of the crash.
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.

Microsoft documents collecting stop-code parameters from the System log and crash dump for analysis. learn.microsoft.com

Initial troubleshooting

Back up important data

Confirm that important files are backed up before changing drivers, hardware, or recovery settings. Some recovery operations can remove applications, settings, or files. support.microsoft.com

Check recent hardware

If hardware was installed shortly 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 among its general stop-error steps. support.microsoft.com

If the problem 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 crashes began.
• Device-status errors.
• Devices that repeatedly disconnect.
• A driver version matching the beginning of the problem.

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

Review kernel-level software

Because exception handling occurs in kernel paths, investigate recently installed or updated:

• Endpoint protection and antivirus drivers.
• Virtual-machine platforms.
• File-system filter drivers.
• Backup software.
• Hardware-monitoring tools.
• Anti-cheat or application-control software.

Do not permanently disable security software on a production system. Prefer a supported vendor update or diagnostic procedure.

Install updates

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

• BIOS or UEFI updates.
• Chipset packages.
• Graphics, storage, and network drivers.
• Firmware updates.
• Compatibility updates for security or virtualization software.

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

Check disk space

Windows requires free space for paging, temporary files, updates, and crash dumps. Microsoft includes checking disk space in its general stop-error guidance. support.microsoft.com

Open Settings > System > Storage and inspect the system drive. Remove only known unnecessary files or move backed-up 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 crash.

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, endpoint protection, virtualization, storage filters, and monitoring tools.

If it 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 events around the crash time. Look for:

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

An event written after the restart may describe the consequence rather than the original fault.

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 include enough context to identify the original driver. If no useful dump exists, configure Write debugging information for a future crash. Microsoft documents using WinDbg or KD to read small memory dumps. Windows Client

Analyze the dump

Open the dump in WinDbg. Microsoft documents starting WinDbg with a dump file and analyzing kernel-mode memory dumps. 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 stack or memory corruption.
• Whether the same module appears in multiple dumps.

Microsoft specifically recommends !analyze for this bug check. learn.microsoft.com

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

Technical guidance for driver developers

Drivers that handle exceptions must preserve the correct kernel execution state and provide valid handling paths.

Review:

• Exception filters and handlers.
• Whether an exception can occur at the current IRQL.
• Whether cleanup runs after a partial operation.
• Whether resources, locks, and references are released on every path.
• Whether user-mode pointers are validated before use.
• Whether asynchronous work can outlive an object or context.
• Driver unload, cancellation, timeout, and error paths.
• Whether a secondary exception occurs while handling the first one.

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

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:

• Deleting the process or module named in the crash.
• Deleting driver files manually.
• Disabling antivirus or endpoint protection permanently.
• Installing generic driver-updater utilities.
• Updating every driver simultaneously.
• Reinstalling Windows before collecting a dump.
• Running Driver Verifier without a recovery plan.
• Changing registry settings or kernel debugging options at random.
• Treating the stop-code name as a hardware diagnosis.

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 stop code, four parameters, dump file, Windows build, computer model, recent changes, and troubleshooting results.

Frequently asked questions

Is NO_EXCEPTION_HANDLING_SUPPORT an application error?

No. It is a Windows kernel bug check. A user application may trigger activity that exposes a kernel defect, but the application name alone does not establish the cause.

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 Windows cannot handle any exceptions?

No. It means Windows encountered a particular kernel exception condition without the support needed to continue safely. It does not mean all exception handling is disabled.

Can Windows Update fix this error?

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

Should I use Driver Verifier?

Only for controlled, advanced diagnosis with a recovery plan. It can cause additional crashes and is not a normal repair step.

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 NO_EXCEPTION_HANDLING_SUPPORT appears very infrequently. The exact dump, driver history, and event timeline are therefore more useful than generic fixes. learn.microsoft.com

Conclusion

NO_EXCEPTION_HANDLING_SUPPORT (0x0000000B) is a rare Windows kernel stop code indicating that the operating system could not safely handle an exception 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 exception paths, cleanup, IRQL restrictions, pointer validation, and resource ownership. Base any repair on evidence from the affected system.

Sources

• Microsoft Learn, Bug Check 0xB: NO_EXCEPTION_HANDLING_SUPPORT. learn.microsoft.com
• 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