Hey jeffis, we appreciate the report.
Looked into this and very interesting indeed – it looks like a monitor change came in (WM_DISPLAYCHANGE) but there was no actual change. But in the meantime, the icons got moved. Critically – we see that there were two WM_DISPLAYCHANGE's generated within one second of each other, indicating two system monitor changes within a second.
> 2026-01-06 01:04:01,356 - WM_DISPLAYCHANGE Received
> 2026-01-06 01:04:02,238 - WM_DISPLAYCHANGE Received
Might you be able to share a little more of what went on between those "before" and "after" snapshots? Sounds like it goes to sleep, and then you immediately wake it up by moving mouse.
Also given the monitor only seems to sleep for a second - I'm wondering if this happens too if you let it sleep longer – say 30 or 60 seconds, instead of waking it up immediately? Wondering if the behavior is the same, and wondering what the logs might look like there. (Try this, and then upload logs again?)
===
Regarding the logs we have, here's the full technical detail in case you're curious.
A guess is perhaps that, for a split second moment, one of the monitors blinked out of existence as far as the system was concerned, but too quickly to react at a Fences-layout-recalibration level. Because the monitor disappeared however, the icons got moved (by Windows), and the move registered as valid (by Fences) as the monitor wasn't there. Groups themselves have the luxury of knowing that "move" operations are only valid if you move them, but for icons themselves, their positions are owned by Explorer, so if the icon moves, it technically is valid until proven otherwise.
Normally in this scenario, the new bad icon positions wouldn't save because the monitor remains gone long enough and by the time position changes save on batch delay, a monitor check is done, and the save is blocked. (It can be computationally expensive to scan full monitor configuration every single time an icon is moved – so this check happens on batch during save.) In this scenario, the save of the icon data would be blocked – and because the layout of the system has changed, the configuration would be reloaded from the registry, thus negating any transient icon moves that happened. But since it went out and back without time to react, the icons got moved, but no reload-from-registry happened as no layout change was detected. And actually further, since no layout change was detected, the new incorrect icon positions get written to the registry as if all was good.
> 2026-01-06 00:52:50,647 - Saved icon [...] -> 3:[1920x1080@100]+[1920x1080@100][1920x1080@100] -> -1|3944|367|3944|367|0|3840|0|\\.\DISPLAY3|0|0|0|Fences.exe|0|0|0
> 2026-01-06 01:04:03,855 - Saved icon [...] -> 3:[1920x1080@100]+[1920x1080@100][1920x1080@100] -> -1|2176|294|2176|294|0|1920|0|\\.\DISPLAY3|0|0|0|Fences.exe|0|0|0
3944 vs 2176 above is what is wrong regarding the shift, as well as 0|3840 vs 0|1920, indicating a shifted owning-display coordinates despite still listing \\.\DISPLAY3. These are numbers from the top left of the desktop not the 0,0 of the primary monitor.
Further: Something notable as well is that the OS's own APIs may not have fully updated. Full dump at time of event still reporting 3 monitors. So we might need to get you another build for some more fine tune debugging. Might take several attempts to figure out where this tripwire is occurring.
2026-01-06 01:04:01,356 - WM_DISPLAYCHANGE Received
2026-01-06 01:04:01,361 - DetectResolutionChange attempt
2026-01-06 01:04:01,374 - DetectResolutionChange all clear, fingerprints match 0
2026-01-06 01:04:01,386 - Skipping SyncMultiMonAsync, fingerprints haven't changed. [0|0|1920|1080|1|\\.\DISPLAY1];[-1920|0|1920|1080|0|\\.\DISPLAY2];[1920|0|1920|1080|0|\\.\DISPLAY3]; / [0|0|1920|1080|100|\\.\DISPLAY1|\\.\DISPLAY1\Monitor0|\\?\DISPLAY#AUS25AB#5&2a9d5ec8&0&UID176389#{e6f07b5f-ee97-4a90-b076-33f57bf4eaa7}|\Registry\Machine\System\CurrentControlSet\Control\Class\{4d36e96e-e325-11ce-bfc1-08002be10318}\0009];[-1920|0|1920|1080|100|\\.\DISPLAY2|\\.\DISPLAY2\Monitor0|\\?\DISPLAY#ACI22AE#5&2a9d5ec8&0&UID176385#{e6f07b5f-ee97-4a90-b076-33f57bf4eaa7}|\Registry\Machine\System\CurrentControlSet\Control\Class\{4d36e96e-e325-11ce-bfc1-08002be10318}\0004];[1920|0|1920|1080|100|\\.\DISPLAY3|\\.\DISPLAY3\Monitor0|\\?\DISPLAY#AUS25A8#5&2a9d5ec8&0&UID176388#{e6f07b5f-ee97-4a90-b076-33f57bf4eaa7}|\Registry\Machine\System\CurrentControlSet\Control\Class\{4d36e96e-e325-11ce-bfc1-08002be10318}\0008];
====
Anywho.
Yes, information on what exactly happened in that blip between "before" and "after" would be useful, as well as "what does the log look like if you wait 60 second wait before waking the monitor up". And otherwise, stay tuned and appreciate your help.
