Ntoskrnl.exe Failed? How to Fix the BSOD in Windows 11

Seeing “ntoskrnl.exe failed” after a Windows 11 crash does not usually mean the Windows kernel file itself is damaged. Crash-reporting tools often name ntoskrnl.exe because the kernel was active when Windows stopped, while a faulty driver, unstable memory, storage error, BIOS setting, or hardware problem caused the failure earlier.

That distinction matters. Replacing ntoskrnl.exe, downloading a copy from a DLL website, or reinstalling random drivers can make the PC less stable without addressing the real fault. The useful evidence is the stop code, the circumstances surrounding the crash, and the pattern in one or more memory dumps.

Windows 11 may show a blue or black stop-error screen depending on its version. Record the stop code displayed near the bottom, such as MEMORY_MANAGEMENT, IRQL_NOT_LESS_OR_EQUAL, or DPC_WATCHDOG_VIOLATION, before the computer restarts.

What Ntoskrnl.exe Actually Tells You

ntoskrnl.exe is the Windows NT operating system kernel. It handles core operations involving memory, processes, scheduling, hardware communication, and other low-level Windows functions. Almost every system crash passes through kernel code, so finding its name in BlueScreenView or a dump summary is not a diagnosis by itself.

Microsoft explains that a Windows stop error can be caused by a hardware device, driver, or software. The stop screen may list the module whose code was executing when the failure occurred, but that module is only one piece of evidence. The current Microsoft stop-error guidance recommends using the stop code and memory-dump analysis for deeper troubleshooting.

Use this distinction when reading a crash report:

What the report shows	What it means
ntoskrnl.exe appears once	The kernel recorded the crash, but the cause is still unknown
The same third-party .sys file appears in several dumps	That driver or its associated hardware deserves investigation
Different stop codes appear in different crashes	RAM instability, overclocking, power, storage, or broader hardware problems become more likely
Crashes began immediately after a driver or Windows update	Test a rollback or manufacturer-approved replacement
Crashes occur only during gaming or heavy load	Check the GPU driver, temperatures, power delivery, RAM profile, and overclocking
MEMORY_MANAGEMENT is the repeated stop code	Test memory stability and follow a memory-specific diagnostic path

Do not decide from a single “caused by driver” line. Compare multiple crashes when possible and look for a repeated stop code, third-party module, or activity that triggers the failure.

Record the Stop Code and Crash Pattern First

Write down the exact stop code rather than searching only for ntoskrnl.exe. Also note what was happening immediately before the restart:

• Did the crash begin after a graphics, chipset, storage, or network driver update?
• Does it happen while gaming, waking from sleep, transferring files, or sitting idle?
• Was new RAM, a GPU, an SSD, or another device recently installed?
• Are XMP, EXPO, CPU overclocking, GPU tuning, or undervolting enabled?
• Does the same stop code appear every time?

Windows may restart too quickly to read the screen. Open Control Panel > System and Security > System > Advanced system settings. Under Startup and Recovery, select Settings, then clear Automatically restart. This does not fix the crash, but it keeps the stop screen visible long enough to record the details.

When Windows cannot stay running normally, use Safe Mode in Windows 11 to remove a recently installed driver or application. A PC that remains stable in Safe Mode points more strongly toward a third-party driver, startup service, or software component.

Find the Windows Minidump

Windows normally stores small crash dumps here:

C:\Windows\Minidump

Each .dmp filename usually contains the crash date. Copy the newest file to the Desktop before opening it if WinDbg reports a permission error.

An empty or missing Minidump folder can mean Windows did not create a dump. Check the setting:

1. Press Windows + R.
2. Enter sysdm.cpl and press Enter.
3. Open the Advanced tab.
4. Select Settings under Startup and Recovery.
5. Set Write debugging information to Small memory dump.
6. Confirm that the directory is %SystemRoot%\Minidump.
7. Make sure the Windows system drive has adequate free space.

The setting applies to future crashes. It cannot recreate a dump from an earlier BSOD.

Memory dumps can contain fragments of information that were present in memory during a crash. Avoid posting them publicly without considering privacy, especially when the computer handles confidential work.

Analyze the Crash in WinDbg

WinDbg provides more evidence than relying only on the filename reported by a simplified crash viewer.

Install WinDbg from the Microsoft Store, then:

1. Open WinDbg.
2. Select File > Open dump file.
3. Choose the newest .dmp file copied from C:\Windows\Minidump.
4. Wait while WinDbg loads the dump and downloads the required symbols.
5. Enter the following command in the command area:

!analyze -v

Open the newest Windows minidump in WinDbg. The image is an annotated interface illustration.

Microsoft documents !analyze -v as the verbose analysis command for the most recent bug check. The WinDbg !analyze reference explains its supported parameters and output.

Look for these fields:

• BUGCHECK_CODE or the named bug check, which identifies the type of stop error.
• MODULE_NAME, which may identify the module involved.
• IMAGE_NAME, which may show a driver filename ending in .sys.
• PROCESS_NAME, which shows the active process but does not necessarily make that application responsible.
• FAILURE_BUCKET_ID, which groups similar failures.
• STACK_TEXT, which shows the sequence of calls leading toward the crash.

Example WinDbg output showing where to inspect the bug check and driver fields. The sample driver is illustrative and is not a diagnosis of your computer.

