MaxTo loses Hotkeys, restarting helps

[matthiash82]

Recently this problem started and I'm fairly sure that it started to happen when I upgraded to 2.1.0-beta1. Basically, every now and then, Hotkeys stop working but regions otherwise work as normal.

I have 2 HotKeys: Windows+PageDown for moving a window left, and Windows+PageUp for moving right.

When starting my computer, 1/4 times everything works, but 3/4 regions will work but HotKeys not. If I close and restart MaxTo it starts working. Then during the day, suddently the HotKeys will stop working again and a restart of the application will again fix the problem. I see no pattern for when the HotKeys stop working.

Not sure how I can troubleshoot this any further.

[rustamsh]

The same issue with me. Checked the logs and found this:

2020-05-12 18:34:32 [Server@2.1.0.644] [Warning] [MaxTo.Core.Communication.NamedPipeServerManager] Lost connection to "bbc9a917-2819-421a-8bea-5a2bc21fefd4"
System.IO.IOException: Pipe is broken.
   at System.IO.Pipes.PipeStream.WinIOError(Int32 errorCode)
   at System.IO.Pipes.PipeStream.BeginWriteCore(Byte[] buffer, Int32 offset, Int32 count, AsyncCallback callback, Object state)
   at System.IO.Stream.<>c.<BeginEndWriteAsync>b__53_0(Stream stream, ReadWriteParameters args, AsyncCallback callback, Object state)
   at System.Threading.Tasks.TaskFactory`1.FromAsyncTrim[TInstance,TArgs](TInstance thisRef, TArgs args, Func`5 beginMethod, Func`3 endMethod)
   at System.IO.Stream.BeginEndWriteAsync(Byte[] buffer, Int32 offset, Int32 count)
   at System.IO.Stream.WriteAsync(Byte[] buffer, Int32 offset, Int32 count, CancellationToken cancellationToken)
   at MaxTo.Core.Communication.NamedPipeServer.<Send>d__26.MoveNext()

[vegardlarsen]

Thanks for reporting this. I am looking into this. I assume this goes for all hotkeys; not just the ones you mentioned above @matthiash82?

@rustamsh The warning you listed happens every time a client disconnects; e.g. when MaxTo is closing down (or in the case where a subprocess crashes). It is normally nothing to worry about by itself.

My guess as to what is happening here, is that there is a problem with our hotkey implementation. It is implemented as a low-level keyboard hook (that is how we are able to override Windows' default hotkeys); and Windows has pretty strict tolerance limits for how quickly we need to respond. My guess is that MaxTo has been too slow to respond in one instance, and our hook is therefore unloaded.

edit: changed the word "driver" to "hook", which is the correct terminology.

[rustamsh]

@vegardlarsen on my pc when this issue appears all hotkeys don't work, restarting the app helps.

But that issue didn't appear on my other machine (that new machine is more powerful and I installed the beta version from scratch), so it could be either something related to settings with an old maxto app or machine configuration. I am just guessing

[matthiash82]

Is it possible that the problem (keyboard driver?) is caused by idling? While I can’t say for sure it feels like the problem never appears while I’m working, but it’s a good bet that it won’t work when I get back from for example lunch.

[vegardlarsen]

I don't think so. It only listens for events that happen when a key is pressed or released (KEY_UP and KEY_DOWN events), and has to determine (very quickly, I might add, to prevent any input lag) if it should treat the current key combination as a hotkey or not.

I have had a look at some improvements in this event listener that may improve things in the next beta.

[matthiash82]

The last few days I have been trying to be more observant and I’ve definitely lost hot keys during normal work. But every time the computer felt sluggish and unresponsive for a second or two.

[matthiash82]

I have managed to reproduce the problem semi-consistently. Whenever I connect to our VPN (Cisco AnyConnect) my computer will input lag for a few seconds (probably totally unrelated to MaxTo). If I press any keys during this lag I can expect MaxTo to lose its HotKeys; if I do not they still work afterwards.

[vegardlarsen]

@matthiash82 Very interesting. It could be that Cisco AnyConnect installs its own low-level keyboard hook, but I can't quite see what purpose that would have in a pure VPN solution? Does it do remote desktop as well (in which case the keyboard hook could be used to forward keypresses to the remote computer)?

[matthiash82]

@vegardlarsen My point was more that it more confirms your theory(?) that the root cause is your device driver not responding quickly enough (due to system lag). As far as I know, Cisco AnyConnect does not install any low-level keyboard hooks. It might do remote desktops, but I use it as a pure VPN solution.

And regardless, Cisco AnyConnect was more a tool for me to somewhat consistently reproduce the problem, but I have still lost HotKeys even when I did not use it.

[vegardlarsen]

You are right. I will have to experiment with this more closely.

[vegardlarsen]

I am 99% sure that I found the cause of this issue. When connecting to a VPN (or other network status events), MaxTo would try to get the name of the network you connected to. MaxTo uses the network name to allow filtering the network triggers. This caused an access violation (I don't know why exactly), which would crash the MaxTo.Core process immediately, with just a trace in the logs saying the MaxTo.Server process lost contact with one of the other processes.

I have fixed this for beta.2 by dropping support for filtering on network names (you can still filter on adapter name).

Can you confirm that MaxTo.Core.exe is running immediately before you connect to a VPN, and is no longer running a few seconds afterwards @matthiash82? That would give me greater confidence that I solved this issue.

Also, this is probably the same issue as #519.

[matthiash82]

@vegardlarsen Yes, I can confirm that MaxTo.Core.exe is running before I connect to VPN, and then afterwards it closes within a few seconds :) Before I even managed to catch in Task Manager that its status changed to Suspended. Great find!

[vegardlarsen]

Great! Beta.2 was released last night, and if you restart MaxTo twice you should have it... :)

[matthiash82]

Thanks! Seems like my first comment that I could reproduce it semi-consistently when I connect to VPN must have been a lie :) must have been “consistently” ...