How to interpret BSOD codes in Windows 11 step by step

PCHardwarePro » Windows » How to interpret BSOD codes in Windows 11 step by step

If you've been using Windows 11 for a while, you've probably encountered the infamous blue screen of death. That screen where you see a message saying your PC has encountered a problem, a percentage of information gathering, and one or more error codes. You barely have time to read before the computer displays a blue screen and restarts.. Those BSOD (or STOP) codes are the main clue to finding out what went wrong.But interpreting them isn't always as simple as "look at it in the Event Viewer".

Furthermore, in many cases something even more frustrating happens: you try to do what all the guides recommend (check the viewer, open the minidump, use an automatic analyzer…) and you discover that Windows hasn't even been able to create the dump fileThe unexpected shutdown appears in the Event Viewer, yes, but the next entry says that "the dump file creation failed." What do you do then? Is this a serious system failure, or are you looking in the wrong place?

What exactly is a Blue Screen of Death (BSOD) in Windows 11?

A blue screen or BSOD (Blue Screen of Death) is, essentially, Windows' defense mechanism activates when it detects a critical error from which it cannot recover without risking data corruption.When this happens, the system stops everything, displays the blue screen, and forces a restart to protect the integrity of the system and hardware.

In Windows 10 and Windows 11, the typical message that appears is something like “Your PC ran into a problem and needs to restart,” accompanied by an error code in text (like CRITICAL_PROCESS_DIED) and sometimes a STOP code in hexadecimalThat information, although it may seem like gibberish, is the key to knowing whether we are talking about a driver failure, a hardware failure, a memory failure, a disk failure, or a Windows bug or a recent update.

The most frequent causes of these screens are quite well known: Faulty hardware (RAM, CPU, SSD/HDD), old or poorly written drivers, incompatible software, malware, and corrupted system filesPhysical factors such as overheating or power supply problems also come into play, which end up manifesting as hardware errors (for example, WHEA_UNCORRECTABLE_ERROR or MACHINE_CHECK_EXCEPTION).

In recent times, there have even been screenshots caused by faulty Windows 11 patchesFor example, certain recent cumulative updates have generated BSODs with codes such as KERNEL_SECURITY_CHECK_FAILURE when using the GPU intensively, or have broken Wi-Fi connectivity on some computers until Microsoft released another corrective update.

What is a STOP code and what information does it contain?

The STOP code is the numerical identifier of the critical error that has forced Windows to stop. It is usually seen in hexadecimal format (for example, 0x00000050 or 0x00000124) and is associated with a symbolic name, such as PAGE_FAULT_IN_NONPAGED_AREA or WHEA_UNCORRECTABLE_ERROR.

That symbolic name is the one Microsoft uses in its documentation. For example, DRIVER_POWER_STATE_FAILURE corresponds to code 0x0000009FIf you open a dump file with the WinDbg debugger and run the command !analyze -v, you'll see something like this:

BugCheck 9F, {3, ffffe000f38c06a0, fffff803c596cad0, ffffe000f46a1010}

The line above shows the error checking code (9F) and four additional parameters in curly braces. Each STOP code has up to four parameters that provide very specific context about what happened (for example, memory addresses involved, type of operation, device identifiers, etc.). Microsoft's official bugcheck code reference details what each parameter means for each bugcheck.

The symbolic name (for example, DRIVER_POWER_STATE_FAILURE) and the hexadecimal value (0x9F) appear together in the debugger output and in the documentation. When you're looking for advanced technical information, you'll want to use both: the name and the code.In contrast, more generic guides tend to focus on the name in text because it is more readable.

How are the parameters of an error-checking code collected?

If you want to go beyond "I got a blue screen" and understand what went wrong, you need obtain the STOP code and its parametersThere are several ways to achieve this, depending on whether you have memory dumps, can attach a debugger, or only have the event log.

The most accessible way for most users is through the Event Viewer. In the system log, Error checking events include the STOP code and the four associated parametersIt's not always pretty or easy to read, but the information is there, unless the dump creation failed or the system crashed so badly that it couldn't even be recorded correctly.

