Summary
The main RazerAppEngine.exe process (the one without --type=) starts leaking GDI objects about 40 minutes after launch, at a steady ~70 objects/minute, until it hits the default per-process limit of 10,000. While the leak is active, the whole Windows UI stutters: taskbar, window dragging, app rendering. The input-language hotkey (Alt+Shift) also becomes unreliable. Restarting RazerAppEngine immediately resets the count and the symptoms disappear. Measured over 3 days with per-minute logging plus an ETW kernel trace.
Environment
- Windows 11 26H2, build 26300.9550
- NVIDIA RTX 5080, driver 32.0.16.1714; two monitors (240 Hz + 60 Hz)
- Razer Synapse 4.0.827.114, autostart (
--url-params=apps=synapse --launch-force-hidden=synapse --autoStart=1), 10 RazerAppEngine processes - Only Razer device connected: BlackShark V2 Pro (USB)
Measurements (per-minute log, main RazerAppEngine process)
- After start: 39–82 GDI objects, stable. USER objects stable at ~170. Private memory stable at 160–300 MB, so this is not a RAM leak.
- About 40 min after logon the GDI count starts growing linearly, ~70 objects/min (76 → 325 → 2,049 within 30 min). It reaches 10,000 within roughly 2–2.5 hours and stays pinned there.
- Session-wide GDI count grew from ~9,000 to ~21,800 accordingly.
Correlation with UI responsiveness
Explorer taskbar response to WM_NULL was probed every 2 s:
- Before the leak starts: 0–3 ms.
- From the very minute the leak starts: 8–9 of 30 probes per minute exceed 40 ms, up to ~1 s.
- Once at 10,000: every minute affected, 35–65% of probes over 40 ms, peaks of 3.5–5 s. This continued for ~46 hours without interruption.
- Restarting RazerAppEngine reset the GDI count to ~80, and the stutter and Alt+Shift problem disappeared immediately. Reproduced twice.
- Additional observation: on one occasion the stutter mostly stopped earlier, when Windows killed a hung ShellExperienceHost.exe, while RazerAppEngine was still at 10,000. This suggests the leak interacts with the shell / notification area. That part is a hypothesis.
ETW trace (WPR, CPU + context switch + GPU + DWM)
- UI threads of dwm.exe and of applications repeatedly block on
WrResourcewaits of 52–60 ms. Each time they are released by a thread executing in win32kfull.sys/win32kbase.sys, i.e. contention on the win32k lock. - Frame presentation (PresentMon) shows matching periodic 54–67 ms gaps.
- Ruled out: CPU starvation (scheduler latency ≤ 13 ms), DPC/ISR (max 2.9 ms), disk I/O (disks idle), GPU throttling.
Not determined
Which code path creates the leaked objects. A tray-icon or bitmap update is suspected but not confirmed. I can collect a GDI object type breakdown or an ETW trace with stacks if needed.
Workaround
Restarting RazerAppEngine when its GDI count starts rising. Note: raising GDIProcessHandleQuota in the registry would only let the leak grow further.
Expected
The GDI object count of RazerAppEngine should stay flat during normal operation.