X-MBC keeps blocking input in Windows 10

[Lores]

This has been happening from the very beginning of me using this program, first on version 2.19.2 Portable and now on installed 2.20 Beta 10-11: every now and then my input freezes to the point, where all I can do is to move the pointer [which gets me nowhere] and press CTRL+ALT+DEL. That second one gives me ability to navigate to Task Manager where I have to close XMouseButtonControl.exe - usually only having at my disposal TAB, ARROWS and SPACEBAR with only sometime my mouse buttons regaining ability to send input

Sometimes I also have to close HotkeyP - so it would point out to some conflict, right? So having noticed this I later on have test-started running sometimes just X-MBC, but despite this also experienced such freeze-up dozens of times. It also does not make sense: why do I only sometimes need to close HotkeyP? Could something get imprinted to the system: sometimes because of conflict between X-MBC and HotkeyP while sometimes just being [de]activated by X-MBC on its own?

I read this post viewtopic.php?t=4671 and did noticed that this often happens when interacting with Firefox and Thunderbird- but that is probably because recently I have been using them extensively. And what is more important: I do not use wheel in X-MBC [and in those two other mapping programs]

I also, after going through Manual looking for suggestions, starter increasing the value of

Settings > Advanced > Windows Low Level Hook Timeout

to currently 555 ms. But I do not know how far I should go with this, before it [i.e. lack in averting freezes] will start pointing out to some other culprit. Also testing this is annoying as every change of this value requires restart of system


Is there something else I should be taking notice off and something I could try out? I just simply can not seem to spot a pattern in occurrences of those blocking of input and consistency in this ill-behavior

[phil]

