Theme partially disabled when external display connected

[e-t-l]

~~When I start up my computer, some colors in my custom theme are incorrect. Once I launch ThemeTool and re-apply my current theme, they get corrected. The correct colors persist even after logoff/login; it seems like it's only an issue on system start.~~

See updated comment below.

~~Below is all the debugging info I can think of. Let me know if there's anything else I can share. I only started noticing this issue around November/December 2024, so it's possible it's a conflict with a recent cumulative update. If you're going to test it out on a VM, maybe start with update KB5046633 and go forward from there?~~

ThemeTool:

> Version v3.0.0
> Running on 10.0.26100 flavor F
> MainDialog: is_elevated 1

Windows:

Windows 11 version 24H2 (64-bit)
OS build: 26100.2605
Stable release channel
Last cumulative update: KB5048667

[Undam]

I have the same problem with this latest version of SecureUxTheme and the latest version of UltraUXThemePatcher even after taking ownership of uxtheme.dll, uxinit.dll, themeui.dll before patching. I too only started noticing this issue in November. Right now I am sticking with UltraUXThemePatcher only because the issue seems to occur less often, granted my testing was limited with SecureUxTheme.

Windows 11 version 24H2 (64-bit) OS build: 26100.2605 Last cumulative update: KB5048667

[e-t-l]

Update

I no longer thing it's system startup that's causing the issue, I think it's when I connect to an external display (specifically, connecting to a TV via HDMI). So now I don't even know if the issue is exclusive to Win 11 24H2 or not! Hopefully this will help with further debugging.

[e-t-l]

Confirming after further testing that the issue is reproducible when connecting an external display/tv via HDMI.

Using ThemeTool to re-apply a theme does not work UNLESS I first lock the computer and log back in. (I have the LogonUI hook installed, so presumably that hook is somehow "resetting" whatever part of the injection got corrupted.)

[Rekit0]

I also can confirm this, I have the same issue on windows 11 23H2. Even if i re-apply the theme using SecureUxTheme nothing happens while the TV is still plugged in.

[namazso]

I don't really understand how this is possible. I went through every call of SetSysColors (the thing that controls the solid colors used) in every binary on a 24h2 install. Here's the breakdown:

Unimportant stuff:

• win32k.sys (implementation stub)
• win32kbase.sys (actual implementation)
• win32u.dll (syscall stub)
• user32.dll (user stub)
• shell32.dll (only sets COLOR_DESKTOP for wallpaper stuff)
• BootMenuUX.dll (only sets COLOR_DESKTOP for wallpaper stuff)
• Microsoft.Uev.AppAgent.dll (only sets COLOR_DESKTOP)
• Microsoft.Uev.ModernAppAgent.dll (only sets COLOR_DESKTOP)
• KernelBase.dll (some API listing for debugging or telemetry)
• unimdm.tsp (some 56k modem shit, code probably from the 90s)
• msoobedui.dll (OOBE, sets from DefaultColors)

Actually meaningful:

• themecpl.dll (Vista control panel)
• LogonController.dll (sets from DefaultColors)
• themeui.dll (sets when applying a new visual style)
• uxtheme.dll (exports SetSystemMetrics ord 90, ApplyThemeSections ord 93, SetSystemVisualStyle ord 65)

themecpl

ThemeTool is based on the usage patterns from this, but its otherwise unused.

themeui

themeui exposes its features only through two COM interfaces, CThemeManager2 and CThemeManagerShared:

CThemeManager2 users:

Uninteresting:

• aitstatic.exe (big ass GUID list for telemetry)
• desk.cpl (XP theme manager control panel, only Init then Release)
• explorer.exe (only calls UpdateColorSettingsForLogonUI)
• stobject.dll (only calls UpdateColorSettingsForLogonUI)

Interesting:

• CloudRestoreLauncher.dll (cloud restore)
• sethc.exe (set high contrast)
• SettingsHandlers_nt.dll (Settings app)
• themecpl.dll (Vista theme manager control panel)
• twinui.pcshell.dll (something to do with Appx themes)