The words Probably caused by or a single IMAGE_NAME can still be wrong, particularly in a small dump with limited context. Stronger evidence comes from the same non-Microsoft driver appearing in several dumps with the same stop code.

To inspect a driver named in the results, replace drivername with the module name without .sys:

lmvm drivername

This can show the module path, vendor, timestamp, and version. An old timestamp alone does not prove that the driver caused the crash, but it helps you identify the correct device and update source.

Follow the Repair Path Supported by the Dump

The correct repair depends on what repeats in the crash evidence.

A third-party driver appears repeatedly

Match the .sys file to its device or software vendor. Update the driver from the computer manufacturer, motherboard manufacturer, or hardware vendor rather than using a bulk driver-updater application.

When crashes began immediately after an update, rolling back to the last stable driver can be more useful than reinstalling the newest release. In Device Manager, open the affected device, select Properties > Driver, and use Roll Back Driver when available.

Graphics-driver crashes often occur during games, video editing, streaming, or wake-from-sleep transitions. NVIDIA systems can use the clean installation procedure in How to reinstall NVIDIA drivers on Windows instead of deleting driver files manually.

Avoid removing a driver simply because its name appears once in the stack. Windows may have called that driver normally before another component corrupted memory.

MEMORY_MANAGEMENT or changing stop codes appear

Repeated MEMORY_MANAGEMENT, PFN_LIST_CORRUPT, or apparently unrelated stop codes can indicate unstable RAM or memory corruption caused by a driver.

Return the PC to standard settings before testing:

1. Disable XMP or EXPO temporarily in the BIOS or UEFI.
2. Remove CPU and GPU overclocks, undervolts, and automatic tuning.
3. Reseat recently installed RAM after shutting down and disconnecting power.
4. Run Windows Memory Diagnostic by entering mdsched.exe in the Run dialog.
5. Test matched RAM modules individually when crashes continue and the computer permits it.

A Windows Memory Diagnostic pass does not rule out every intermittent RAM or memory-controller fault. Crashes that stop only when XMP or EXPO is disabled suggest that the selected memory profile is not stable on that CPU and motherboard combination.

For the detailed stop-code-specific process, use How to fix MEMORY_MANAGEMENT BSOD. Keeping those steps on the existing page avoids repeating a full memory troubleshooting guide here.

Crashes point toward storage or file-system activity

Storage problems become more plausible when crashes occur during boot, file transfers, installations, or heavy disk use. Check the Windows-reported drive status:

Get-PhysicalDisk | Select-Object FriendlyName, HealthStatus, OperationalStatus

Then run an online file-system scan:

chkdsk C: /scan

Back up important files promptly if Windows reports drive errors, the SSD disappears intermittently, or the PC produces unusual storage warnings. Do not repeatedly run intensive repair scans on a drive that may be physically failing.

Windows components may be damaged

Use the Windows image repair tool before System File Checker:

DISM /Online /Cleanup-Image /RestoreHealth

After DISM completes, run:

sfc /scannow

Restart Windows and monitor for another crash. These commands can repair protected Windows files, but they cannot fix defective RAM, an unstable BIOS setting, a failing power supply, or a broken third-party driver. When SFC itself fails or cannot repair files, follow SFC /Scannow not working rather than repeating the command indefinitely.

The crashes began after hardware or BIOS changes

Undo one recent change at a time. Remove newly added peripherals, restore default BIOS settings, disable overclocking, and test the original RAM configuration. Check that internal power and data connections are secure only when you are comfortable working inside the computer.

Use the exact support page for the PC or motherboard model when updating BIOS and chipset software. Do not interrupt a BIOS update, install firmware meant for a similar model, or flash firmware while the system has unreliable power.

Temperature and power problems may appear only under load. Record CPU and GPU temperatures during the activity that usually triggers the crash. Sudden restarts, freezes, or different stop codes under gaming load can justify checking cooling, GPU power connections, and the power supply rather than continuing to reinstall Windows files.

What Not to Do With Ntoskrnl.exe

Do not delete, rename, or manually replace C:\Windows\System32\ntoskrnl.exe. Windows protects the file because the operating system requires it to start.

Avoid websites offering an individual ntoskrnl.exe download. The file must match the installed Windows build and servicing state, and an unknown copy may contain malware. DISM, SFC, Windows Update, or an official Windows repair installation are the appropriate ways to restore damaged operating-system components.

Driver Verifier should not be the first troubleshooting step for an ordinary home user. It deliberately stresses selected drivers and can trigger additional crashes or a boot loop. Dump analysis, recent-change testing, manufacturer drivers, memory checks, and standard Windows repair tools provide a safer starting path.

How to Know the Problem Is Fixed

One successful restart is not enough to confirm a repair when the original crash happened intermittently. Use the computer under the same conditions that previously triggered the failure and monitor it for several days.

A useful confirmation includes:

• No new .dmp files appearing in C:\Windows\Minidump.
• No repeated stop-code event in Reliability Monitor.
• Games, sleep and wake, file transfers, or other previous triggers working normally.
• Memory tests completing without errors at the chosen RAM settings.
• The corrected driver remaining installed after Windows Update.

ntoskrnl.exe disappearing from a simplified crash report is less important than the system remaining stable. The real goal is to identify and remove the driver, memory, firmware, storage, temperature, or hardware condition that forced the Windows kernel to stop the computer.