Desktop-wide lag after long-running TUI sessions persists after Terminal restart; DWM restart required

[Polymistis]

Windows Terminal version

1.24.11911.0

Windows build number

No response

Other Software

Codex CLI 0.144.5
Claude Code 2.1.214
NVIDIA GeForce RTX 5090, driver 596.49 / 32.0.15.9649
Intel UHD Graphics 770, driver 32.0.101.7082
3840x2160 display at 120 Hz

Steps to reproduce

1. Open Windows Terminal on a 3840x2160 120 Hz display.
2. Run prolonged Codex CLI or Claude Code TUI sessions that produce frequent spinner, status, title, and streamed-text redraws.
3. After prolonged activity, drag windows around the desktop, switch applications, and select windows.
4. Stop active TUI workloads, close the previous Terminal windows, and open one fresh Terminal window.
5. Observe that desktop responsiveness remains degraded.
6. Restart Desktop Window Manager and repeat the desktop interactions.

Exact time-to-trigger is not yet deterministic. The behavior has recurred after prolonged heavy terminal use. Default Terminal rendering and appearance settings were active during reproduction: no acrylic, transparency, background image, or custom shader.

Expected Behavior

Frequent Terminal presentation should not leave persistent desktop-compositor degradation. Desktop responsiveness should remain normal, or recover after the active workloads and previous Terminal surfaces end, without restarting Desktop Window Manager.

Actual Behavior

Window dragging, application switching, and desktop selection become severely choppy. Fullscreen 3D applications remain responsive.

Stopping active TUI workloads and reopening Terminal with only one fresh window does not restore desktop responsiveness. Restarting dwm.exe restores responsiveness immediately while the fresh Windows Terminal and Codex processes remain active.

Related issue #18422 reports similar desktop-wide lag, but closing all Terminal processes restores performance in that case. The recovery behavior differs here: restarting Terminal does not recover the degraded compositor state; restarting DWM does.

Resource checks

• RAM availability remained above 50 GB.
• Page-in activity, pagefile pressure, and disk utilization remained near zero.
• DWM handle counts were comparable before and after restart, so current evidence does not support a raw handle leak.
• DWM CPU was approximately 104.6% on a one-logical-core scale before restart and 7.7% immediately after restart under comparable observation.
• DWM working set fell from approximately 304.5 MB to 208 MB immediately after restart.

ETW evidence

A 41.7-second WPR CPU plus DesktopComposition trace captured the degraded state with zero lost events. DWM accumulated approximately 48,268 sampled CPU milliseconds, averaging more than one logical core.

Top DWM CPU frames from PerfView with Microsoft symbols:

Function	Exclusive	Inclusive
dwmcore!CComposition::CleanTrees	18.93%	31.95%
dwmcore!CTreeData::GetOcclusionInfo	9.51%	9.67%
dwmcore!CVisualTreeIterator::WalkSubtree<COcclusionContext>	1.89%	11.32%
udwm!CWindowList::ForceUpdateScene	0.30%	8.18%
dwmcore!CComposition::PreRender	0.12%	23.52%

The hot path is concentrated in DWM visual-tree cleanup, scene traversal, and occlusion calculation rather than paging, storage, or GPU-driver execution.

A second DesktopComposition trace used process suspension to isolate the same fresh Terminal process while the degraded DWM state remained:

Phase	Terminal dirty-generated frames	Terminal compositor-rendered frames
Running	50.56%	43.07%
Suspended	2.04%	1.70%
Resumed	48.03%	40.79%

The suspension test identifies Windows Terminal as a major redraw source during the degraded state. The test does not establish ownership of the accumulated DWM state.

Source-backed mitigation under test

Windows Terminal 1.24.11911.0 normally uses DXGI_SWAP_EFFECT_FLIP_SEQUENTIAL and Present1 dirty rectangles. The supported global setting below switches AtlasEngine to DXGI_SWAP_EFFECT_FLIP_DISCARD and disables dirty-rectangle presentation:

{
  "rendering.disablePartialInvalidation": true
}

Source: https://github.com/microsoft/terminal/blob/v1.24.11911.0/src/renderer/atlas/AtlasEngine.r.cpp#L333-L355

The setting is enabled for a long-session recurrence test. Codex TUI animations and terminal-title updates are also disabled to reduce continuous redraw pressure. Results remain pending.

Questions

