Intermittently stops interacting with windows

[dsjstc]

After a couple of days of use, AltSnap will stop interacting with windows: my I can no longer resize or drag with a hotkey+drag.

The main process does not crash, and the tray icon remains interactive, but I don't get back window interaction until I exit and restart.

I've attached my .ini, and an ad.log (created with a debug version of 1.63 run through gdb32) that spans an instance of this behaviour.
adlog_and_ini.zip

[RamonUnch]

but I don't get back window interaction until I exit and restart.

You need to restart? enabling/disabling is not sufficient?

From the log I do not see anything suspicious. I suspect Win11 does no like a hook to hold for too long and maybe silently disables the whole program from hooking.
Also gdb32 generates its own trance, you would need to include the content of the console for extra information, however in this case given there is no crash we do not care about gdb32 results.

[dsjstc]

You need to restart? enabling/disabling is not sufficient?

I have been assuming that left-clicking the tray icon disables/enables. If so, then it is not sufficient.

[brentk]

Not sure if this is the same issue, but I've noticed similar behavior. However, what I've also noticed (in what I'm experiencing) is that it seems to affect exclusively windows that have been snapped.

Whenever the bug presents itself, the vast majority of windows that have been snapped will stop responding alt-drags. For example, if I snap something in the the corner, I can't altdrag unless I first drag it normally by the title bar any distance, then it will start responding again. Dis/re-enabling altsnap by left clicking on it in the task bar will not fix the issue, you need to close it and reopen it. Once you do that it starts behaving correctly again, and I haven't noticed a specific timeframe or action that causes it to stop working again.

PS: I say "vast majority of windows that have been snapped..." since there are odd outliers. Like when I was testing this my VS2022 window would not respond to altdrags when snapped to a corner, but would when snapped to a halfscreen. Outside of this, for the most part it seemed pretty reliable way to trigger the issue. I've since restarted altsnap to confirm that fixes it, so it's a waiting game for it to stop working again.

[airtonix]

Not sure if this is the same issue, but I've noticed similar behavior. However, what I've also noticed (in what I'm experiencing) is that it seems to affect exclusively windows that have been snapped.

This started happening to me too, but only for windows that have been maximised.

[hgklmena]

Similar issue here. Windows 11 Version 23H2 (Build 22631.4317).
I use AltSnap to adjust browser and eMail window to fill the complete screen at about 60:40 ratio, as Windows is silly enough to add borders where the desktop is visible after every sleep mode. When a window has been snapped, I can't use Alt-drag for it any more. Unsnapped windows still work. Alt+wheel menu still works for snapped windows.

Restarting AltSnap makes no difference. I need to close and restart the application of the snapped window to make Alt-drag work again.

[hgklmena]

Found out that this only happens, if Windows 11 starts in fast boot mode. When I disable fast boot in energy settings or after a system restart with updates, this bug does not show.