Desktop app corrupts DWM compositor state in Windows 11, causing system-wide stutter that survives closing the app on certain systems

Desktop app corrupts DWM compositor state in Windows 11, causing system-wide stutter that survives closing the app on certain systems

Summary

After 1–3 hours with the Codex desktop app open, the entire Windows desktop develops persistent mouse/window stutter. not just the Codex window. Closing the app does not fix it.

A reboot is not actually required. Restarting DWM alone fixes it instantly (confirmed on the affected machine, with Codex still running). That localizes the fault: Codex drives the Desktop Window Manager into a bad state that DWM latches and does not release when the app exits. Which internal DWM/dxgkrnl state is responsible is not yet established, see "Candidate mechanisms" below.

An xperf trace captured during the stutter shows the DPC storm is in dxgkrnl.sys (the DirectX Graphics Kernel), with a bimodal DPC duration distribution indicating a pathological slow path being taken ~16% of the time.

Symptoms in this class are often attributed to a memory leak. On this machine the stutter occurred with no memory pressure present, so memory exhaustion does not explain this failure, but see "On memory" below, which scopes that claim carefully. It should not be read as ruling out a memory issue generally.

Related issues

Searched the tracker for prior reports. This does not appear to duplicate any of the following, but they are adjacent and may share a root cause:

• #40409 — [Windows][multi-GPU] OnDeviceModelService wakes an otherwise idle RTX 5090 into P0 with an 18 MiB context. Closest existing report on anomalous GPU power state under Codex on Windows. Distinct mechanism: there, a utility process holds a GPU context and blocks idle P8 on a zero-utilization card. Here, the renderer's continuous present stream drives clock oscillation on an actively used card, and the primary symptom is compositor state corruption. Verified on this machine that no OnDeviceModelService process exists (only network.mojom.NetworkService and storage.mojom.StorageService utility processes), so that mechanism is not a confound for these measurements.
• #39846 — Codex Desktop continuously flickers on Ryzen 7 9700X integrated Radeon graphics (Windows 11 build 26200). Also a Windows presentation/compositor defect, different GPU vendor and different visible symptom. Possibly the same underlying continuous-repaint behavior surfacing differently.
• #39816 — Desktop app (macOS): idle node_repl visualization kernels accumulate (60–70 concurrent, ~600 MB), causing severe input lag. Different platform and different cause, but note that idle node_repl processes were also observed accumulating under codex.exe on this machine.
• #39670 — Memory leak - Codex Windows using all of ram. Symptomatically adjacent and on Windows. Unclear whether it describes this same failure; see "On memory" below for why memory-framed reports may or may not be related.

If maintainers judge this a duplicate of any of the above, the DPC trace evidence here may still be useful attached to that issue instead.

Environment

| | |
|---|---|
| App | OpenAI Codex 26.818.5229.0 (ChatGPT.exe) |
| Electron/Chromium | 151.0.7922.170 |
| OS | Windows 11 Pro 26200 |
| Machine | Razer Blade 15 (2022), RZ09-0421 |
| CPU | Intel i7-12800H (6 P-cores + 8 E-cores) |
| GPU | NVIDIA RTX 3080 Ti Laptop, driver 610.88 |
| RAM | 32 GB |
| Display | 2560×1440, 119 Hz, VRR range 50–143 Hz |
| Graphics mode | Discrete-only — Intel iGPU inactive, all desktop compositing on the dGPU |
| MPO | Enabled (Windows default; OverlayTestMode unset) |
| HAGS | On (HwSchMode = 2) |

Symptom

• Mouse cursor hitches, window dragging is jerky, desktop animations skip frames.
• Affects the whole desktop, every application — not only Codex.
• Develops after 1–3 hours of Codex running.
• Persists after Codex is closed.
• Cleared only by reboot — or, as established here, by restarting DWM.

Expected behavior

An idle Codex window should not present continuously at display refresh rate. With no active generation, no streaming output, and no visible animation required, the renderer should quiesce and stop submitting frames, as Chromium's occlusion and idle throttling normally ensure.

Closing the application should return the system to its pre-launch state. No application should be able to leave the Desktop Window Manager in a degraded state that outlives the process.

Actual behavior

The renderer presents continuously at 119 Hz for the entire session, measured at 6.3–20.5 MB/s of rasterized bitmap pushed renderer→GPU over IPC, sustained across 7+ hours, with the app idle.

After 1–3 hours this leaves DWM in a degraded state that produces desktop-wide mouse and window stutter affecting every application. Closing Codex does not clear it. The state persists until DWM is restarted (or the machine is rebooted, which restarts DWM incidentally).

