claude-mods/skills/windows-ops/references/bugcheck-codes.md

Windows BugCheck Code Catalog

Load this when decoding Event 41 Properties0, analyzing minidump files, or matching a BSOD stop code to a likely cause. Codes here are the ones that actually appear on workstations; the full list is in Microsoft's documentation but most are kernel-internal or driver-specific corner cases.

Contents

1. How to read Event 41
2. Most common stop codes — by frequency on real workstations
3. Hardware-pointer codes — when the bugcheck points at silicon
4. Driver-pointer codes — when a kernel-mode driver is at fault
5. Storage-pointer codes — bugchecks induced by failing disks
6. Power / sleep codes
7. Code 0x0 (no bugcheck) — the special case
8. Decoding bugcheck parameters
9. Cross-reference: symptom → likely codes

How to read Event 41

Get-WinEvent -FilterHashtable @{LogName='System'; Id=41} -MaxEvents 5 |
    Select-Object TimeCreated,
        @{N='BugCheckCode'; E={ '0x{0:X}' -f $_.Properties[0].Value }},
        @{N='Param1'; E={ '0x{0:X}' -f $_.Properties[1].Value }},
        @{N='Param2'; E={ '0x{0:X}' -f $_.Properties[2].Value }},
        @{N='Param3'; E={ '0x{0:X}' -f $_.Properties[3].Value }},
        @{N='Param4'; E={ '0x{0:X}' -f $_.Properties[4].Value }},
        @{N='SleepInProgress'; E={ $_.Properties[5].Value }},
        @{N='PowerButtonTime'; E={ $_.Properties[6].Value }}

Properties[0] is the BugCheck code (the "stop code" in BSOD blue screen). Properties[1-4] are the four parameters whose meaning depends on the code. Properties[5] flags crashes during sleep transitions. Properties[6] is non-zero if the power button was held (manual force-shutdown vs spontaneous crash).

Critical gotcha: people frequently quote Properties[1] as "the BugCheck code" — it isn't. That's BugcheckParameter1. The actual code is at index 0.

Most common stop codes

Frequency on real workstations, descending:

Hex	Name	Typical cause	Investigation entry point
0x0	(no bugcheck recorded)	Hard power loss / total hang / hardware-level failure	See Code 0x0 below
0xD1	DRIVER_IRQL_NOT_LESS_OR_EQUAL	Driver accessed bad memory at high IRQL	Param4 = driver address; symbol lookup
0x3B	SYSTEM_SERVICE_EXCEPTION	Exception in a kernel service call	Param2 = faulting address
0x7E	SYSTEM_THREAD_EXCEPTION_NOT_HANDLED	Driver thread threw unhandled exception	Param1 = exception code; Param2 = address
0x50	PAGE_FAULT_IN_NONPAGED_AREA	Bad memory OR storage I/O failed for pageable code	Param1 = referenced address; check disk Event 51 same timeframe
0xEF	CRITICAL_PROCESS_DIED	A critical system process (csrss/services/wininit) terminated	Param1 = EPROCESS address (needs dump for process name)
0x124	WHEA_UNCORRECTABLE_ERROR	Hardware-level CPU/cache/PCIe error	Cross-reference WHEA-Logger events same timeframe
0x1E	KMODE_EXCEPTION_NOT_HANDLED	Kernel-mode unhandled exception	Param1 = exception; Param2 = faulting address
0x9F	DRIVER_POWER_STATE_FAILURE	Driver hung during sleep/wake	Param1 = transition type (1=sleep, 2=resume, 3=device, 4=node)
0xA	IRQL_NOT_LESS_OR_EQUAL	Like 0xD1 but caller usually pageable code	Param4 = caller address
0x1A	MEMORY_MANAGEMENT	Memory manager corruption	Param1 = subcode (0x41201 = PFN list corruption, 0x41284 = PTE corruption)
0xC1	SPECIAL_POOL_DETECTED_MEMORY_CORRUPTION	Driver Verifier caught buffer overrun	Param1 = pool address; only fires with Verifier enabled
0x139	KERNEL_SECURITY_CHECK_FAILURE	Stack/pool corruption detected	Param1 = subcode (3 = invalid stack guard, 0xA = corrupt LIST_ENTRY)
0xC2	BAD_POOL_CALLER	Driver freed bad pool / freed twice	Param1 = subcode

