Keeping this as a draft until the user confirm it works.

The user has confirmed that it works, but with a very minor caveat where they have to wait a second or two to let it work normally

Submission review

Note: This review was done by Claude, and then refined manually. Due to the amount of submissions, doing a fully manual review for each pull request is no longer feasible. Thank you for understanding.

Please address the following issues. The items in the collapsed sections are optional, so it's your call whether to address them.

1. Wh_ModUninit wipes the caption color of app-controlled windows. The whole point of the new g_appControlledWindows set is to never touch windows whose owning app set DWMWA_CAPTION_COLOR itself. But UninitEnumWindowsProc doesn't consult that set — it resets DWMWA_CAPTION_COLOR to DWMWA_COLOR_DEFAULT (and clears immersive dark mode) on every eligible window:

// UninitEnumWindowsProc — mods/auto-custom-titlebar-colors.wh.cpp:663
if (!IsWindowEligible(hWnd)) return TRUE;
BOOL off = FALSE;
DwmSetWindowAttribute(hWnd, DWMWA_USE_IMMERSIVE_DARK_MODE, &off, sizeof(off));
const COLORREF def = DWMWA_COLOR_DEFAULT;
DwmSetWindowAttribute(hWnd, DWMWA_CAPTION_COLOR, &def, sizeof(def));

So when the mod is disabled/reloaded, any window the app itself colored gets its color blown away and reset to the system default — the opposite of "leave it alone". Since many apps set their caption color only once (at window creation), it won't come back until the app restarts. Skip windows in g_appControlledWindows here (and ideally only reset windows the mod actually colored). This also makes the unload non-reversible for those windows, which is a core Windhawk principle.

2. g_appControlledWindows / seenWindows grow forever and key on recyclable HWND values. Neither set ever removes an entry when a window is destroyed:

static std::unordered_set<HWND> g_appControlledWindows;   // never erased
...
static std::unordered_set<HWND> seenWindows;              // never erased

Two consequences in a long-lived, broadly-injected (@include *) process like explorer.exe:

• Stale-HWND false positives: Windows recycles HWND values. Once a tracked window is destroyed, a brand-new, unrelated window can be created with the same handle value — it will be found in g_appControlledWindows and silently never colored (item stays until the process dies).
• Unbounded growth: both sets accumulate one entry per window ever seen, for the life of the process.

You already hook DefWindowProcW/A, so HandleWindowMessage can handle WM_NCDESTROY and erase(hWnd) from both sets to bound the lifetime and fix the reuse hazard.

Noted, will work on this when I have the time.

@m417z Hope this settles it

Submission review

There are additional notes regarding the mod functionality. I didn't verify them, but they might be worth fixing. Take a look, if you think the mod is ready as is, let me know.

1. The eligibility cache is poisoned at window creation — the structural UWP/WinUI detection never fires for windows created after the mod loads. CreateWindowExW/A_hook calls ApplyTitleBar immediately after the top-level window is created (line 594), at which point the window has no children yet. IsWindowEligible runs EnumChildWindows, finds no CoreWindow/DesktopWindowXamlSource/DesktopChildSiteBridge, and caches isEligible = TRUE (lines 225–233) — an entry that's only evicted at WM_NCDESTROY. When the bridge child appears moments later, every subsequent check (WM_NCACTIVATE, theme changes, …) hits the stale TRUE and the mod colors the window anyway. Net effect: the detection only works for windows that already exist at Wh_ModAfterInit time; any UWP/WinUI 3 window opened afterwards is treated as a normal window — reintroducing exactly the conflict from issue 4582. (The create-time ApplyTitleBar also colors the window once before detection could possibly succeed, which likely explains the "wait a second or two" caveat the reporter mentioned.)

Suggested fix, in two parts:

• Don't populate the cache from the CreateWindowEx path — pass a "don't cache" flag (or skip the ApplyTitleBar eligibility caching there), so the first activation-time check, which runs when the children exist, is the one that gets cached.
• Additionally, invalidate on child creation: in the CreateWindowEx hooks, GetClassNameW the new window, and if it's one of the bridge classes, mark GetAncestor(hWnd, GA_ROOT) ineligible in the cache — and reset that root's DWMWA_CAPTION_COLOR to DWMWA_COLOR_DEFAULT, since the create-time apply may already have colored it. Note this doesn't cover the UWP ApplicationFrameHost case, where the CoreWindow is created in the app's process and reparented into the frame window cross-process — so the first bullet (defer caching to activation time) is the important one; the child-creation invalidation covers same-process XAML/WinUI 3 windows.

2. Dialogs never reach HandleWindowMessage, so their WM_NCDESTROY cleanup never runs. The DefDlgProcW/A hooks exist precisely because dialogs don't route through the exported DefWindowProcW/A — but they only special-case WM_NCACTIVATE (lines 553–576). For every dialog, the g_eligibilityCache / g_appControlledWindows entries are therefore never erased, which brings back the two hazards from the previous review round for this window class: unbounded growth, and stale entries on recycled HWND values (a new unrelated window reusing a destroyed dialog's handle inherits its cached eligibility / app-controlled status). Dialogs also miss the WM_ACTIVATE / WM_SETTINGCHANGE / WM_DWMCOLORIZATIONCOLORCHANGED handling. Fix: call HandleWindowMessage(hWnd, Msg, wParam, lParam) from both DefDlgProc hooks and drop the duplicated WM_NCACTIVATE block (double-handling in case both hooks fire for a message is harmless — the erase is idempotent and ApplyTitleBar is repeat-safe).

3. Wh_ModUninit still force-resets DWMWA_USE_IMMERSIVE_DARK_MODE to FALSE on windows whose app set it itself. g_appControlledWindows only tracks DWMWA_CAPTION_COLOR, but many modern Win32 apps (terminals, editors, Chromium/Electron apps) opt into dark titlebars themselves via this same attribute, typically once at window creation. Disabling the mod while the system is in dark mode flips those titlebars to light until the app restarts (lines 677–678) — the same reversibility problem as the caption-color half you already fixed. Suggested fix: in DwmSetWindowAttribute_hook, also track app-initiated sets of DWMWA_USE_IMMERSIVE_DARK_MODE (e.g. an HWND → BOOL map of the app's last value, cleaned up at WM_NCDESTROY like the others), and at uninit restore that recorded value instead of unconditionally writing FALSE.