Analyze stalls and context switches in Timing Captures

A context switch occurs when a CPU core stops running one thread and starts running another thread or goes idle. When the operating system switches threads on a core, it saves the state, or context, of the thread being switched out and restores the context of the thread being switched in. This context includes data such as the current values of all registers and the program counter. Saving and restoring context is expensive, so reducing the overall number of context switches is often key to achieving predictable, consistent frame times.

Context switches happen for several reasons. For example, a thread waits on a synchronization object, or the OS scheduler determines that a thread's quantum has expired and another thread is ready to run on that core.

In PIX Timing Captures, a stall is the unscheduled time between the context switch that removes a thread from a core and the context switch that runs it again. Use this article to find stalled CPU work, inspect the context switches around a stall, and identify the stack or readying thread that explains why the work stopped.

For the Timeline lane visuals, see Timeline layout. This article focuses on the stall-analysis workflow.

Capture the data you need

PIX captures context switch events for Timing Captures. To analyze why a switch happened, keep Context switch callstacks enabled before you start the capture. This option is on by default. If you turn it off, PIX still captures context switches, but Element Details won't have the switch-out and switch-in stacks that usually explain the stall.

For stalls that involve system work or another process, consider enabling these advanced options before you capture:

Callstacks for non-title processes: captures callstacks for processes other than the launched or attached process.
Kernel image information: collects the information PIX needs to show callstacks for kernel binaries.

PIX needs symbols to make stacks useful. If stacks contain unknown frames, see Configure PIX to access PDBs for Timing Captures.

Find stalled CPU events

Start from the CPU event that took longer than expected.

Open the Timeline layout.
Select a PIX CPU event in the Timeline view or Range Details.
In Element Details, compare Duration, Execution, and Stalled.
Expand Stalls to see the stalls that occurred while the event was active, listed in time order. For example, an UpdatePlayerArmor event might show eight separate stalls.
Select a stall duration to open the Thread Stall details.

Use Execution to understand how long the event spent scheduled on a core. Use Stalled to understand how much of the event duration was unscheduled time. If Stalled dominates, optimize the wait that caused the thread to stop running before you optimize CPU instructions inside the event.

Make stalls visible in the Timeline

By default, the Timeline draws context switches as small vertical red lines on Thread and Core lanes, and draws stalled (unscheduled) time on Thread lanes with a cross-hatched pattern. For more about these visuals, see Core lanes and Thread lanes. When you're looking at a capture specifically to find context switches, use lane configuration to make them stand out:

Show Context Switches shows or hides the context switch markers.
Bold Context Switches extends the context switch markers to the full height of the Thread or Core lane.
Shade Unscheduled Thread Time shows or hides the shaded stall regions on Thread lanes.

Every shaded region on a Thread lane is bounded by the context switch that switched the thread out and the context switch that switched it back in. Select the shaded region when you want PIX to show the stall as one item instead of inspecting each context switch separately.

Inspect a stall

When you select a stall, Element Details shows Thread Stall. Selecting a whole stall gives you quick access to the stalled thread's call stack and, if available, the stack of the thread that readied it. Use these fields to determine why the thread stopped and what resumed it:

Thread identifies the stalled thread.
Duration is the stall length.
Switched Out identifies the context switch that started the stall. Expand it to see the wait reason and the stalled thread's call stack, or select the header to inspect the switch-out context switch.
Switched In identifies the context switch that ended the stall. Select the header to inspect the switch-in context switch.
Readied by appears when PIX has ready-thread data for the switch-in. Expand it to see the stack for the thread that readied the stalled thread.
Readied Time shows when the readying event occurred.
Adjust Info shows the scheduler ready adjustment reason and increment when that data is available.

After you select the switch-out context switch, the From stack usually answers why the thread stopped running, such as a synchronization wait or blocking API call. The Readied by stack answers what made the thread runnable again. If Readied by points to another title thread, inspect that thread in the Timeline to understand the dependency. If it points to another process, check whether the stall is caused by external system activity or scheduler competition.

Inspect an individual context switch

Select a context switch marker in the Timeline view or a context switch row in Range Details to show Context Switch in Element Details. The details include:

Time: when the switch occurred.
Core: the CPU core where the switch occurred.
From: the thread or process that was switched out, including priority, wait reason, and call stack when available.
To: the thread or process that was switched in, including priority and call stack when available.
Readied by, Readied Time, and Adjust Info when ready-thread data is available.

For example, a switch-out whose From stack shows the title's AppMain thread calling the Win32 ReadFile API indicates that the file read blocked the thread, and the core went from running AppMain to Idle.

If a thread starts running because of an action on another thread, PIX shows the readying thread in both the Timeline and Element Details. For example, a context switch can show that Core 0 went from Idle to running AppMain, and that AppMain was readied by a thread named Worker. Element Details shows the readying thread's call stack, the ready time, and the readying reason. In the Timeline, PIX draws a correlation arrow from the readying thread to the thread that was switched in. Use the arrow to follow cross-thread wakeups without losing the time relationship in the Timeline.

If a context switch involves a process other than your title, Element Details shows that process's name and ID. For example, Core 0 might switch from running devenv.exe to running a title thread named AP1. In that case, the wait reason indicates whether the switch happened because of the operating system's thread scheduler.

Use Range Details for a time range

Use Range Details when you want a sortable list of context switches in a frame, event range, or visible Timeline range.

Select the time range you want to analyze.
Open Range Details.
Set Item Type to Context Switches.
Use the Selector panel to include only the cores you care about.
Sort the table by Core, Time, From, or To.
Select a row to inspect the switch in Element Details or show it in the Timeline.

For larger ranges, open the Range Summary view, set Data Type to Context Switches, and use the Summary tab to group by dimensions such as To Thread, From Thread, To Call Stack, From Callstack, and Type. The presets Call Stacks by To Thread and Call Stacks by Type are useful starting points when you need to find repeated wait patterns instead of a single stall.

Interpret common patterns

Use the three pieces of evidence together:

The stalled event tells you which gameplay or engine phase was affected.
The switch-out stack tells you why the thread stopped running.
The readying thread tells you what dependency or scheduler action made the thread runnable again.

Common interpretations include:

A switch-out stack in a blocking file API means the event is waiting for I/O. Correlate it with file I/O data if you captured file accesses.
A switch-out stack in a synchronization API means the event is waiting for another thread. Follow Readied by to the thread that released or signaled the wait.
A switch where the From or To process is not your title can indicate CPU competition from another process. Enable Callstacks for non-title processes in a follow-up capture if you need stacks for that process.
A long event with little Stalled time is mostly scheduled CPU execution. Analyze CPU samples or the event's own work instead of treating it as a stall problem.

Feedback

Was this page helpful?

Last updated on 2026-10-05