Windows Stop Code PANIC_STACK_SWITCH (0x0000002B): Meaning, Parameters, and Troubleshooting

Quick Answer

PANIC_STACK_SWITCH is Windows bug check 0x0000002B. Microsoft says it indicates that the kernel-mode stack was overrun. This normally happens when a kernel-mode driver uses too much stack space; serious kernel data corruption is another possible cause. Microsoft Learn

Arg1 is the trap-frame address; Arg2–Arg4 are reserved. In an actual dump, start with !analyze -v, then inspect the trap frame and stack. The code does not, by itself, tell you which driver consumed the stack or whether corruption occurred earlier. Microsoft Learn

What Is the Kernel Stack?

Each executing kernel thread has stack space for call frames, return information, and local data used by nested routines. The space is limited. Microsoft advises driver developers to avoid deeply nested calls, excessive recursion, and large amounts of data placed on the kernel stack. The available size can vary with hardware platform and Windows version. Microsoft Learn

If code exceeds the usable stack space, Windows cannot safely continue. With 0x2B, Microsoft describes the detected condition as a kernel-mode stack overrun. A deeply nested driver path is a plausible mechanism, but corruption can also produce the failure. Microsoft Learn

PANIC_STACK_SWITCH Parameters

A trap frame preserves processor context associated with a trap. WinDbg’s .trap command can display important registers from a specified trap frame and use it as the debugger’s register context. Depending on the dump, that context may help reconstruct the thread’s execution path. Microsoft Learn

Documented Causes

A driver uses too much kernel stack

Microsoft says this is the normal explanation for the bug check. Patterns worth investigating include:

• Deeply nested driver calls.
• Recursion with too many levels.
• Large local arrays or structures on the stack.
• A call path that grows unexpectedly because of repeated callbacks.

These are development patterns to check against the actual stack. Microsoft’s kernel-stack guidance specifically warns against deep nesting, excessive recursion, and passing large amounts of data on the stack. Microsoft Learn

Serious corruption in the kernel

Microsoft also says 0x2B can occur when serious data corruption takes place in the kernel. In that situation, the stack may itself be damaged or may not reveal the original corrupting operation. Do not conclude that a long stack is the cause without checking the dump’s broader evidence. Microsoft Learn

How to Investigate a 0x2B Crash in WinDbg

1. Preserve the dump and verify the code

Confirm 0x0000002B in the original crash dump. Keep the complete bug-check arguments and record the Windows build. A screenshot of the name does not show the trap frame or stack context.

2. Run the initial analysis

Open the dump in WinDbg:

!analyze -v

Record the suggested module, exception or trap information, and stack trace. Microsoft recommends !analyze to help determine the cause of bug check 0x2B. Treat an automatically identified module as a lead, then verify its role in the call path. Microsoft Learn

3. Examine the trap frame from Arg1

If the dump contains the trap frame, use the Arg1 address:

.trap <Arg1 address>

Replace <Arg1 address> with the actual value from your dump. The .trap command displays saved register state and changes the debugger’s register context. If the trap frame is unavailable in a limited dump, the command may not provide useful detail. Microsoft Learn

4. Display the stack

After selecting the relevant context, run:

kv

Look for recursion, repeated routines, unusually deep call chains, and the driver modules involved. Consider whether the stack is trustworthy: severe corruption can make it incomplete or misleading.

5. Compare repeated crashes

If several dumps exist, compare their stacks and failing drivers. A stable, repeatedly deep path points to a different investigation from crashes with unrelated and visibly corrupted stacks.

6. Correlate with system changes

Note any driver or device changes preceding the first crash and inspect Event Viewer → Windows Logs → System for related failures. Use this context alongside the dump, rather than assuming the most recent update caused the overrun.

Guidance for Driver Developers

When a driver you maintain appears in the relevant call path:

1. Measure or inspect stack use along the deepest path.
2. Bound recursive calls and review accidental re-entry.
3. Replace large stack-resident temporary data with an appropriate allocation strategy.
4. Keep call trees as flat as practical.
5. Consider the kernel stack’s available space on the supported platforms and Windows versions.

Microsoft documents IoGetStackLimits and IoGetRemainingStackSize for examining stack bounds or remaining space, and KeExpandKernelStackAndCallout for cases that need an expanded stack. These are design tools to use appropriately; the first task remains identifying the actual failing path. Microsoft Learn

If the stack looks corrupted rather than simply deep, investigate the earlier write or lifetime error that could have damaged it. Reducing local-variable size will not fix an unrelated corruption bug.

Guidance for End Users

There is no Windows setting that directly “increases the kernel stack” as a general end-user fix. If the blue screen repeats:

• Preserve the crash dumps.
• Record what operation or device use precedes the crash.
• Note recent driver changes.
• Have the dump analysed to identify a relevant driver path.
• Obtain a supported update or rollback from the implicated vendor when the evidence supports it.

Do not replace RAM or reinstall Windows solely because the stop-code name contains “PANIC.” Microsoft identifies driver stack use and possible kernel corruption, not one universal hardware or software remedy. Microsoft Learn

Frequently Asked Questions

What does PANIC_STACK_SWITCH mean?

Windows detected a kernel-mode stack overrun and reported bug check 0x0000002B. Microsoft Learn

Is a driver always responsible?

Microsoft says excessive stack use by a kernel-mode driver is the normal cause, but it also identifies serious kernel data corruption as a possibility. Investigate the dump before assigning fault. Microsoft Learn

What does Arg1 contain?

It is the trap frame. A debugger can inspect it with .trap when the frame is available in the dump. Microsoft Learn

What do Arg2, Arg3, and Arg4 mean?

Microsoft marks them reserved for 0x2B. Do not interpret them using another bug check’s parameter table. Microsoft Learn

Can recursion trigger this kind of failure?

Excessive recursion can consume kernel stack space. Microsoft explicitly advises drivers to limit recursive calls to avoid running out of stack. Confirm the actual call pattern in the dump. Microsoft Learn

Is the user-mode application stack involved?

This bug check concerns the kernel-mode stack. A user application may trigger a driver operation, but its own user-mode stack is not what the code identifies. Microsoft Learn

Summary

PANIC_STACK_SWITCH (0x0000002B) reports a kernel-mode stack overrun. Excessive stack use in a driver is the usual documented cause; serious kernel corruption is another possibility. Use Arg1’s trap frame, the dump’s stack, and repeated-crash patterns to determine which explanation fits before choosing a fix. Microsoft Learn

Sources

• Microsoft Learn: Bug Check 0x2B — PANIC_STACK_SWITCH
• Microsoft Learn: Using the Kernel Stack
• Microsoft Learn: .trap WinDbg command