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

### 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` | 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:

```json
{
"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.

Start with src/renderer/atlas/AtlasEngine.r.cpp around lines 333-355 and compare long-session behavior with rendering.disablePartialInvalidation enabled and disabled. Reproduce the workload, capture the WPR CPU plus DesktopComposition profiles, and compare DWM activity; done requires a confirmed Terminal-side mitigation or evidence that the behavior belongs to DWM or the display driver.

Written by the indexing model from the issue text.