Wallpaper switching back after a second

[nightfever77]

Description

I set up two wallpapers, one for light mode and another one for dark mode.
When the theme switches from light to dark mode, the wallpaper switches also. But after a second the wallpaper switches back.
This occurs on the automatic theme switch at sundown and on forcing dark mode.

Expected Behavior

No response

Log Data

2024-12-18 16:10:18 | Info | SystemEventHandler.HandleTimeChangedEvent: system time changed from 18.12.2024 16:10:18 
2024-12-18 16:10:22 | Info | PostponeManager.Remove: postpone queue cleared 
2024-12-18 16:10:22 | Info | SystemEventHandler.SystemEvents_Windows11_SessionSwitch: system unlocked, refreshing theme 
2024-12-18 16:10:22 | Info | ComponentManager.GetComponentsToUpdate: components queued for update: [AppsSwitchThemeFile, SystemSwitchThemeFile, WallpaperSwitchThemeFile] 
2024-12-18 16:10:22 | Info | WallpaperSwitch.LogHandleSwitch: update info - previous: Light/Fill, now: Dark/Fill, mode: Fill, type: Individual 
2024-12-18 16:10:23 | Info | ThemeFile.SyncWithActiveTheme: theme used for syncing is ADMTheme, path: C:\Users\night\AppData\Local\Microsoft\Windows\Themes\ADMTheme.theme 
2024-12-18 16:10:23 | Info | AppsSwitchThemeFile.HandleSwitch: update info - previous: Light, pending: Dark, mode: Switch 
2024-12-18 16:10:23 | Info | SystemSwitchThemeFile.SwitchSystemTheme: update info - previous: Light/NoAccent, pending: Dark/NoAccent, mode: Switch, accent: no 
2024-12-18 16:10:23 | Info | ThemeManager.UpdateTheme: dwm management: full refresh requested by user 
2024-12-18 16:10:23 | Info | ThemeHandler.RefreshDwmFull: dwm management: refresh performed by theme handler 
2024-12-18 16:10:24 | Info | Tm2Handler.SetTheme: applied theme ADMTheme, from origin: C:\Users\night\AppData\Local\Microsoft\Windows\Themes\ADMTheme.theme directly via IThemeManager2 
2024-12-18 16:10:24 | Info | ThemeManager.UpdateTheme: refreshed dark theme, source: SystemUnlock 
2024-12-18 16:10:49 | Info | MessageParser.Parse: signal received: request for running status 
2024-12-18 16:10:49 | Info | MessageParser.Parse: signal received: validate autostart entries 
2024-12-18 16:10:49 | Info | TaskSchdHandler.GetLogonTask: logon task folder does not exist 
2024-12-18 16:13:28 | Info | MessageParser.Parse: signal received: get requested theme 

2024-12-18 16:25:05 | Info | Service.ForceMode: ui signal received: forcing dark theme 
2024-12-18 16:25:05 | Info | ComponentManager.GetComponentsToUpdate: components queued for update: [AppsSwitchThemeFile, SystemSwitchThemeFile, WallpaperSwitchThemeFile] 
2024-12-18 16:25:05 | Info | WallpaperSwitch.LogHandleSwitch: update info - previous: Light/Fill, now: Dark/Fill, mode: Fill, type: Individual 
2024-12-18 16:25:05 | Info | ThemeFile.SyncWithActiveTheme: theme used for syncing is ADMTheme, path: C:\Users\night\AppData\Local\Microsoft\Windows\Themes\ADMTheme.theme 
2024-12-18 16:25:05 | Info | AppsSwitchThemeFile.HandleSwitch: update info - previous: Light, pending: Dark, mode: Switch 
2024-12-18 16:25:05 | Info | SystemSwitchThemeFile.SwitchSystemTheme: update info - previous: Light/NoAccent, pending: Dark/NoAccent, mode: Switch, accent: no 
2024-12-18 16:25:05 | Info | ThemeManager.UpdateTheme: dwm management: full refresh requested by user 
2024-12-18 16:25:05 | Info | ThemeHandler.RefreshDwmFull: dwm management: refresh performed by theme handler 
2024-12-18 16:25:06 | Info | Tm2Handler.SetTheme: applied theme ADMTheme, from origin: C:\Users\night\AppData\Local\Microsoft\Windows\Themes\ADMTheme.theme directly via IThemeManager2 
2024-12-18 16:25:06 | Info | ThemeManager.UpdateTheme: dark theme switch performed, source: Manual 

Commit Hash, Version and Windows Build

• Commit: cf7a0fe
• Service/App: 10.4.1.1
• Updater: 3.1.4
• Shell: 1.3.3.0
• .Net: 7.0.5
• Windows: 22631.4602

Screenshots / Videos

No response

