Mapped mouse buttons stop working after a while.

[phil]

That's weird, 10000m (10 seconds?!) is certainly not the Windows default (at least not since Windows 7) - it is normally 200ms (on a fresh install).
10 seconds is an eternity. the whole point of the timeout is to prevent applications from locking up the mouse (or anything else hooked into) which would certainly be noticeable if it failed to respond (move) within 10 seconds!

As such, I would imagine Windows would either ignored 10 seconds completely (and use the default 200ms) or, it if not, and it accepts 10 seconds, then the problem you are facing is very unlikely to be the hook timing out!

However, if disabling XMBC then re-enabling it (via the context menu or global hotkey) OR exiting and restarting makes a difference, then that does point towards the hook being removed. As I said to heading0803, some debug log might be useful particularly when it stops working (you would probably have to setup a global hotkey to toggle debug ON when it stops working for that to be useful).

[Dan23437]

I opened the X-Mouse settings and that's what was written there. I never played with those settings and did a clean install two days ago. Although I don't have the problem at the moment, I kept a log file before it happened. How do I share it? The forum doesn't allow me to share a file hosting link.

[phil]

You need 5 posts to share files here (or by private message I think). You now have that so you should now be able to upload/add attachments.
Please note that the normal log file will be useless here - it needs to be the debug log.