CThemeManagerShared users:

• aitstatic.exe (big ass GUID list for telemetry)

Of course none of these should be any relevant when plugging in extra displays.

uxtheme

Unfortunately this one is exported by ordinal, so going through all usages would be a pain, but this is mainly used for setting styles. Signature checking only happens in EnumThemes, and it's unlikely someone would be enumerating what to set when a new display arrives.

However, SetSystemMetrics is plausible to be called when DPI scaling is in play.

LogonController

This should just bail if DefaultColors isn't there, and just not even call SetSysColors

---

I have a few questions to someone who still has this issue:

• Is there any DPI scaling in play? I remember themes had issues with that in the past.
• Does it happen to all themes?
• Does it happen when using a high contrast theme too?
• Does HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Themes\DefaultColors exist? It shouldn't due to the "Remove DefaultColors" feature when installing, but I wouldn't be surprised if a Windows update added it back.

[e-t-l]

I will check on these when I'm next on my desktop (on mobile right now.) Just to clarify...

• Is there any DPI scaling in play? I remember themes had issues with that in the past.

Personally, yes both my built in monitor and the connected display are high res so they have DPI scaling on. Are you suggesting setting the DPI scale back to 100% may resolve the issue? I can certainly try it.

• Does it happen to all themes?

All custom themes I've tried, yeah. Are you asking about regular themes too? (The parts of the theme that get affected by this bug are things like the background color for the Win+R run dialog, and the bug seems to make them revert to white; i.e. only custom themes are affected because only custom themes set that color to anything other than white)

[namazso]

Are you suggesting setting the DPI scale back to 100% may resolve the issue?

Not sure about that, but knowing whether scaling is what triggers the condition would be a good clue.

Are you asking about regular themes too?

only custom themes are affected because only custom themes set that color to anything other than white

Actually, high contrast themes also set the colors, which is exactly why I'm asking about those as well.

[namazso]

Just released 4.0.0 which may or may not fix this.

[e-t-l]

~~I was trying to debug this on v3.0.0 and was having difficulty reproducing it for some reason, then realized I had recently installed the SystemSettings hook because I wanted a more convenient way to reset the colors. However, it looks like hooking SystemSettings might actually be enough to fix the problem entirely!~~

This turned out not to be true; the issue still occurs with SystemSettings hooked. I have not yet gotten around to upgrading to v4.0.0 to see if that fixes it though

[namazso]

I think it's more likely you had "Remove DefaultColors" enabled when doing the reinstall. A Windows Update probably restored the key / values earlier, which is what caused the symptoms. With 4.0.0 the colors are cleared every new session, so this shouldn't be an issue anymore.

[e-t-l]

@namazso Please reopen.

Unfortunately the issue persists on v4.0.0.

(for comparison, below is the correct colors, which returns after I unplug the HDMI and I run my .theme file.)

.

Getting back to the troubleshooting you had requested earlier...

• Is there any DPI scaling in play? I remember themes had issues with that in the past.

Yes. My integrated monitor is scaled to 150%. When I tried setting it to 100% and then connecting the HDMI, I actually got inconsistent results. Sometimes it messed up some of the colors, sometimes it didn't. Not sure what's going on there.

• Does it happen to all themes?