Hardware-pointer codes

When you see these, suspect the hardware first. Software/driver fixes are unlikely to help.

Hex	Name	What it means
0x124	WHEA_UNCORRECTABLE_ERROR	CPU machine check, ECC failure, PCIe link fault. Run memtest, check thermals, audit recent hardware changes.
0xF4	CRITICAL_OBJECT_TERMINATION	Critical process exited — often storage-induced when paging fails.
0x9C	MACHINE_CHECK_EXCEPTION	CPU detected uncorrectable hardware fault. Param2 = machine check bank. Almost always CPU/RAM.
0x18B	SECURE_KERNEL_ERROR	VBS/Credential Guard hardware enforcement failure. CPU/TPM.

For 0x124, the WHEA-Logger entries in the same minute give the actual MCA bank and error type. Without those it's hard to localise further than "hardware error."

Driver-pointer codes

Most common on workstations. The fixable category — driver update / rollback usually resolves.

Hex	Name	Typical culprit drivers
0xD1	DRIVER_IRQL_NOT_LESS_OR_EQUAL	Network drivers, antivirus, VPN drivers
0x7E	SYSTEM_THREAD_EXCEPTION_NOT_HANDLED	GPU drivers (nvlddmkm, igdkmd64, amdkmdag), audio drivers
0x9F	DRIVER_POWER_STATE_FAILURE	USB, GPU, network (anything that has power states)
0xC4	DRIVER_VERIFIER_DETECTED_VIOLATION	Whatever driver Verifier was watching
0x101	CLOCK_WATCHDOG_TIMEOUT	Usually CPU/chipset driver, or hardware. Param1 = stalled CPU number.

Identifying the driver: minidump analysis with WinDbg's !analyze -v is the canonical method. Without a dump, look for warnings from the driver's provider name in the System log within the same minute as the crash:

# Provider names commonly associated with these crashes
Get-WinEvent -FilterHashtable @{
    LogName='System'
    ProviderName=@('nvlddmkm','igdkmd64','amdkmdag','e1rexpress','RTKVHD','iaStorAVC','Disk','storahci')
    StartTime=(Get-Date).AddDays(-7)
    Level=@(1,2,3)
}

Storage-pointer codes

These bugchecks are typically caused by storage failures, not the kernel/drivers per se. The actual fix is usually replacing the disk.

Hex	Name	Why storage causes it
0x50	PAGE_FAULT_IN_NONPAGED_AREA	Page file I/O failed → kernel can't read paged-out memory
0x77	KERNEL_STACK_INPAGE_ERROR	Paged-out kernel stack couldn't be read back. Param2 = I/O status.
0x7A	KERNEL_DATA_INPAGE_ERROR	Paged-out kernel data couldn't be read back. Param3 = I/O status code.
0xC4 (subcode 0x91)	Driver Verifier — DPC routine exceeded time limit	Often disk driver waiting on hung disk
0xF4	CRITICAL_OBJECT_TERMINATION	A critical process couldn't read its executable pages (storage failed)
0xEF	CRITICAL_PROCESS_DIED	Variant of above — paging failure kills csrss/services/wininit

For storage-induced bugchecks, the I/O status code at Param3 (for 0x7A) or Param2 (for 0x77) is informative:

I/O Status	Meaning
0xC000009C	STATUS_DEVICE_DATA_ERROR — bad sector
0xC000009D	STATUS_DEVICE_NOT_CONNECTED — drive vanished
0xC000016A	STATUS_DISK_OPERATION_FAILED — generic disk failure
0xC0000185	STATUS_IO_DEVICE_ERROR — I/O device error

Cross-reference with disk Event 51 / 154 (disk provider, hardware error events) in the same timeframe. The two together definitively pin the cause to a specific drive.

Power / sleep codes

Hex	Name	When
0x9F	DRIVER_POWER_STATE_FAILURE	Driver hung during sleep transition. Param1 = phase.
0xA0	INTERNAL_POWER_ERROR	Power manager internal error
0x9E	USER_MODE_HEALTH_MONITOR	Clustering / fault-tolerance code path (rare on workstations)
0xEF (during resume)	CRITICAL_PROCESS_DIED	Critical process didn't survive sleep — often paging-storage related
0x101	CLOCK_WATCHDOG_TIMEOUT	CPU didn't tick — sometimes ACPI/chipset-driver-induced during sleep

