search

RamonUnch / AltSnap

Maintained continuation of Stefan Sundin's AltDrag
GNU General Public License v3.0
2.06k stars 65 forks source link

Windows 11 crash #125

Open Ichisich opened 2 years ago

Ichisich commented 2 years ago

https://github.com/RamonUnch/AltSnap/issues/124#issuecomment-962596040

I still have a crash on Win11, I have no clue on how to fix (I do not have Win 11 so this is a pure guessing job).

I currently have Windows 11 installed in a Hyper-V environment. If you want I can try to reproduce the crash conditions.

RamonUnch commented 2 years ago

see https://github.com/RamonUnch/AltSnap/issues/107 for more details, I think it happens when staying in sleep mode for a while, I am not sure on how to reproduce, If you are able to get the crash, then You can try with a debug build. I will provide one here.

Ichisich commented 2 years ago

Mhh, xzayn unfortunately doesn't give much information. Closing after some time isn't really specific.

I let Windows 11 run a few hours without touching it and couldn't register anything out of order. It also appears that Windows 11 didn't change anything profound in its window management. Border (visible and invisible) sizes are identical, and even the notorious 8 pixel start-gaps are still present.

In short, AltSnap seems to work exactly like in Windows 10, although with the caveat that I used a virtual machine.

RamonUnch commented 2 years ago

Did you try with the latest test build or with the 1.47 release. The later test builds are disabling AltSnap when windows goes in suspend mode. Maybe this is what fixed the crash.

Ichisich commented 2 years ago

Some later test build, but don't know which one.

With suspend mode you mean what exactly, Idling, sleep or hibernating?

RamonUnch commented 2 years ago

With suspend mode you mean what exactly, Idling, sleep or hibernating?

Whenever I the WM_POWERBROADCAST message is sent with the PBT_APMQUERYSUSPEND/PBT_APMRESUMESUSPEND parameters, AltSnap should be enabled/disabled, since 1.48tets13. Any kind of iddle/sleep/standby state should do that. according to the MS doc. If with the 1.47, release build you can get crash it means that this is a fix.

Ichisich commented 2 years ago

As far as I can make an understanding out of Microsoft's documentation, resumesuspend functions as a return to wake-up from sleep:

If the system wakes due to user activity (such as pressing the power button) or if the system detects user interaction at the physical console (such as mouse or keyboard input) after waking unattended, the system first broadcasts the PBT_APMRESUMEAUTOMATIC event, then it broadcasts the PBT_APMRESUMESUSPEND event. In addition, the system turns on the display. Your application should reopen files that it closed when the system entered SLEEP and prepare for user input.

But for querysuspend I could only find that it's deprecated since Vista:

PBT_APMQUERYSUSPEND is available for use in the operating systems specified in the Requirements section. Support for this event was removed in Windows Vista. Use SetThreadExecutionState instead.

I have to check if I can even activate sleep mode in a virtual machine but if so, I could test this more quickly with the 1.47 and a later test build.

RamonUnch commented 2 years ago

I now use the PBT_APMSUSPEND and the PBT_APMRESUMEAUTOMATIC messages that should always be sent, I was reading the doc from an old book, but things are changing. AltSnap1.48test16.zip

Ichisich commented 2 years ago

As it turned out, suspend modes in guest systems are a tricky bunch, but you can initiate them with the host system. In addition, I'm currently letting the release build run some hours in the background on W11 to recheck it's not some low-power state which crashes AltSnap in Windows 11.

I tried the release x64build 1.47 and neither Windows 10 nor 11 crashed AltSnap during or after the wake-up call from suspend. I doubt suspending is the culprit, but to be sure, xzayn should test it on his native system or at least give more conditions.

mikkorantalainen commented 2 years ago

Could it make a difference if mouse is connected via hub integrated in the monitor and the monitor disconnects the hub when in deep powersaving mode? I think it would appear to the OS as mouse connected to hub and the hub being reseted or disconnected while the monitor is in deep powersaving mode. (I'm asking this because I was bitten by LG monitor appearing to disconnect DP connection from the GPU when it entered DPMS off mode and GPU driver / OS not liking the monitor to be disconnected at that moment. My monitor doesn't have USB hub but I wouldn't be too surprised if LG monitors with USB hubs had weird powersaving behavior.)

RamonUnch commented 2 years ago

Interesting insight, but even if you disconnect screen/mouse/keyboard it should not make AltSnap crash. I will try this kind of test plugging/unplugging devices...

mikkorantalainen commented 2 years ago

Yeah, I think if you test all the four possible combinations and find no errors, it should be okay (assuming no races):

  1. disconnect monitor, disconnect mouse, reconnect monitor, reconnect mouse.
  2. disconnect mouse, disconnect monitor, reconnect monitor, reconnect mouse.
  3. disconnect monitor, disconnect mouse, reconnect mouse, reconnect monitor.
  4. disconnect mouse, disconnect monitor, reconnect mouse, reconnect monitor.

And of course, if you have multiple monitors and you disconnect only some of those while the mouse cursor is on that monitor, the Windows will need to move the mouse to another monitor which could affect the software, too. I use just one monitor myself.