The default hook timeout is 20ms. What that means, is that if the hook does not return back to windows in that time, it is REMOVED by Windows silently (and then XMBC or anything else (I suspect HotkeyP also uses hooks) will not work.

I'd have thought that 555ms is more than enough - XMBC is pretty light weight and should never take long to return from the hook (any heavy lifting like simkeys is done in a separate thread so the hook returns asap!).

Usually if something goes wrong in the hook then CTRL+ALT+DEL and cancel fixes it, I pretty much never have to kill XMBC itself (although I also have a global hotkey setup to disable/re-enable XMBC which should also work to reset things if anything gets stuck - again rarely do I have to do that). It could be that there is more chance of conflict with other hooking programs (like HotkeyP - if indeed that uses hooks) but Im surprised you see such problems so often.

It may be useful to capture DEBUG logging when this happens. But debug logging is slow/expensive and as such, turns itself off when XMBC restarts - so it can be tricky to capture at the right moment (before it locks up). You could enable a global hotkey to toggle debug logging ON/OFF and then when it locks up, you could try turning on debug logging (with the hotkey) and I can have a look - see if there is anything usefull/of note in the log - but possibly there wont be as its already gone wrong by then!

Not really sure what else to suggest, as I say, it does not generally happen to me....

[Lores]

[So just to be sure and to not waste time]

I need to select

Settings > Updates & Logging > Enable DEBUG Logging

and click te Apply buttn and then close X-MBC and then reopen it. And when the freeze up will happen again, I need to repet this, because DEBUG will be off? And after dozens of freeze ups I am to send the you the content of XMouseButtonControl.log file?

And maybe I will first try to record those dozens of freezes as they are happening right now - and then add to my Profiles a global shortcut disable and re-anable X-MBC. But how do I do that? And know how to can KILL and RUNMIN it - but turning it ON and OFF? How?

I also came up with this additional questions to which answers I think I should write down after experiencing each freeze-up

During which / what it happened?:
What was the value of Windows Low Level Hook Timeout?:
How long did a session of X-MBC last before freeze-up and what was the workload?:
How long did a session of Windows last before freeze-up and what was the workload?:

Was HotkeyP also running?:
Was AHK also running?:
Was HUION Mini Keydial KD100 also running?:

Was pushing mouse buttons producing clicks in CTRL+ALT+DEL screen?:
Was pushing mouse buttons producing clicks in Task Manager?:
Was pushing mouse buttons producing clicks after closing of X-MBC?:

[phil]

TICK: Settings > Updates & Logging > Enable DEBUG Logging
Hit OK
Hit Apply to close the setup window (not XMBC!).

*** Do not EXIT (quit/terminate) XMBC as that will automatically turn dbeug logging back off (as I explained, because debug logging to too resource heavy).

Then once the freeze happens, you can send me the debug log (which you can access from the Updates & Logging tab on the settings screen).
You can send me the log each time the freeze happens - no need to wait for dozens (although no problem to have more than one too).
BUT: It is also REALLY useful (and important if the log has multiple freezes) if you can make a note of the time (as close to the nearest second as possible) the freeze happens because the debug log is SO verbose, finding anything of interest can be a challenge some time - so having a time window to narrow down the search is quite helpful!

The questions you have suggested answering are all good. The hook timeout wont change (unless you change it AND REBOOT between changes!)
Another question (assuming you setup a global hotkey to toggle enable/disable XMBC)

Code: Select all

Was pushing mouse buttons producing clicks after disabling/enabling of X-MBC (using global hotkey)?:
And perhaps as well (if the answer is no above...) do the global hotkeys still work (does XMBC disable then enable)

note: global hotkeys are only active when the setup window is closed.

[Lores]

Would releasing mouse buttons with a global hotkey originating from X-MBC make sense? Or is it a waste of time nad I should create a global hotkey for disabling X-MBC with keyboard [and with what]?

Sometimes during a freeze-up mouse buttons work; if I am not mistaken almost always in docked window of Winamp


Getting enough data will take me a few days. But already I can see that settings when freeze-ups happen are quite inconsistent

[phil]

Would releasing mouse buttons with a global hotkey originating from X-MBC make sense? Or is it a waste of time nad I should create a global hotkey for disabling X-MBC with keyboard [and with what]?

I'm not exactly sure what you mean by "with a global hotkey originating from XMBC"?
But you can setup (in XMBC) a global hotkey to disable/enable (in effect, reset) XMBC. Thats worth a try - and just see if it works when your buttons freeze - because if it does, it may help narrow down what is going wrong (inside xmbc).

Sometimes during a freeze-up mouse buttons work; if I am not mistaken almost always in docked window of Winamp

So what is frozen if the mouse buttons work? The cursor? The buttons in other windows? other buttons?

And yes, tracking these things down is difficult - its even more difficult to track/fix when you (I) cant reproduce it easily! Has always been my worst nightmare really!

[Lores]

[...]
I'm not exactly sure what you mean by "with a global hotkey originating from XMBC"?

A Button Chording] for LMB and the for RMB a Simulated Keys

Code: Select all

{LMBU}{MMBU}{RMBU}{MB4U}{MB5U}

But you can setup (in XMBC) a global hotkey to disable/enable (in effect, reset) XMBC

I will add such later on

[,,,]
So what is frozen if the mouse buttons work? The cursor?
[...]

The mouse pointer works always

[phil]

[...]
I'm not exactly sure what you mean by "with a global hotkey originating from XMBC"?

A Button Chording for LMB and the for RMB a Simulated Keys

Code: Select all

{LMBU}{MMBU}{RMBU}{MB4U}{MB5U}

Ah, OK, well if that works, that would suggest that the button is being pressed down but not released up (by XMBC) - that obviously shouldn't happen - maybe there is somewhere in XMBC that is failing to release buttons. They should get released if the profile changes, the layer changes, the chord ends, the timed held ends etc.

Of course, if you have done any {LMBD}{RMBD}etc. etc. then it is up to you to ensure that corresponding {LMBU}{RMBU} etc etc. is also sent otherwise its stuck because "you" have told it so.

Regards,
Phil

[Lores]

I do not know if that works, I have just started using this. If I will noce it does not, then I will start using a global one on top of it

And no, I have nowhere in my entire X-MBC an instruction to send anything DOWN. The only pseudo-DOWN's I have are in form of Button Chording

[phil]