For 0x9F with Param1=3 (device sleep): Param4 points to the device object that hung. WinDbg can decode this; without dump access the device class can sometimes be inferred from the System log's last successful device-state events before the crash.

Code 0x0 (no bugcheck)

When Properties[0] is 0x0 and all four parameters are also 0, Windows recorded no bugcheck. The crash record exists only because the kernel saw an unclean shutdown on the next boot. This means one of:

• Hard power loss — PSU dropout, power cable yanked, mains cut. Most common cause on desktops.
• Total hardware lockup — CPU/chipset entered a state where the kernel couldn't even execute the bugcheck path.
• Manual power button hold — user force-shutdown a hung machine.

Discriminator: Properties[6] (PowerButtonTimestamp):

• 0 → no power button input recorded → likely power loss or hardware lockup
• Non-zero → power button was pressed → user-initiated force shutdown of a hung machine

Critically: no minidump will exist for 0x0 crashes. There's no point hunting for MEMORY.DMP — the system was gone before it could write. Investigation has to use circumstantial evidence: System log events in the minutes before the crash, recent hardware changes, thermal logs, etc.

The repeated occurrence of 0x0 crashes on the same machine is a strong signal for:

1. Failing PSU (power transients under load)
2. Failing/loose storage cable (storage drops → kernel hangs → user power-cycles)
3. Thermal shutdown (CPU/GPU hits TjMax)
4. Failing RAM (kernel hang or instant total corruption)

Decoding bugcheck parameters

The four parameters' meaning depends on the BugCheck code. The Microsoft docs list each code's parameter semantics; the common patterns:

Position	Typical content for hardware-related codes	Typical content for driver-related codes
Param1	Subcode / error class / referenced address	Faulting address
Param2	I/O status / IRQL level	Calling function address
Param3	Error-specific	Process/thread context
Param4	Caller address	Driver image base address

Parameter values that look like 0xFFFFxxxxxxxxxxxx (high bits set) are kernel-mode addresses. Decoding them to a driver name requires dump analysis with proper symbols.

Parameter values that look like 0x000000xxxx (low value) are usually subcodes — look these up in the Microsoft documentation for the specific BugCheck.

Cross-reference: symptom → likely codes

User-reported symptom	Most likely BugCheck codes	First investigation step
"Random crashes, no pattern"	0x124, 0x1A, 0x101	Check WHEA events, run memtest
"Crashes during gaming"	0x116, 0x117, 0x7E (nvlddmkm/amdkmdag)	GPU driver, GPU thermals, PSU
"Crashes on sleep/wake"	0x9F, 0xA0, 0xEF	Param1 of 0x9F = transition phase
"Crashes with USB device plugged"	0xD1, 0x9F (Param1=3)	USB driver / device driver
"Crashes during file copy / heavy IO"	0x7A, 0x50, 0xF4, 0xEF	Check storage event 7/154 + storahci 129
"Random reboot, no dump"	0x0	Check storahci 129 in minutes before; check WHEA
"Crashes after BIOS update"	Various	Likely chipset driver mismatch; roll back BIOS or update chipset
"Crashes after Windows Update"	0xD1, 0x7E, 0x3B	Identify recently-updated driver; roll back
"Crashes only at boot"	0x7B, 0xED, 0x74	Boot-critical drivers or storage

When to escalate to WinDbg

The Windows-side analysis the skill performs (BugCheck code + Properties + correlating events) handles ~70% of crashes. For the remaining 30% — driver bugs, complex memory corruption, hardware quirks — WinDbg with proper symbols is essential:

# Verify symbol path
$env:_NT_SYMBOL_PATH = "srv*C:\Symbols*https://msdl.microsoft.com/download/symbols"

# Then open the dump in WinDbg and run:
#   !analyze -v
#   lm   (list modules)
#   .bugcheck   (recap bugcheck)
#   k   (stack trace)

That's a deeper investigation than this skill's scope; windows-ops produces the verdict that says "go look at the dump with WinDbg" for the cases that warrant it.