Yes, all the ones I've tried, which granted is not many. Here's the theme I normally use if you want to play around with it (I didn't actually compress the files, only renamed them so github would upload them, so just remove .zip from the filenames) Black-Win-min.theme.zip , Black-Win.msstyles.zip

• Does it happen when using a high contrast theme too?

No. High contrast themes do not appear to be affected.

• Does HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Themes\DefaultColors exist? It shouldn't due to the "Remove DefaultColors" feature when installing, but I wouldn't be surprised if a Windows update added it back.

As of v4.0.0, yes, that key does exist. It has two subkeys, .\HighContrast and .\Standard, but none of these keys contain any actual data. I forgot to check whether the keys existed before uninstalling v3.0.

[namazso]

Very weird. It evidently isn't setting DefaultColors because those are most certainly not around on 4.0.0, so it must be from the theme.

Could you grab Procmon, and set up filtering like this:

After that, trigger the issue. You should see something like this (or just any events, really):

Once that's done, save the capture with the default settings, and share it here (or via mail). This should tell us if anyone tried to signature verify the theme.

[wbalmung]

@namazso Not the original poster, but having the exact same issue. I ran Procmon with the filter you requested and captured a record, let me know if there's anything else I can share to help.

ProcmonThemeLog.zip

I'm running on the latest version of Windows 10 and SecureUXTheme, with 3 displays at 4k/120hz, 1440p/144hz and 1080p/60hz. The issue only seems to occur when the 4k/120hz display is connected, and I've had it connected via both direct HDMI and a Displayport-to-HDMI adapter.

[namazso]

Thanks. All I can tell from the procmon capture is that SecureUxTheme is working as intended, no one is reading the signature so it can't have failed. Unfortunately the filters I provided don't contain why (or who) asks rundll32.dll to apply the Aero style instead, which would be the interesting part in this case. My initial guess would be that it's some sort of theme problem, and whoever handles the new display notices that and reverts to aero.

[namazso]

I can confirm this is an issue with the theme not working on a specific DPI. UXInit will first test if the currently loaded theme matches the wished plateaus. If it does not, it attempts reloading the current theme. If that returns a failure code, it will instead load aero.msstyles.

You can override the loaded plateaus by setting DWORD ForceThemePlateaus to 1 in HKLM\Software\Microsoft\Windows\CurrentVersion\ThemeManager and setting DWORD ThemePlateaus to a bitmask of your wished plateaus in HKCU\Software\Microsoft\Windows\CurrentVersion\ThemeManager. Of course I have no idea what terrible consequences this will come with, or even if it will work at all.

DPI to plateau mapping:

0-118 -> 1 119-143 -> 2 144-191 -> 4 192-239 -> 8 240-287 -> 16 288-383 -> 32 384+ -> 64

However, I'm going to close this issue now as it is clear that this is not a SecureUxTheme issue.

[e-t-l]

Awesome troubleshooting, thank you! Although I'm not sure how to determine the DPI of my displays (particularly with how it might be affected by the Windows settings for Scale and Resolution). I would also assume that the DPIs of my default monitor versus the HDMI-connected secondary monitor are different, and that's what's causing the issue, so I don't know which one's values I would use to set these regkeys...

I notice in "Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ThemeManager" that DllName = %SystemRoot%\resources\themes\Aero\Aero.msstyles; do you think it would work to replace that with the path to the user's custom msstyles file?

[namazso]

It’s simple, the “standard” DPI is 96, and the “scaling” in windows is the multiplier to that. You can divide my earlier numbers by 96 and conveniently get exactly the same percentages as Windows offers for scaling. So, to work around this limitation in your theme you can also just make sure your all displays’ scalings are 100%.

do you think it would work to replace that with the path to the user's custom msstyles file?

For fixing this issue, no. Aero is hardcoded as fallback in UXInit.dll

[e-t-l]

do you think it would work to replace that with the path to the user's custom msstyles file?

For fixing this issue, no. Aero is hardcoded as fallback in UXInit.dll

What I did, which seems to be working perfectly so far, is rename my custom theme to "aero." In other words, in the windows Themes folder, I made the following name changes:

• [folder] aero >> aero.bak
• aero.theme >> aero.theme.bak
• mytheme.theme >> aero.theme
• mytheme\mytheme.msstyles > mytheme\aero.msstyles
• [folder] mytheme >> aero

Basically tricks Windows into using my theme instead of aero.

[namazso]

I think that will trip WRP

[e-t-l]

I think that will trip WRP

Hmm, it's possible. All I can say is I did this a month ago and haven't had any issues so far

Edit: a quick google couldn't find a list of WRP-protected folders, but given my successful experience with this (and the fact that even before doing this, I had placed my custom theme folder and .theme file in the Themes folder), I would guess that the Themes folder is not a protected resource.