1. Can repeated small Present1 dirty rectangles on a high-refresh 4K display leave pathological dirty-tree or occlusion state in DWM on Windows build 26200?
2. Is rendering.disablePartialInvalidation the expected workaround for this compositor behavior?
3. Would another WPR profile or private event provider help distinguish Terminal swap-chain behavior from a Windows DWM or display-driver defect?

The raw ETL files are approximately 0.9 GB and 0.6 GB and may contain machine activity metadata, so no public attachment is planned. A symbolized PerfView CSV and sanitized attribution output can be provided publicly; raw traces can be shared through a Microsoft-approved private channel.

[JC-S]

I'm running into the exact same issue. It's also triggered by Codex CLI and Claude Code.

[Polymistis]

Fortunately you can get performance back anytime this happens by just killing the Desktop Window Manager (DWM) process which auto restarts in Windows. Fixes performance completely for me.

[JC-S]

Fortunately you can get performance back anytime this happens by just killing the Desktop Window Manager (DWM) process which auto restarts in Windows. Fixes performance completely for me.

Thanks for the heads-up, but unfortunately this workaround doesn't really work for me. If I do this on my device, it causes issues with some other apps I use regularly. Hopefully this can be properly fixed soon.

[Bbk1AtJJF8]

Have you checked whether the DWM high CPU usage correlates with specific operations in the TUI, like certain redraw events or heavy output from Codex CLI?

[Polymistis]

It doesn't, the problem is the DWM gets entirely stuck like this for whatever reason. I can close all terminal windows and everything and it still runs poorly, that's why I noted that closing and restarting terminal has no effect which would mean that no operations in the TUI would have any impact. It's something that's getting stuck or leaking, not sure exactly how. So far the only remediation is restarting the DWM process

[lhecker]

This is an excellent bug report, the only thing that's missing is the Windows version number. That would be highly relevant to investigate whether there's a known DWM bug.

Some notes:

• I have an RTX 5090 as well and could not observe such an issue so far.
• Your Nvidia driver is outdated - please update it. The latest version is 610.74.
• "Intel UHD Graphics 770" -- the Intel driver has had DWM leaks numerous times in the past. I would suggest disabling the integrated GPU in BIOS if you don't need it.

Can repeated small Present1 dirty rectangles on a high-refresh 4K display leave pathological dirty-tree or occlusion state in DWM on Windows build 26200?

I'm not aware of such an issue. Of course it would be possible.

Is rendering.disablePartialInvalidation the expected workaround for this compositor behavior?

Because Present1 is difficult to implement and because it had bugs in the past, this setting serves as an escape hatch. And if you aren't using a laptop nor remote desktop, setting this to true is actually advantageous. It allows your GPU to use so called independent flips, which are faster. For instance, I always have it set to true.

Would another WPR profile or private event provider help distinguish Terminal swap-chain behavior from a Windows DWM or display-driver defect?

Your existing trace should be enough for now. We first need to know:

• What's your exact Windows version?
• Are you using multiple displays?
• Are there any displays plugged into the Intel GPU?
• Does the issue go away if you update your Nvidia driver?
• (Optionally) Does the issue go away if you disable the Intel GPU?

[Polymistis]

Hello,

• Windows 11 Pro 25H2, OS build 10.0.26200.8875 (KB5101650).
• Two active displays, both attached to the RTX 5090:
  • 2160x3840 portrait at 119 Hz
  • 3840x2160 primary at 144 Hz
• No displays are attached to Intel UHD Graphics 770. All enumerated Intel outputs are detached and have no current
  display mode.
• Intel UHD 770 remains enabled with driver 32.0.101.7082.
• NVIDIA driver is now updated to 610.74, no change.

Since the original trace, rendering.disablePartialInvalidation=true has been enabled and Codex animations/title
updates have been disabled. Any current lack of recurrence is therefore not attributable to the NVIDIA driver.

The driver was installed while the desktop was already degraded. Sluggishness remained afterward.

Before restarting DWM:

• Average DWM CPU: 43.85%
• Peak DWM CPU: 65.12%
• Private working set: 239.4 MB
• Handles: 1,857

After restarting DWM:

• Average DWM CPU: 17.16%
• Peak DWM CPU: 21.65%
• Private working set: 70.2 MB
• Handles: 1,997

Window dragging and application switching immediately returned to normal. The increased handle count after recovery
provides further evidence against a raw handle leak.

Long-session recurrence under NVIDIA 610.74 remains under observation.

[lhecker]

The DWM maintainers told me there's a known leak related to screen captures. Are you by any chance running any software that records your screen (e.g. OBS, Nvidia ShadowPlay, etc.)?