[rdxdkr]

I've done a fresh install of Windows 11 last week, with every possible system update installed. I decided to try the wallpaper switch feature for the first time as well (I've never used it before on Windows 10), but I'm experiencing the same issue.

[rdxdkr]

@nightfever77 @Spiritreader @Armin2208 After fiddling around with settings and config files for a while, I may have found a workaround and a possible cause for the behavior in question.

Basically, the .theme file created by AutoDarkMode contains two different wallpaper keys under the [Control Panel\Desktop] section, named Wallpaper and Wallpaper1, and they point to the images I've set up to be applied when switching to light and dark mode respectively. Is this the correct behavior? I haven't gone too deep into this, but there might be something that reads the Wallpaper key again after Wallpaper1 is used to set its own image.

Anyway, since then I've decided to let ADM handle the themes through Windows by defining two new custom themes, and for whatever reason the second one didn't save the correct image. After changing it manually inside the .theme file it appears to work, so I would advise to give it a try.

[nightfever77]

There was only one line Wallpaper1 pointing to the light theme image.
I added a line with Wallpaper pointing to the dark mode image.
But behavior is the same: wallpaper switching back after a second.
This is my .theme:

[Control Panel\Desktop]
Wallpaper=F:\Wallpapers\enterprise_A.png
Pattern=
MultimonBackgrounds=1
WindowsSpotlight=0
PicturePosition=4
Wallpaper1=F:\Wallpapers\Enterprise_E.png

Additional notice: If I change MultimonBackgrounds to 0, the images will be cross-changed but the behavior persists.

If I setup two different colors (black and white) instead of two wallpapers nothing changes, background remains grey.

[Spiritreader]

The wallpaper with a number at the end is the wallpaper for each monitor when MultiMon background is enabled.

A theme file should never contain both light and dark wallpapers. If that happens, it effectively means that something went wrong.
The only way to fix that would be to find out why this fail occurs, which is very hard to do because the API we are using is an undocumented black box that came from reverse engineering with a kernel debugger. (see SecureUXTheme).

What I've discovered is that there are multiple instances where windows modifies the theme file that was supposed to be applied, - often wrong - which is usually related to special Unicode characters though. So most likely not what is happening here.

@rdxdkr Getting multi monitor wallpapers to work In a way where the images show up on the correct monitor is quite the challenge by itself when simultaneously attempting to modify the light/dark UI flavor while maintaining a synchronized theme state between ADM and Windows.
When a user configures wallpapers via ADM, on a theme switch we first apply the wallpapers via a different API (IDesktopWallpaper) that supports setting wallpapers per monitor using the display identifier.

That change then gets propagated to the active theme file that windows uses, which serves as our base theme that we then modify with the remaining preferences configured in ADM.

This by itself is also a challenge, because we can't read the active theme file directly as it only persists in memory until an update is triggered by an unknown component that flushes it to disk.
We use a best effort method to effect this flush, but sometimes it doesn't work (or doesn't do it quickly enough, causing sync issues)
This new interim theme file is then patched, as mentioned above.

Since there is no explicit synchronization between those events (as it's all async without the ability to subscribe to callback events), what you're experiencing is mostly likely a desync event.
My guess is a state where the wallpapers are not yet fully propagated to the in-memory copy of the theme file, or where the flush-to-disk mechanism failed.
So before the change from the IDeskropWallpaper API is reflected.

A way to solve it would be to monitor the interim theme file and check if all of the users requested wallpapers are found, and then perform in the following order:

• retrigger the flush event for a couple of seconds and listen for changes to the interim file
• retrigger setting the wallpapers if no update is detected

As you can see, quite a bit of complexity that goes into getting this to work cleanly.

When you use the windows theme mode, all of this synchronization mess goes out the Window because we never land in a scenario where we had to synchronize two or more async api calls. The windows theme mode should work better in theory. It does for some, and almost never works for others.

So it's a YMMV situation on top of that.

[rdxdkr]

@Spiritreader yikes, that sounds incredibly bad but I guess I shouldn't be really surprised, given how this appears to be quite standard for Windows. Creating and editing themes via the Windows 11 settings UI is inexplicably confusing, after all.

Just wanted to add that I'm only using a single monitor and I haven't really touched any related settings. If you want I can share my .theme files, especially the ones automatically generated by ADM.

[Spiritreader]

sounds incredibly bad

Believe me, incredibly bad is still an understatement. The workarounds I had to do to get it to work as is range from inconvenient to straight up unhinged.

Even if you're only using a single monitor mode, if you use the multi monitor wallpaper API (which also supports single monitor scenarios) the whole fiasco will still happen.

At some point in the future when I have more time again, I'll hopefully get around to building some sync logic on top of what we currently have to hopefully mitigate this some more.