Another more technical way is to load the generated dump file (the minidump or the full dump) into WinDbg or the Windows debugger and use The !analyze command, ideally with the -v option to see a detailed analysisThere you will see the BugCheck with its parameters, the module that probably caused the problem (for example, hidusb.sys) and even the call stack at the time of the failure.

If you have a kernel debugger connected to the computer when the error occurs, Error checking will cause the system to stop directly in the debuggerIn this scenario, the blue screen may not even appear on the monitor; instead, all the information is sent to the debugger window. You can view the bugcheck data again with the `.bugcheck` command or restart the analysis with `!analyze`.

Why does the dump file creation sometimes fail?

A very common complaint is finding a log entry in the Event Viewer that says “The creation of the dump file failed due to an error during the dump creation process.”This doesn't necessarily mean your system is irreparably broken, but it does indicate that something has prevented Windows from saving that crucial information.

The causes can be many: lack of disk space, errors in the volume where the dump is to be written, file system corruption, memory problems so severe that the operation cannot even be completed, or incorrect dump settingsIt can also interfere with third-party software (aggressive antivirus, low-level encryption, etc.).

In these cases, it's often helpful to review the advanced system settings, in the Startup and Recovery section, to make sure that You have enabled some type of dump (minidump, kernel or full) and the save path is validAdditionally, it's advisable to check that the system drive is not full and that the file system is free of errors (using tools like CHKDSK).

If it still fails, it's not because you're looking at it wrong: Your team simply hasn't managed to "log" the failure in the form of a dump.In these cases, you will need to rely more on the Event Viewer, hardware testing, and context analysis (what you were doing, what has been recently updated, etc.).

Reading debug information with WinDbg

For those who want to get to the bottom of this, the key tool is WinDbg. When you load a kernel dump and run !analyze -v, the debugger shows a detailed description of the error, including the bugcheck, parameters, call stack, and suspect module.

For example, you might see something like the error occurred “Probably caused by: hidusb.sys”, which points to a problem with the USB HID controller (mice, keyboards, etc.). From there you can delve deeper, set breakpoints in the relevant code, proceed step by step, and check exactly where in the controller the violation occurs.

If you have the ability to connect a debugger to the system with persistent problems, kernel debugging is especially useful for recurring or very complex errorsEspecially when other diagnostic techniques have reached their limit. However, it's always advisable to note down the exact text that appears on the blue screen message and the specific actions that lead to the problem so that it can be reproduced in a controlled manner.

Microsoft offers specific documentation on how to analyze memory dumps (both in kernel mode and user mode) and how to make in-depth use of the debugger extensions, in particular Analyze and its optionsFor developers and advanced support staff, this allows them to differentiate whether the fault is actually in their own code or in another component of the system.

Common BSODs in Windows 11 and what they usually mean

There is a set of blue screen errors that occur quite frequently in Windows 10 and Windows 11. Recognizing them at a glance helps prioritize where to start lookingSome of the most common are:

