done and sent

Thank you for your dedication to this issue.  I did wait about 60 seconds in the monitor power saving state before moving the mouse in case it does not show.

Your efforts show great dedication to your software and go above what most software devs have shown me in my experience so far!

Thank you!

Is there any news?

Hi Jeffis, newsch1,

We put in enhanced debug logging for this in the new version above, so just checking in on if anyone has been able to give this a shot, assuming the issue is this occurring. Thanks for any insight

Thanks for asking.

As I already wrote, I changed the monitor connections and no longer have any problems. So I can't tell whether your changes solved the problem.

uploaded before and after.  I have created a bandaid for now, doesnt fix the issue but does stop it from messing up my icons.  I just created new fences called left center and right monitors. and just drag my random icons there.  For testing I moved a few icons out of the right monitor fence.  As you can tell they moved into the center after power saving.

[ResetFrom] Icon monitor origin changed (.lnk) [\\.\DISPLAY3, 3840x0->1920x0]

Very interesting! So yes, one minute after workstation lock, the screen goes to sleep (at least for a second), then 15 seconds later a WM_DISPLAYCHANGE notifies of a display settings change. But, according to the display enumeration, everything is still the same – \\.\DISPLAY1, \\.\DISPLAY2, \\.\DISPLAY3, and the overall virtual screen size etc. Yet – those icons somehow then report that the monitor origin has changed, thus shifting them in.

This aligns with the initial guess that somehow \\.\DISPLAY3 is blinking out of existence for a moment in some Windows subsystem layer but not another.

"I would guess" that the monitor handle has just gone invalid somehow, and so the system is defaulting to the primary, except that that's not how the GetMonitorInfo API works. So. Going to need to think of ways to debug this further to see what's going on, and see which kind of redundancy helps turn up the truth. Very strange!

Thanks again for rolling along with this and will be back with more.

will have to be tomorrow as im not at a point i can shutdown my pc atm.

Thanks Jeff!

Aye! Looks like this attempt was with v6.40 from February. Had added v6.41 (6.4.1.2) in the post above March 2 – though, looks like the link was broken, so you might not have been able to try. Here it is fixed:

https://www.dropbox.com/scl/fi/z601k08hmmzrjifde2su6/Fences6_6.4.1.2-j110-Setup.exe?rlkey=vslexmaoq2fzoyud17h4n7wo6&dl=1

This one might even fix the issue, so, 🤞. It adds (1) A whole bunch of debug code looking for invalid monitor handles, which is the current hypothesis, and (2) Ability to fix invalid monitor handle, if detected

2026-03-04 22:45:02,561 - [ResetFrom] Icon monitor Pre-Change-Verify [rcMonitorValid 0] (.url) [\\.\DISPLAY3, 1920x0->1920x0] [VerifyMonitor1: 10062 0 0,0 0x0] [VerifyMonitor2: 0 0 0,0 0x0] - 0

We are getting close!

This verified that the monitor handle at \\.\DISPLAY3 was indeed invalidated, and as well, we're unable to look up a new handle for it, even though it's still being reported as present by Windows via EnumMonitors.

This is touching on very sensitive logic, wherein a "fix" could create problems for other people, so, treading carefully and making sure to understand the scenario.

Going to think up a final round of debug output to explore the scenario more exhaustively, and then can hopefully come to a decision around how to go about fixing. 
(1) If monitor is invalid, and cannot refresh handle, ignore monitor change without attempting to reassign to a new monitor [would fix, but dangerous, if we don't know why it's still present but giving back nil monitor info]
(2) cache the monitor information. if monitor info missing but monitor itself is still present, pull from cache [likely even more dangerous]
(3) [something else, depending on what the debug output shows]

New build coming in the morning. 👍 I don't know what it is about this specific system that is causing this, but, it's immaterial. The app needs to be able to know that this scenario exists and handle it.

Unclear. It does look like it's just an issue with the handle being invalidated. More or less, the monitor never leaves, but its handle is invalidated during the display changeover. We haven't seen this before, but, we should be able to handle it, and this isn't actually that crazy of a scenario. I'm surprised we haven't seen it before.

Found a gap in the just-added handle refresh logic in 6.4.1.2 (saw it just now walking through in debug after reviewing log), so, there's a good chance the next build resolves this in full. I'm going to guess that it just refreshes the handle, and everything just works.

did i get a tinkered with file??  Did not receive the warning on any of the other files.

Fixed! Thanks again

https://www.dropbox.com/scl/fi/m4zxfd1ynmw75a991zvpv/Fences6_6.4.1.4-j113-Setup.exe?rlkey=rnfr843eia2eylsv1eygq4ovp&dl=1