To enable debug logging (you don't want to do this all the time as its very verbose and slows things down, and it turns off automatically when XMBC restarts) you can turn it on in Settings -> Updates and Logging -> Enable debug logging.

You can also setup a global hotkey to toggle debug logging on and off. This is great because you can leave debug logging OFF until the problem happens. Then toggle on debug logging and the last 200 lines of debug messages will be flushed to the log file (it buffers them in memory temporarily). That way you don't need debugging on, but when you want it, it will have remembered the last messages and you can toggle it on, off and then send me the log file.

This can be done in Settings -> Hotkeys. First enable global hotkeys, then on the Other hotkeys tab choose a unique key combination for to toggle debug logging.

ToggleDebugLogging.png

Hit OK and apply and your good to go. When the problem happens, just hit the hotkey (and then try pressing all the mouse buttons/tilt for a bit before turning it off again. Make a note of the time too as it helps narrow things down, then send me the log file.

[Dan23437]

Please find it attached.

[Dan23437]

I have just checked and the functions stopped again. It takes a lot longer for the buttons to lose their functionality after uninstalling the updates, though.

[phil]

OK well some initial impressions...
1. the mouse hook timeout changed, on 08th November 2024 from 200ms to 10000ms (10 seconds). Not by XMBC but by something else.
Sometimes other software like Virtual Machine stuff (VMWare/VirtualBox) increase that timeout value so I guess something like that.

So it has been 10000ms since then until you changed it to 1000ms.

2. When you have toggled debug (today at about 20:14:21), the last 200 debug messages span from 19:08:52 through to 21:31:39. That's a long time with not much happening - did your computer go to sleep or standby by any chance or was locked? I thought XMBC logged sleep events so perhaps not. Maybe you just left it without moving/clicking the mouse much.

Either way, I don't see any button clicks. I do see some movement that is invoking the "check if the profile has changed as the mouse moves".

3. In that time period, 19:08 through 21:31, particularly between 20:14 through 21:30, there is a big gap with no log messages. Im seeing the odd
CThreadLock::TryEnterCS Skipping 'WM_MOUSEMOVE' (TID: 000083B4) because the thread is locked by 'ProcessMouseOverTimerProc'

I don't know if that's relevant, but I will have to check. Its also possible that some of the debug logging from the mouse hook is not making it into the memory buffer (perhaps to prevent it filling that too quickly) so it may be a bit of a red herring.
The fact that the mouse hook is still working at 21:31:40 as evidenced by

Code: Select all

14-08-2025 21:31:40.851> MouseHookLLProc: MouseHookData: Msg=0x0201 (WM_LBUTTONDOWN), X=2516, Y=0, Data=0x00000000, Flags=0x00000000, Time=99238500, Info=0x0, Ptr=0x2007AF, Layer=0
14-08-2025 21:31:40.851> Translating Left Button Down Key state 0x0: Action 40 [** No Change (Don't intercept) **]
14-08-2025 21:31:40.851> MouseHookLLProc: Passing original mouse message 0x00000201 through....

Suggests that the hook did NOT timeout and is still responding - so chasing hook timeouts appears to be futile. That's something at least!
What I dont see in there anywhere is the tilt (horizontal wheel). I thought that's what was not working. Can you confirm/remind be of that?
If Im right, either you didnt press the wheel left/right or XMBC is not seeing it. There are several possibilities for that... Y

1. You didn't press it while debug was enabled.
2. Something else has intercepted it before XMBC gets a look in (some other software has also hooked the mouse).
3. Your mouse or mouse driver is not sending the tilt messages.

I would lean towards option 2 initially. The problem will be finding what. Any other mouse/keyboard utilities installed/running? Its quite possible if there is another mouse hook, it may be "swallowing" just the tilt messages so XMBC sees the button messages but not the tilt messages.

Is there any obvious (or even not obvious) pattern to the failure? Is it always after using a particular piece of software? or completely random (or always after about 10 minutes etc.)

It would be useful doing debug logging while it is working also... (you can delete/rename the old log if you want, as I no longer need messages back to 2024 .

If some other software has messed with the hook timeout, then maybe that software is also messing with the hooks.
The reason I asked you to disable/re-enable XMBC is that actually removes the mouse hook, then re-installs it. Due to the nature of mouse hooks, the most recently one installed is called first. So that can block the message being passed to the next hook. If some other program is installing a mouse hook, it will take precedence over XMBC and be able to swallow the tilt messages without XMBC every seeing them. The disadvantage of mouse hooks is that there is very little informaiton about what is going on - Windows has no notifications or callbacks to say some hook has been added, removed or changed (nor by what) which might make this very difficult to troubleshoot further.

I'm looking for WM_MOUSEWHEEL (scroll) and WM_MOUSEHWHEEL horizontal scroll (tilt) - assuming that's what is not working.
All I can see from this log is that XMBC didn't get any of those messages when it had "broken".
Also, next time it breaks, WHILE debug logging is enabled, can you disable and then re-enable XMBC - see if the mouse buttons start working again.
You can disable/enable XMBC via hotkey (like the toggle debug) and/or from the right click context menu on the XMBC icon in the tray - just right click and select disable then right click and select enable). This forces XMBC to reinstall the mouse hook (thus will be the top/most recent hook).

Sorry for the long winded message - I hope it makes some sense (and gives an appreciation as to how complex this could be to figure out).

EDIT: Reworded some bits and pieces!

[Dan23437]

I enabled the debug mode today for about 20 seconds and pressed all the buttons a few times before uploading the log file here. I have also been using the internet for a few hours actively.

I exported the active process list and asked AI what could potentially affect my mouse and here is the response:

Likely to affect mouse behavior directly

X-Mouse Button Control (XMouseButtonControl.exe): Remaps buttons, adds per-app profiles, scroll/window focus tweaks. Disable or exit it to test conflicts. (I have been using this for a long time. Since the issue appeared within the last 10 days.


Logi Options+ (logioptionsplus_agent.exe, logioptionsplus_appbroker.exe, logioptionsplus_updater.exe): Logitech driver suite that can remap buttons, gestures, DPI, and app-specific actions. Ensure only one Logitech stack is installed and test with it closed.


I uninstalled this before, restarted the pc but the problem didn't go away.

Mouse Server / Luminati Mouse Server (MouseServer.exe, Mouse Server Luminati.exe): Turns phone into a wireless mouse/keyboard. These inject input at a low level and can cause lag, ghost moves, or clicks; stop these services to test.

I doubt it's the reason. It also doesn't have any mouse remapping feature. I have also changed the wireless mouse usb port to observe if that's the case. Here is a log file attached while the app is working. By the way, it's not only your app that has the issue. I installed the AutoHotkey app, and it has the same problem too.

[phil]

OK, So when it is working, in that log, I see the expected WM_MOUSEHWHEEL messages. So that would suggest that when it is not working, but XMBC is still seeing the left/right button messages and mouse movement messages (as seen the the previous log) that *something* is either causing the messages to not be sent OR is swallowing them in a hook before XMBC's hook.

The test of that would be, next time it stops working, turn on debug logging, then disable and re-enable XMBC and press the tilt wheel. If it works after disable/re-enable then that suggests another hook is interfering, and re-installing the XMBC hook "fixes it" by taking a higher priority.

As for Logitech Options+... Hummm I have had trouble with Logitech software before where the tilt (horizontal) wheel and/or buttons 4 and 5 are not set "correctly" by default so it does not send the tilt messages like a normal mouse does. However, after it has been corrected, it never (previously) randomly stopped working. Whilst the majority of my mice (across 5 machines are Logitech devices, I tend to avoid the Logitech software where possible (its not always possible). But every Logitech mouse seems to have different software. There was one in particular that messed with the tilt more than others, but I cant remember off the top of my head exactly what the software was or how the issues presented itself. I think its what ever came with the G604 Im running on my development desktop (and surface when docked - both now on Win 11 24H2). The various Logitech software all seems to behave differently, and these days they have a habit of updating themselves (so could introduce new problems silently) - so I can rule it out. I know on my dev desktop, I used to run the software that came with the G604 (was it Logi Options+ - I think so but am not 100% sure) and I'm also not sure I ever re-installed it after rebuilding and switching to Win11 I'll try and have a look tomorrow if I get a moment between/after work!

I also doubt that Mouse Server would impact it (but it wouldn't do any harm to temporarily disable it to check I guess). I dont know how it works, but if its driving the mouse rather than watching it, I doubt its relevant. If it were the other way round, to share your mouse to another computer, I'd be far more suspicious.

Unfortunately though, I fear there is little more I can do other than offer such troubleshooting suggestions as above. Working out what is interfering is clearly not easy, and if Windows Updates were a general the issue, I'd expect far more than two people complaining - although it may be too early to rule that out completely...

[Dan23437]

Thank you very much for your time. If I find a permanent solution or the root cause of the issue, I will give you an update.

[Hyjynx]

Hi Phil,

Just wanted to chime in that I'm also experiencing this issue since the beginning of the week.

I have a Ploopy Classic and I use Xmouse to map button 4 as right click. Nothing fancy.

As with the other users, when I disable/enable Xmouse, I get regular functionality for a little bit and then button 4 no longer functions as right click. I'd say the timing is somewhere between 15 and 30 minutes after enabling Xmouse.

I did run advanced debugging for a bit this morning so my log file should have this happening at least twice.

[phil]

OK the more logs the better... I wish this was happening here, that would make things so much easier to debug!
Ive removed you from the new users group so you should be able to attach your log (or PM it to me).

Finding that common something that has changed will probably be the key... Especially if your using 2.20.5 which has been stable for over 2 years.

[Hyjynx]

Thanks Phil. Hopefully I did the logging correctly.

[phil]

OK plenty of debug logging in there - but I'm not seeing any obvious particular problem. The hook seems to be seeing the mouse messages all the way through, but maybe there are gaps that are tricky to spot at first glance.
Can you help narrow down the time when the problem actually happened?

EDIT: Unless it went wrong when debug logging was not enabled?

[Hyjynx]

I enabled advanced debug logging at 8:28. There is no communication from 8:53 to 9:07 despite the fact that I was definitely at my computer and using the mouse at that time. I was in a Teams call from 8:59 until 9:31 and I was looking up information for the call . I'm guessing the logging picked up at 9:07 because I discovered that button 4 wasn't doing the right click thing anymore, and I disable/enabled Xmouse.

I'm not sure why the logging would have stopped from 8:53 to 9:07. Button 4 stopped working sometime between 8:28 and 9:07.

[phil]

OK thanks, yeh I missed that gap...

Wow no logging AT ALL in that time - that's definitely a little bit odd, because even if the hook is removed, there is still other threads going on (I'd expect) although it is possible they don't log anything unless triggered by mouse actions (which wont have been seen if the hook has gone). More so, I cant see any log regarding disabling/re-enabling XMBC, just opening the setup window at 9:07. Even if the hook stopped responding, I'd expect some logging, but maybe not. The release version does have less logging than the beta version (because in beta I often need more information)... I will have to do some research, and maybe add some sort of heartbeat log "still here - honest" lol.

But it does look like *maybe* the hook was removed or was not receiving any mouse messages, especially if disable/enabled "fixed" it - even if that didn't log anything (which is odd).

I can see you have tried different hook timeouts... and currently is is 1000ms so not a lot of point suggesting you play around with that. I wonder if MS have recently changed the rules here.. Might have to study the KB release notes to figure that out - because its probably too recent to have been talked about much.