Windows bug check parameter reference
Parameter 1 to 4 of five common Windows stop codes in one table each, row by row, with the meaning checked against Microsoft Learn.
Short answer: a bug check passes up to four values, shown as Arg1 to Arg4 in !analyze -v. Their meaning depends on the stop code, and for 0x133 and 0x9F on the value of Parameter 1. Each row below has its own anchor (for example #0x133-parameter-1-0), so you can link to one.
Every row is taken from the Microsoft Learn page named above its table, read on 2026-11-06. Microsoft revises these pages and documents differences by Windows version and architecture, so treat the Learn page as the authority for your build. Codes covered: 0x133 · 0xD1 · 0x50 · 0x3B · 0x9F. New to WinDbg? Start with how to analyze a Windows minidump.
0x133 DPC_WATCHDOG_VIOLATION
Parameter 1 says which kind of timeout it was; parameters 2 to 4 depend on it. Source: Microsoft Learn, Bug Check 0x133. Guide: 0x133 DPC_WATCHDOG_VIOLATION.
| Parameter | Meaning | Parameters 2 / 3 / 4 |
|---|---|---|
| Parameter 1 = 0 | A single DPC or ISR exceeded its time allotment. The offending component can usually be identified with a stack trace. | Parameter 2: the DPC time count (in ticks). Parameter 3: the DPC time allotment (in ticks). Parameter 4: cast to nt!DPC_WATCHDOG_GLOBAL_TRIAGE_BLOCK. |
| Parameter 1 = 1 | The system cumulatively spent an extended period of time at IRQL DISPATCH_LEVEL or above. The offending component can usually be identified with a stack trace, but the code may not stop in the offending area. | Parameter 2: the watchdog period. Parameter 3: cast to nt!DPC_WATCHDOG_GLOBAL_TRIAGE_BLOCK. Parameter 4: reserved. |
0xD1 DRIVER_IRQL_NOT_LESS_OR_EQUAL
A kernel-mode driver touched pageable or invalid memory while the IRQL was too high. Source: Microsoft Learn, Bug Check 0xD1. Guide: 0xD1 DRIVER_IRQL_NOT_LESS_OR_EQUAL.
| Parameter | Meaning |
|---|---|
| Parameter 1 | Memory referenced. |
| Parameter 2 | IRQL at time of reference. |
| Parameter 3 | Type of access: 0 = read, 1 = write, 2 = execute, 8 = execute. |
| Parameter 4 | Address that referenced memory. Run ln on it to see the function. |
0x50 PAGE_FAULT_IN_NONPAGED_AREA
Invalid system memory was referenced; the address is usually wrong or points at freed memory. Source: Microsoft Learn, Bug Check 0x50. Guide: 0x50 PAGE_FAULT_IN_NONPAGED_AREA.
| Parameter | Meaning |
|---|---|
| Parameter 1 | Memory address referenced. |
| Parameter 2 | Type of access. x64 and x86 after Windows 1507: 0 = read, 2 = write, 10 = execute. Arm after 1507: 0 = read, 1 = write, 8 = execute. Before 1507 (x64 and x86): 0 = read, 1 = write. |
| Parameter 3 | Address that referenced the memory, if known. |
| Parameter 4 | Type of page fault: 0x0 = the address is on a page table entry marked free; 0x2 = no valid active page table entry; 0x3 = session space address used in a process with no session (last used in Windows 10 RS3, reported as 0x2 from RS4); 0x4 = non-canonical virtual address; 0xF = kernel-mode code accessed a user-mode address where that is not allowed. |
0x3B SYSTEM_SERVICE_EXCEPTION
An exception happened in a routine that moves from non-privileged to privileged code. Source: Microsoft Learn, Bug Check 0x3B. Guide: 0x3B SYSTEM_SERVICE_EXCEPTION.
| Parameter | Meaning |
|---|---|
| Parameter 1 | The exception that caused the bug check (an NTSTATUS value, for example 0xC0000005 STATUS_ACCESS_VIOLATION or 0x80000003 STATUS_BREAKPOINT). |
| Parameter 2 | The address of the instruction that caused the bug check. |
| Parameter 3 | The address of the context record for the exception. Use .cxr on it, then kb. |
| Parameter 4 | 0 (not used). |
0x9F DRIVER_POWER_STATE_FAILURE
A driver is in an inconsistent or invalid power state. Parameter 1 is the type of violation. Source: Microsoft Learn, Bug Check 0x9F. Guide: 0x9F DRIVER_POWER_STATE_FAILURE.
| Parameter | Meaning | Parameters 2 / 3 / 4 |
|---|---|---|
| Parameter 1 = 0x1 | The device object that is being freed still has an outstanding power request that it has not completed. | Parameter 2: the device object. Parameters 3 and 4: reserved. |
| Parameter 1 = 0x2 | The device object completed the IRP for the system power state request, but did not call PoStartNextPowerIrp. | Parameter 2: the target device's device object, if available. Parameter 3: the device object. Parameter 4: the driver object, if available. |
| Parameter 1 = 0x3 | A device object has been blocking an IRP for too long. | Parameter 2: the physical device object (PDO) of the stack. Parameter 3: nt!_TRIAGE_9F_POWER. Parameter 4: the blocked IRP. |
| Parameter 1 = 0x4 | The power state transition timed out waiting to synchronize with the PnP subsystem. | Parameter 2: time-out value, in seconds. Parameter 3: the thread holding the PnP lock. Parameter 4: nt!_TRIAGE_9F_PNP. |
| Parameter 1 = 0x5 | The device failed to complete a directed power transition within the required time. | Parameter 2: PDO of the stack. Parameter 3: the POP_FX_DEVICE object. Parameter 4: reserved (0). |
| Parameter 1 = 0x6 | The device did not complete its Directed Power Transition callback successfully. | Parameter 2: the POP_FX_DEVICE object. Parameter 3: 1 = Directed Power Down, 0 = Power Up completion. Parameter 4: reserved (0). |
| Parameter 1 = 0x500 | The device object completed the IRP for the system power state request, but did not call PoStartNextPowerIrp. | Parameter 2: reserved. Parameter 3: the target device's device object, if available. Parameter 4: device object. |
Common questions
- What are the four parameters of a Windows blue screen?
- Every bug check passes up to four values to the debugger. What each one means depends on the stop code, and for some codes (0x133 and 0x9F) on the value of Parameter 1. In WinDbg they show as Arg1 to Arg4 in the !analyze -v output.
- Where do I see the bug check parameters in a dump?
- Open the dump in WinDbg and run !analyze -v. The Arguments section lists Arg1 to Arg4 with a one-line description of each. Then look the stop code up in its reference to see what the values mean for that code.
- Is the parameter table the same on every Windows version?
- Not always. Microsoft documents differences by version and architecture, for example Parameter 2 of 0x50, so check the value against the Windows build in the dump before relying on a row.
Rather not read the dump yourself?
Upload it to DumpTriage. It runs the debugger, reads the output and sends back the faulting module, the stack and a plain-language root cause (how the analysis works). Cases the automated passes can't settle go to an engineer. Free during the pilot.
Create an account