And no, I have nowhere in my entire X-MBC an instruction to send anything DOWN. The only pseudo-DOWN's I have are in form of Button Chording

OK - will have to keep an eye on this - maybe there is a problem with the chording missing the release somewhere. If it is a problem, I'd expect it to affect more people that just you - so perhaps when I release 2.20 there will be a flood of similar issues (which will make tracking it down easier I suspect). But then, I'm surprised I haven't noticed it too, so maybe its something setup specific that's triggering the problem (that's more likely) and in which case, a new copy of your settings may be useful, as well as basic instructions to try and reproduce it, so hopefully it will become clearer when it happens. If I can reproduce it, I can trace it through under the debugger and see exactly whats going on - always difficult with random ones though!

[Lores]

Just to let you know, I am sill doing these tests. They will take weeks, as I cannot afford to have my workflow constantly disrupted by having to write down all that info; I can only pick some days. Also I am making tests when I run only HotkeyP, which seems to have the very same issue but occurring much rarer. I also am trying out some AHK scripts for re-releasing mouse buttons up, trying to help HotkeyP and X-MBC

I started using your program having experience problems with the other one and would prefer to use just yours. But If I will be forced then I will use all three methods of expanding usability of mouse. All in all I am trying to help make X-MBC a better program thus taking all those tests seriously

As for the release of version 2.20 [which I also started using] - are there reports of such problems as mines?

[phil]

You are the only one reporting problems in general recently, other than a few issues with scrolling which were introduced in 2.20.
As as far as I know, no one else has noticed this, at least, no one else has reported it yet, but 2.20 has only been out for a few days so if it is a new issue, there is time yet!

I anticipate 2.20.1 will be made soon (maybe the weekend) to fix a couple of serious scrolling regressions and hopefully fix a low level crashes that a couple of people have reported (via the automatic crash bug detector/reporter).

EDIT: And don't worry about taking time. I understand and I also cant spend all my time on XMBC either - I do have a proper job too!

[Lores]

So far I have managed to established three things:


1] Without a doubt this is unfortunately the fault of X-Mouse Button Control

After first run of tests I started then running my system for well over a month without X-MBC being used at all- and as a result I had zero issues of that kind

And the day [the hour!] I went back to using it, the issues came back


2] Apparently this has to do with mouse buttons not being properly handled by individual programs

My current fix makes X-MBC work in some programs ~95% of the time while in others I have to turn it off as it is just unusable. And by work I mean that I no longer have totally disrupting freezes of input forcing me each time to go to Task Manager. most of the times now when a glitch happens it in form of my input being ignored that can be fixed by just repeatingly using the same hotkey or others or a key from keyboard


3] This can be most likely fixed with some script

After trying out few approaches and changing various values in them, currently I use this AHK script

Code: Select all

#Persistent
SetBatchLines, -1

; Initialize state variables
Loop, 8
{
    state[A_Index] := "U"
    prev_state[A_Index] := "U"
}

SetTimer, CheckMouseButtons, 44
Return

CheckMouseButtons:
    hotkey := false
    Loop, 10
    {
        state[A_Index] := GetKeyState("MouseButton" . A_Index)

        ; Check if any hotkey is being held down
        if (state[A_Index] = "D")
        {
            hotkey := true
            break
        }

        ; Check if any mouse button is being pressed
        if (state[A_Index] = "D" and prev_state[A_Index] = "U")
        {
            hotkey := true
            break
        }

        if (state[A_Index] = "U" and prev_state[A_Index] = "D" and !hotkey)
        {
            ; Release the mouse button
            SendInput, {Blind}{Click %A_Index% Up}
            ; Sleep for a short duration to prevent rapid re-pressing of the button
            Sleep, 22
            ; Simulate a mouse move to ensure the release is properly registered
            DllCall("user32\mouse_event", UInt, 0x0001, UInt, 0, Int, 0, UInt, 0, UInt, 0)
        }
        prev_state[A_Index] := state[A_Index]
    }
Return