• PAGE_FAULT_IN_NONPAGED_AREA (0x00000050)Windows has attempted to access a memory page that does not exist or is currently inaccessible. This usually indicates faulty RAM or a corrupted NTFS volume.
• IRQL_NOT_LESS_OR_EQUAL (0x0000000A)A kernel-mode controller has attempted to access pageable memory when it shouldn't have (IRQL too high). This is very typical of faulty drivers or malfunctioning hardware.
• SYSTEM_SERVICE_EXCEPTION (0x0000003B)A system service, usually a driver or a critical process, has generated an unhandled exception. This is often related to incompatible drivers or software that interferes too much with the kernel.
• DRIVER_IRQL_NOT_LESS_OR_EQUAL (0x000000D1)A controller has attempted to access an invalid memory address at a high priority level. Again, almost certainly a problematic driver.
• CRITICAL_PROCESS_DIED (0x000000EF)An essential system process has terminated unexpectedly. This may be caused by corrupted system files, malware, or Windows errors.
• MEMORY_MANAGEMENT (0x0000001A)This indicates inconsistencies in memory management. These are usually caused by faulty RAM modules, hardware errors, or deep system corruption.
• SYSTEM_THREAD_EXCEPTION_NOT_HANDLED (0x0000007E): strongly associated with old or incompatible controllers that throw unhandled exceptions.
• INACCESSIBLE_BOOT_DEVICE (0x0000007B)Windows cannot access the boot partition. This may be due to changes in the SATA configuration (RAID/AHCI), missing storage controllers, or corrupted boot files.
• UNMOUNTABLE_BOOT_VOLUME (0x000000ED)The system cannot properly mount the boot drive, often during startup. Again, disk or file system problems.
• DPC_WATCHDOG_VIOLATION (0x00000133): typically linked to drivers that block the system for too long (timeouts exceeded in DPC queues).
• WHEA_UNCORRECTABLE_ERROR (0x00000124) y MACHINE_CHECK_EXCEPTION (0x0000009C): errors closely related to hardware failures (CPU, RAM, motherboard, power supply) or serious temperature or voltage problems.

Each of these errors has its own entry in the Microsoft documentation, with technical explanation, meaning of parameters and specific recommendationsIf your STOP code matches one of these, it's worth checking the official reference to refine the diagnosis.

Less frequent BSOD codes and typical guidelines

In addition to standard bug checks, many manufacturers (Huawei, Dell, and others) collect internal data Lists of less common codes with quick recommendations for their technical support. Although they are designed for their ecosystem, they give an idea of ​​the general direction they usually take:

Errors such as MANUALLY_INITIATED_POWER_BUTTON_HOLD or NMI_HARDWARE_FAILURE These errors only occur if the system is configured to display a blue screen when the power button is held down for a certain period. Even if the trigger is "manual," the fact that it fires could indicate a hardware problem that forces the user to shut down the computer in this way.

Others, like CPFN_REFERENCE_COUNT, FAST_ERESOURCE_PRECONDITION_VIOLATION or INVALID_KERNEL_STACK_ADDRESSThese issues are usually attributed to internal Windows errors that rarely recur. In these cases, the typical advice is to restart, update patches, and, if the problem persists, contact technical support because there may be deep corruption or a bug in the system itself.

There are also many codes almost always associated with third-party applications or driversFor example, QUOTA_UNDERFLOW, PROCESS_HAS_LOCKED_PAGES, BUGCODE_NDIS_DRIVER (network), BUGCODE_USB3_DRIVER (USB 3.0), DRIVER_OVERRAN_STACK_BUFFER, or FSRTL_EXTRA_CREATE_PARAMETER_VIOLATION. In practice, the recommendation is usually to check which programs or drivers have been recently installed, especially PC managers, antivirus software, or "miracle" optimization tools, and uninstall them to see if the problem disappears.

There are codes directly related to the file system, such as FAT_FILE_SYSTEM, UDFS_FILE_SYSTEM, EXFAT_FILE_SYSTEM or FLTMGR_FILE_SYSTEMWhen these errors occur repeatedly, they point to poorly partitioned drives, unorthodox system installations, faulty disks, or filter drivers interfering with disk access. In many cases, manufacturers recommend restoring factory settings or reinstalling Windows if the problem persists after updating and repairing the file system.

Other codes are linked to CPU, memory, or hypervisor failuresFor example, MACHINE_CHECK_EXCEPTION, WHEA_INTERNAL_ERROR, HYPERVISOR_ERROR, or STORE_DATA_STRUCTURE_CORRUPTION. These errors almost always indicate hardware problems or issues with advanced virtualization configurations, and the usual solution is to rely on warranty claims or advanced physical diagnostics.

When the problem stems from Windows 11 updates

Not all BSODs are caused by your hardware or the software you've installed. Sometimes, they are Windows updates themselves introduce regressionsRecent cases have been documented where cumulative patches for Windows 11 have caused KERNEL_SECURITY_CHECK_FAILURE screens on computers with certain graphics cards, as well as Wi-Fi connectivity failures.

