FancyZones doesn't restore the windows to the proper monitor after PC sleep

[Nahor]

Microsoft PowerToys version

0.59.1

Running as admin

• [X] Yes

Area(s) with issue?

FancyZones

Steps to reproduce

• Have a 2+ monitors PC.
• Ensure Windows is configure to turn off the monitors when the PC is idle
• I have the "allow zones to span across monitors" set
• Create zones on both monitors I have one zone of the primary monitor and 4 on the secondary:
• Put some windows on the 2nd monitor (I have a Discord window in zone 3, and two Steam windows in zone 4 & 5)
• Wait until Windows turn off the monitors
• Wake Windows

This was working fine in prior versions of PowerToys (0.58 at least, I don't know if it broke with 0.59 or 0.59.1) This is very similar to issue #18907, but that was closed as a duplicate of issue #16659 which doesn't look similar to the one being reported here.

✔️ Expected Behavior

The windows should remain in place

❌ Actual Behavior

The windows that were on the 2nd monitor are moved to the primary

Other Software

No response

[SeraphimaZykova]

/bugreport

[ghost]

Hi there!

We need a bit more information to really debug this issue. Can you add a "Report Bug" zip file here? You right click on our system tray icon and just go to report bug. Then drag the zipfile from your desktop onto the GitHub comment box in this issue. Thanks!

[Nahor]

Anything in particular that you're looking for? I'm not keen to put some random logs in a public forum accessible by everybody. For instance, FancyZones lists all the applications launched on my PC for the past 3 weeks. That alone is a treasure trove for any would be hacker.

[SeraphimaZykova]

You can send it directly to me at seraphima@janeasystems.com

[SeraphimaZykova]

Thank you for the report. As I can see there, the problem is with the work area identification to place the window in the right place. Can you please check it on 0.60? /needinfo

[Nahor]

Still not working with 0.60 after sleep or by manually turning off the second monitor.

[Nahor]

Still broken in v0.63

[bed428]

I'm having a similar issue with Discord. I place it in a Zone, and after a reboot/restart/sleep/logoff, when I open Discord it opens off screen completely. I have to click the icon in the taskbar, Alt+Spacebar, and maximize to get it to come back on screen (Win+Arrow keys doesn't even work.)

Environment: Windows 11 22623.730, 2 monitors, Discord and Powertoys both being run as administrator, PowerToys v0.63.0

[SeraphimaZykova]

Is it reproducible in 0.65? Thanks! /needinfo

[Nahor]

Yes it is.

[batoorr]

Hello, I'm having the exact same issue (running 0.65)

I have 4 separate Brave browser windows positioned on my 2nd display, after the system puts the DISPLAYS to sleep, after waking the displays, all windows get resized and moved to my primary display. If I put my PC to sleep manually (by button, or via start menu), its all fine after waking up.

[ajab21]

I'm having the same issue even with just a single 32" 4k monitor with multiple zones (custom layout). This issue occurs even when you have a single app (and single window instance of an app) distinctly snapped to a particular zone on the monitor extension without any other apps sharing that same zone.

I opted for PowerToys/FancyZones because I was informed and read that this problem with awake from sleep does not exist like it does with other zone partition apps. Sadly, it does happen exactly the same way as with other apps. If I leave my laptop during the workday for a few hours and monitor goes into standby mode, the problem does not occur. It's only overnight when the laptop eventually goes to sleep when this happens. You can imagine the frustration of starting each workday having to face this recurring problem. What's a bit odd about this is that my laptop is set to go to sleep after 1 hour when plugged in, but that doesn't seem to happen during the day even when I'm away for several hours. Again, only overnight it happens with the windows losing their assigned zones on the 32" 4k monitor.

[VinzNL]

Can confirm this still happens with version 0.67

[farnoy]