Proposed mechanism

Codex's Electron renderer maintains a continuous repaint loop at full display refresh rate that never quiesces, sustained for the entire session (measured: 6.3–20.5 MB/s of rasterized bitmap pushed renderer→GPU over IPC, continuously, for 7+ hours).

This drives the Desktop Window Manager into a bad state that DWM latches and does not release when the presenting application exits. This much is directly established: restarting DWM alone clears the stutter, with Codex still running.

Because this machine composites the entire desktop through the same path, every window in the session inherits the stutter.

Candidate mechanisms inside DWM — NOT yet confirmed

The trace establishes that the DPC storm is in dxgkrnl.sys and that its duration distribution is bimodal, two code paths, the slow one taken ~16% of the time. It does not establish which path. Plausible candidates, in no particular order:

• MPO (Multi-Plane Overlay) plane management. MPO is enabled (Windows default) and the panel is VRR (50–143 Hz). A window presenting continuously at an irregular cadence is a known trigger for overlay-plane stutter. No overlay-plane telemetry was captured, so this remains speculative.
• HAGS (Hardware-Accelerated GPU Scheduling). Enabled (HwSchMode = 2). Also lives in dxgkrnl and also holds state across client lifetime.
• VidMm / VidSch or the general present path, independent of overlays.

Distinguishing these requires either overlay-plane telemetry or A/B testing the settings individually. See "Open questions" below.

Evidence

xperf -a dpcisr, 50.1 s trace captured during active stutter

DPC time by module, summed across all 20 logical CPUs:

dxgkrnl.sys     4,154 ms    8.29% of one core     <- DirectX Graphics Kernel
Wdf01000.sys    1,615 ms    3.22%
nvlddmkm.sys    1,571 ms    3.14%                 <- NVIDIA display driver
ntoskrnl.exe    1,131 ms    2.26%
ACPI.sys          247 ms    0.49%
storport.sys      159 ms    0.32%
tcpip.sys          78 ms    0.16%                 <- networking not involved

Graphics stack (dxgkrnl + nvlddmkm) = 5,725 ms of DPC in a 50 s trace.

The distribution is bimodal — this is the key finding

dxgkrnl.sys, 36,925 DPCs over the trace:

  8-16 us     4,755   12.88%
 16-32 us     9,753   26.41%   <- normal peak
 32-64 us     9,018   24.42%
 64-128 us    2,561    6.94%   <- trough
128-256 us    5,790   15.68%   <- SECOND PEAK
256-512 us      361    0.98%
512-1024 us      52    0.14%
1024-2048 us      2    0.01%

A healthy DPC distribution decays monotonically. The trough at 64–128 µs followed by a distinct second peak at 128–256 µs means two separate code paths, with the slow one taken ~16% of the time, roughly 124 times per second. 6,204 DPCs exceeded 128 µs; 415 exceeded 256 µs.

At 119 Hz the frame budget is 8.4 ms, so these do not individually miss frames, but sustained at this rate they starve the compositor enough to produce continuous visible stutter.

Before / after DWM restart

                        during stutter    after DWM restart
% DPC Time (total)         8-12%              0.68%

A ~15× reduction from restarting the compositor alone, with the Codex app still running and unchanged.

What this is NOT

Ruled out by direct measurement while the system was actively stuttering:

• Disk. 98.7% idle, 0.19 ms read latency, queue depth 0.
• CPU saturation. Processor Queue Length = 0 across every sample. Nothing waiting on CPU.
• CPU throttling. P-cores at 100% performance limit. (E-cores show 75% / TURBO_LIMIT, which is normal hybrid-architecture behavior, and misleads the aggregate "% Processor Performance" counter into reading ~63%.)
• Networking / USB NIC drivers. tcpip.sys at 0.16% of DPC time.
• Thermal or power throttling. SW Thermal Slowdown and SW Power Capping counters both flat (0 µs delta over 20 s sampling); GPU drawing 29–33 W of an 80 W limit.

On memory

Stated carefully, because this class of symptom is frequently attributed to a memory leak and the evidence here is narrower than it might appear.

What was measured, at several points while the desktop was actively stuttering:

Physical total     32,451 MB
Available          11,800 MB
Commit charge      29,523 MB / 81,603 MB   (36.2%)
Pagefile in use        124 MB / 49,152 MB
Hard page faults           0 /sec
Orphaned GPU allocations   0 MB (dead PIDs)

What that supports: there was no memory or commit pressure at the time the stutter was occurring, and no paging. Memory exhaustion therefore does not explain the stutter documented in this report. Restarting DWM, which frees essentially nothing, resolved it, which is independently consistent.

