- Status
- Offline
- Joined
- Mar 3, 2026
- Messages
- 421
- Reaction score
- 7
Anyone digging into kernel-mode overlays on the latest Windows builds has probably run into the classic GDI persistence headache. I've been experimenting with attaching to dwm.exe to render graphics directly from a driver, but the drawings just sit there—stuck on the screen because they aren't refreshing with the composition cycle.
The Current Setup
Working on Windows 11 24H2. The logic involves attaching to the DWM process and hitting the GDI syscalls. While the primitives actually draw, they create a "ghosting" effect where the previous frames never clear out.
Attempted Fixes & Roadblocks
If you're moving away from external overlays to something more integrated, you've likely seen this behavior. The persistence suggests the surface isn't being marked as dirty, or the GDI stack isn't communicating with the DXGI flip chain correctly.
Has anyone successfully forced a DWM refresh on the latest builds without causing a TDR or BSOD?
who's managed to sync kernel draws with the DWM present cycle on 24H2?
The Current Setup
Working on Windows 11 24H2. The logic involves attaching to the DWM process and hitting the GDI syscalls. While the primitives actually draw, they create a "ghosting" effect where the previous frames never clear out.
Code:
hdc = NtUserGetDC(0);
brush = NtGdiCreateSolidBrush(RGB(255, 255, 255), NULL);
NtGdiSelectBrush(hdc, brush);
NtGdiPatBlt(hdc, x, y, w, h, PATCOPY);
NtGdiFlush();
NtGdiDeleteObjectApp(brush);
NtUserReleaseDC(hdc);
Attempted Fixes & Roadblocks
- Tried NtGdiFlush — it's clearly not enough to trigger a redraw of the composition surface in modern DWM environments.
- Hooking NtGdiDdDDISubmitCommand and DxgkPresent — even with these hooks in place, getting a clean render without flickering or artifacts on 24H2 is becoming a nightmare.
- Invalidating rectangles — GDI is effectively legacy for the Desktop Window Manager, which prefers DXGI/Direct3D for the actual composition chain.
Windows 11 24H2 has tightened the screws on how the display miniport driver and the composition engine interact. Relying on simple GDI primitives from a kernel context usually results in these "dirty" rectangles staying in the front buffer until a full screen update is forced by another window move or system event.
If you're moving away from external overlays to something more integrated, you've likely seen this behavior. The persistence suggests the surface isn't being marked as dirty, or the GDI stack isn't communicating with the DXGI flip chain correctly.
Has anyone successfully forced a DWM refresh on the latest builds without causing a TDR or BSOD?
who's managed to sync kernel draws with the DWM present cycle on 24H2?