This also happens on my setup when using a single display at a time, not even putting Windows to sleep. Just turning off the display (it's an LG TV over HDMI) and on again causes windows to bunch up in the top left for me, and I have to fix each virtual desktop independently. The fix for me when this happens is to trigger the layout editor for FancyZones and exit it immediately. This re-calculates and applies the same layout as it was before the TV was turned off. It remembers the zone assignment but probably misses some event when the display is initialized/resized? This is on 0.68.1, Windows 10 22H2 19045.2728

[crutkas]

This was resolved with 0.68 build of PowerToys with PR #24290!

[VinzNL]

This was resolved with 0.68 build of PowerToys with PR #24290!

Not for me it isn't. It has definitely gotten better in 0.68, but I'm still dragging windows to their proper position after resuming from sleep in v0.69.1.

[jonbonney]

Can confirm, this issue is still present in v0.69.1. When the computer goes to sleep, all apps move to my primary window keeping the same resolution and location they had on the prior monitor (though smaller since my primary monitor is high resolution). The apps on the primary monitor are fine, but apps on additional monitors are not returned to their original monitor upon wakeup.

[crutkas]

@SeraphimaZykova fyi

[VinzNL]

To add to my previous statement, this doesn't just occur after waking the PC from sleep, it sometimes also occurs when the PC stays on but the screens have been powered down due to me being idle.

[SeraphimaZykova]

@VinzNL @jonbonney, most likely in your case the monitor IDs are causing the issue. The system could give them another ID after restarting/reconnecting/resuming from sleep, so FancyZones thinks that it's a new monitor where wasn't any window snapped. You can share a /bugreport here to let me check that. If I'm right, it's a different issue then. Thank you!

[microsoft-github-policy-service[bot]]

Hi there!

We need a bit more information to really debug this issue. Can you add a "Report Bug" zip file here? You right click on our system tray icon and just go to report bug. Then drag the zipfile from your desktop onto the GitHub comment box in this issue. Thanks!

[VinzNL]

PowerToysReport_2023-05-13-18-02-12.zip

[microsoft-github-policy-service[bot]]

This issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 5 days. It will be closed if no further activity occurs within 5 days of this comment.

[VinzNL]

I don't think the @Nahor , the original author of this issue, is still active in it, but since @SeraphimaZykova asked @jonbonney and myself for feedback marking it stale would be the wrong thing to do.

[Nahor]

Indeed, I can't easily test, I do not have a Win10 box with DisplayPort monitors anymore. I only have Win10 with HDMI or Win11 with DisplayPort, neither of which is affected by the bug. I can mess up with my setup if really necessary, but I'm unwilling to do so now since the bug has already been confirmed as unresolved by others.

(and hopefully, this post will satisfy the slash-bugreport mention for the stupid ms-github bot)

[VinzNL]

The Win10/Win11 thing is news to me, but you're right. I was contemplating an upgrade anyway so I pulled the trigger and I don't have the problems on Win11 any more. And both my monitors are DisplayPort so that fits your description as well. So it seems this bug is limited to people who are still using Win10.

[jonbonney]

I have mostly worked around the issue by increasing my screen sleep timer. I am on windows 10 and using display ports. What email address should I send the report file to?

[Nahor]

The Win10/Win11 thing is news to me, but you're right. I was contemplating an upgrade anyway so I pulled the trigger and I don't have the problems on Win11 any more. And both my monitors are DisplayPort so that fits your description as well. So it seems this bug is limited to people who are still using Win10.

Hmm, I thought I had mentioned the DisplayPort vs HDMI before, but I can only find a vague mention in #18907. In any case, yes, it works on HDMI but not with DisplayPort. I believe the reason is because a sleeping DisplayPort monitor is considered disconnected by Windows, so all the windows get moved to the primary monitor when the secondary one goes to sleep, while a sleeping HDMI monitor is remains connected, so the windows don't get moved in the first place.

As for Win10/Win11, Win11 has a setting called "remember windows location based on monitor connection" (the main use case is probably for laptops being intermittently docked/connected to external monitors, e.g. home vs office). So when the secondary DisplayPort monitor comes back online, Windows will move the windows back to it. It's still possible that PowerToys has the bug on Win11 where the windows are not correctly re-attached to the zones even if they are moved to their proper location. If the bug does exist on Win11, it doesn't affect me at least, since I do not swap between different zone layouts.

[SixFive7]

I'm have been experiencing a slightly different version of this bug for the past few months.

My setup is windows 11 with 1 HDMI center screen (LG OLED TV) and 2 displayport side monitors. The side monitors never sleep, but the LG center screen is OLED, so I let it sleep to save the pixels. Windows 11 also never sleeps.

If I wake up the center screen on my otherwise running system everything starts shifting around ending up on different places. Then over a timespan of +/- 30 seconds part of my window collection gets restored correctly by fancy zones, but about half ends up on the wrong place. I have no clue as to why this is taking so long or if there is a pattern to the faulty restore postions. I do have 200+ windows open most of the time (yes yes I know), but then still, it should take no more than fraction of a second sending all the win32 window events. I do know it must be fancyzones that is struggling because:

• Without fancy zones I do not have this behaviour.
• All 32 cores are doing absolutely nothing except for fancyzones.
• But more importantly trying to use fancyzones during that time window will have +/- 30 sec. delayed responses.

It's as if fancyzones is taking a super long to (badly) restore window positions after a monitor wake up and is enqueuing all input until that is done. I did observe some firefox windows moving multiple times. So either fancyzones is applying multiple restore logic commands. Or windows and fancyzones are battling out some (set then check) race condition multiple times. I don't know.

Hope this report gives some context for this issue. Let me know if I can do anything else to help or test.

[crutkas]

/dup https://github.com/microsoft/PowerToys/issues/16370

[microsoft-github-policy-service[bot]]

Hi! We've identified this issue as a duplicate of another one that already exists on this Issue Tracker. This specific instance is being closed in favor of tracking the concern over on the referenced thread. Thanks for your report!