In it the first Loop is set to 8 because that is has many buttons my mouse has. But despite this I still cannot really use X-Mouse Button Control as in overall my input becomes too glitchy


Hence:

A] Do you still want to see my notes on set and settings when the issue manifested itself during that time period before I struck a better working AHK script?

B] It seems that all I can do now is to test out other AutoHotkey scripts or keep trying to adjust this current one



As for the

You are the only one reporting problems in general recently
[...]
As as far as I know, no one else has noticed this, at least, no one else has reported it yet
[...]

it is because almost no one in general has time, energy and skills to report bugs to developers of programs. People just do not use programs that do not work or do not mind glitches and / or curse at the monitor when experiencing them



[My last tests were done with versions 2.20.4 and then 2.20.5, both portable and being run with privileges]

[phil]

Yes I am still interested in this, and but don't forget XMBC is a hobby and I simply don't have all the time it needs, so, particularly these sorts of issues, can take a while to figure out. I think I have on the odd occasion noticed it myself (never very often and always able to "fix" it by clicking the mouse button again or by CTRL+ALT+DEl and then cancel.

If your seeing it more often, it might make it easier to debug, but ideally I need debug logging enabled when it goes wrong, or now, debugging turned on immediately after it has gone wrong (as this will flush the last 200 lines of debug log which gets cached in memory for this purpose). I need a fairly precise time that it went wrong (to within a few seconds ideally) because tracking this sort of thing down is neigh on impossible without that or without it being easily reproducible under the debugger.

I have a hotkey to toggle debug on and off (like CTRL+SHIFT+D), and when such things happen, now just toggle debugging ON and the OFF again - which will result in the previous 200 debug messages being captured to file - and that should be enough for what we need to look for.

it is because almost no one in general has time, energy and skills to report bugs to developers of programs. People just do not use programs that do not work or do not mind glitches and / or curse at the monitor when experiencing them

I agree to some extent, but I would have expected more than one or two messages about it not working, here or particularly on Discord, especially from the actively loud users, and beta testers who don't normally have a problem reporting errors (there re quite a few of those normally), so I suspect, this is only a significant issue in particular use cases that most people are not hitting (either at all or often enough for it to become something annoying enough to report - a bit like the odd stuck button I see and just release).

EDIT:
Looking at your AHK Script, the fix is essentially to send a mouse button UP message, which means XMBC must has either sent a DOWN and not sent the UP OR it blocked the UP - either is possible - and it may be a particular thing you are doing in XMBC that is making it happen. I will need to look at your profile again (I probable still have it but ir wouldn't do any harm to send me a copy of your latest XMBC settings.)

This is also interesting:

Code: Select all

; Simulate a mouse move to ensure the release is properly registered
DllCall("user32\mouse_event", UInt, 0x0001, UInt, 0, Int, 0, UInt, 0, UInt, 0)

Why on earth would you need to do that - are you saying SendInput is known to not work without sending a mouse_event afterwards (that's curious and concerning - as it may be relevant to XMBC as well as AHK - given they both use SendInput!!)

[Lores]

[...]
I have on the odd occasion noticed it myself (never very often and always able to "fix" it by clicking the mouse button again or by CTRL+ALT+DEl

That used to be me method before I started to combat this with different AHK scripts

[...]
ideally I need debug logging enabled when it goes wrong, or now, debugging turned on immediately after it has gone wrong (as this will flush the last 200 lines of debug log which gets cached in memory for this purpose)

I think, with this AHK running along, I can just induce it like when trying to cop / paste / cut text when in Notepad3 and Thunderbird. So I can probably provide you with a whole session of this glitches

[...]
EDIT:
Looking at your AHK Script
[...]
This is also interesting:

Code: Select all

; Simulate a mouse move to ensure the release is properly registered
DllCall("user32\mouse_event", UInt, 0x0001, UInt, 0, Int, 0, UInt, 0, UInt, 0)

Why on earth would you need to do that
[...]

The more AHK and other solutions I come up with for various things on my system, the more weird / inexplicable cases I stumble upon. This is just to be on the safe side