What that does not support, and was not tested:

• Whether Codex's memory grows unboundedly over a longer session. The renderer process was observed holding 720–930 MB with large swings, but was not tracked across a full multi-hour run, so no trend can be claimed either way.
• Whether reports on other machines and configurations describe a genuine and separate memory problem. Nothing here speaks to that.
• Windows' Memory Compression process held 2,114 MB during observation. This was noted but not investigated, and is unexplained.

In short: memory is not the mechanism of this stutter. That is a narrower claim than "there is no memory issue," and the latter is not asserted.

Secondary finding (real, but not the cause of the stutter)

While the app runs, the GPU memory clock oscillates between its 810 MHz idle state and 5–7 GHz performance states ~12 times per minute (720/hour), indefinitely, driven by the same continuous low-intensity repaint stream, which is the worst case for GPU clock governors.

Measured effect, with an inverse correlation confirming memory-bandwidth stalling:

at idle mclk (810 MHz),  75% of samples: avg sm utilization 37.0%
at boosted mclk,         25% of samples: avg sm utilization 19.3%

Pinning a memory clock floor (nvidia-smi -lmc 5001,7001) eliminates the oscillation entirely (12/min → 0/min) and dropped Codex's own CPU consumption substantially. It does not fix the stutter, that requires the DWM restart, but it is a genuine second-order pathology from the same root cause and worth fixing alongside.

Reproduction

1. Windows 11, NVIDIA discrete GPU, high-refresh VRR display, MPO enabled (default).
2. Leave the Codex desktop app open for 1–3 hours.
3. Observe progressive desktop-wide mouse/window stutter.
4. Close Codex — stutter persists.
5. Restart DWM (Stop-Process -Name dwm -Force, admin) — stutter clears immediately.

Confirm the mechanism with:

xperf -on latency -stackwalk profile -buffersize 1024 -MaxFile 512 -FileMode Circular
   (reproduce stutter ~60s)
xperf -d stutter.etl
xperf -i stutter.etl -o dpcisr.txt -a dpcisr

Suggested fix (app side)

The app should not present continuously when idle. Likely sources:

• A CSS animation or requestAnimationFrame loop left mounted after the work it indicates completes (streaming/"thinking"/progress indicators are the usual culprit).
• A canvas or virtualized list redrawing every frame rather than on change.
• Repaint continuing while the window is occluded or backgrounded, Chromium's occlusion throttling does not appear to be taking effect.

Concretely: an idle window should not push ~170 KB/frame of bitmap across IPC at 119 Hz. Capping animation rate, unmounting inactive indicators, or honoring occlusion state would each break the loop that corrupts the compositor state.

Open questions

These are unresolved and would sharpen the diagnosis:

1. Which dxgkrnl path is the slow one? Requires overlay-plane / present-path telemetry, or symbolized DPC stacks (the trace here used -stackwalk profile, which samples CPU, not DPC).
2. Does disabling MPO prevent the state from forming? Testable directly — see below. Result pending.
3. Does disabling HAGS prevent it? Not yet tested.
4. Does it reproduce without VRR, or at 60 Hz? Not yet tested. Would indicate whether the irregular present cadence matters.
5. Does it reproduce on hybrid-graphics machines (desktop composited on an iGPU)? This machine is discrete-only, which may be why it is so visible here. Could explain inconsistent reproduction across users.

Workarounds for affected users

Confirmed to fix the stutter:

1. Restart DWM instead of rebooting — Stop-Process -Name dwm -Force from an admin prompt. Applications survive; the screen blanks for about a second. Verified to clear the stutter immediately, with Codex still running and unchanged.

Validation pending:

1. Disabling MPO may prevent the bad state from forming, if MPO is the mechanism (see "Candidate mechanisms" — this is speculative):

reg add "HKLM\SOFTWARE\Microsoft\Windows\Dwm" /v OverlayTestMode /t REG_DWORD /d 5 /f
(admin; restart DWM or reboot to apply; fully reversible by deleting the value). Needs a multi-hour Codex session with MPO disabled to see whether the stutter recurs.

Confirmed NOT to fix the stutter:

1. Pinning a GPU memory clock floor. Tested directly: nvidia-smi -lmc 5001,7001 eliminates the clock oscillation completely (12 transitions/min → 0/min) and substantially reduces Codex's own CPU consumption, but the desktop stutter is unaffected. Listed here because the oscillation is a real second-order pathology worth fixing on its own, and because ruling this out is what localized the fault to the compositor. (Admin; not persistent across reboot; revert with nvidia-smi -rmc.)