In those scenarios, Microsoft usually publicly acknowledges the problem and publish a corrective updateFor example, a faulty cumulative update might be KB5074105, and the update that fixes the bugs might be KB5077181. The latter is distributed through Windows Update and rolled out gradually.

If you start seeing blue screens after installing a specific update and everything was working fine before, it's a good idea to check your Windows Update history and Check if your KB article is associated with any known issues in Microsoft documentation.While you wait for the patch, you could uninstall the conflicting update or temporarily pause automatic updates, although this always involves some security risk.

In any case, in addition to installing the patch that fixes the problem, it's advisable to keep the rest of the system up to date: Updated BIOS/UEFI, chipset, graphics, network, and storage drivers in recent versionsespecially if your equipment manufacturer provides its own tools (SupportAssist, PC Manager, etc.).

Tools and techniques for investigating a BSOD in depth

Beyond the generic advice of "update everything and restart," there are several powerful tools designed precisely for this purpose. Diagnosing the root cause of a blue screeneven when dumps have not been reliably generated.

On one hand, there's the Event Viewer, which we've already mentioned. By navigating to Windows Logs > System, you can filter for critical errors that occurred around the time of the BSOD. Even if the dump fails, the record of the unexpected shutdown and the attempt to create the dump usually remains., with some useful data (error code, module, etc.).

Also very valuable are the minidump files, those small files that Windows creates in C:\Windows\Minidump when it manages to complete at least a partial dump. They contain condensed information about the system's status at the time of failure. and can be opened with WinDbg or other tools to identify the driver or module involved.

If the system starts, another option is to use DriverVerifierA built-in Windows tool that subjects drivers to a kind of real-time "stress test." It validates their behavior with memory, IRQLs, queues, and so on. When it detects incorrect usage, it can force a proactive bug check to clearly identify which driver is misbehaving. However, it does add some overhead, so you have to carefully select which drivers to check to avoid excessively slowing down your computer.

In addition, you can rely on other advanced utilities such as the suite of Sysinternals tools and network monitorsThese help isolate problems that could ultimately lead to a blue screen (extreme memory leaks, unresponsive drivers, frozen services, etc.). Together with the event log and dumps, they allow you to build a fairly complete picture of what's happening.

Specific advice for developers and third-party software

If you develop drivers or software that interferes with the kernel, sooner or later you'll encounter a BSOD caused by your own code. In that case, simply "reinstalling Windows" won't work. It's time to debug and correct the problemTo do this, the most effective method is to use kernel debugging with WinDbg, reproduce the error in a controlled environment, analyze the bug check, and study the call stack and IRQLs at the time of the crash.

When the bugcheck is not due to your code, but your application is affected, the objective changes: You won't be able to fix the root cause, but you can try to prevent your software from triggering it.This often involves implementing additional checks, better handling errors from other components, reducing aggressive dependencies on third-party drivers, or avoiding risky practices that rely too heavily on undocumented behavior.

In any case, it is essential to take accurate notes. the exact actions that lead to the screenshot, the codes that appear, and the frequency with which it is reproducedWith that information, it's much easier for support teams or Microsoft to assess whether it's a known bug, faulty hardware, or a strange interaction between components.

Finally, we must not underestimate the tried-and-true "basic solutions": Review manuals, reinstall key components, check file dates, uninstall intrusive antivirus or PC managers, and verify network, USB, or storage driversA large proportion of BSODs linked to third-party software end up being resolved by removing the problematic component.

In short, interpreting BSOD codes in Windows 11 is not just a matter of seeing a number on the blue screen: it's about combining that code and its parameters with clues from the Event Viewer, memory dumps, hardware status, and recent system changes. When all that context comes together—and you understand what each bugcheck means—it stops being a "mysterious" screenshot and becomes a very concrete tool to find out what's failing, whether it's the fault of a driver, the hardware, an update, or even your own code.and decide if it's enough to update, uninstall something, repair Windows, or if it's time to think about physical diagnosis and specialized technical service.