XMBC sends two keys (original + my custom) after upgrading computer?

[Mojo89]

XMBC Version: v2.20.5
Installed or Portable version: Installed.
Windows Version: Windows 11
Mouse Information: Zowie FK1-C
Relevant Computer Information:
Motherboard: ASUS TUF Gaming X870-Plus. (AM5)
CPU: AMD Ryzen 7 7800X3D.
RAM: 64GB Kingston DDR5 6400MHz CL32.
Did the problem occur after an upgrade of XMBC?: No.
Did the problem occur after a Windows update/upgrade?: No. After new PC build.
How long have you used XMBC?: Many years before this. At least since 2019.
What language and keyboard layout do you use in Windows?: Swedish/Swedish.

Description of the problem:
I've been using XMBC for years to map Mouse Button 5 (the front thumb side button on my Zowie) to (during){F13} and use it as a Push-to-Talk in Discord.
After upgrading from my old computer (AM4. Mobo: ASUS X570-A Pro. CPU: Ryzen 9 3900x), XMBC does no longer seem to be able to block Original Mouse Input, or something.
I think I have set it up exactly as I did before. But no matter what I try, "Mouse 5 + F13" is sent into Discord, where you set the Hotkey, instead of the expected only F13.
Scroll lock option is off. Confirmed scroll lock is indeed off before trying via windows on-screen keyboard or whatever it is called.

Oh, I have tried other combinations too. It always sends "original mouse input + my custom key", never only "my custom key".

Any word about XMBC not working with AM5 maybe?
Any settings I might have accidentally touched that you can think of?
What can I check next?

I have tried googling this for two days now and haven't found an answer. So here I am, looking for answers at the source.
Thank you for otherwise great software.

[phil]

Well, Ive had no problems on my AM5 9950x3D - so I don't think so. I am on the latest beta mind (not that it should be any different in this respect).
Two things to try...
1. Turn on debug logging for a bit, press the button in discord (where its not working) and send me a copy of the log file. That at least should tell me what XMBC is doing.

2. Save your whole settings (use the save profile button) and send it to me in a private message so I can try it on my system and check it works here.
That will at least reproduce your entire settings - so if there is something wrong I may be able to spot it!

[Mojo89]

Two things to try...
1. Turn on debug logging for a bit, press the button in discord (where its not working) and send me a copy of the log file. That at least should tell me what XMBC is doing.

2. Save your whole settings (use the save profile button) and send it to me in a private message so I can try it on my system and check it works here.
That will at least reproduce your entire settings - so if there is something wrong I may be able to spot it!

Sent a pm!

[Mojo89]

I just tried AutoHotKey. It has the same issue.
Thumb mouse buttons just won't f**king stop sending on this PC lmao
Very weird issue.

Update: I decided to get a new mouse (Logitech G Pro) and hope their Hub software solves this, since it changes the raw output of the mouse.

[phil]

I'd be interested to see if the new mouse fixes it.. Ive had many mouse buttons fail over time, and some failures can result in rapid repeating clicks when you think you made only one (switch bounce). Used to happen a lot on old joysticks too back in the 80'/90's lol... Probably still does on cheap console controllers too - physics and all that

Naturally I have a tonne of mice here spanning many years - some have similar problems with buttons (some I have replaced the micro-switches myself as I like the mouse and a decent replacement was no longer available). I did try and write some code to detect/ignore such clicks but it is not particularly reliable as every device/dodgy switch behaves differently

Let me know if the different mouse makes any difference (or not).

[Mojo89]

The issue persist on the new mouse and on my partners pc as well.
The new mouse have the onboard ability to remap though, so I can use that. But I hate that mouse lol. It's loud and plastic, and the scroll wheel is already failing after two months (Logitech G PRO X SUPERLIGHT 2).

Here is what information I have collected, if anyone else encounters this.

My goal:
Use Zowie FK1-C (which has no on-board memory or software for remapping) front thumb button (Mouse 5 / XButton2) as F13 for Discord push-to-talk specifically without triggering browser “Back” or "Forward".

The Problem:
This setup worked perfectly for years on my old computer. XMBC would block the original MB5 input and only send F13. On my new computer, the blocking function no longer works. When I press the button, the system (especially Discord) receives both MB5 and F13.

New PC Specs (Problem Occurs):
Windows 11.
Motherboard: ASUS TUF Gaming X870-Plus. (AM5)
CPU: AMD Ryzen 7 7800X3D.

Old PC Specs (Worked Perfectly):
Windows 11.
Motherboard: ASUS X570-A Pro. (AM4)
CPU: Ryzen 9 3900X.

After hours of googling, this is what I could collect online. Not sure how correct this information is.

This behavior comes from a change in how Windows 11 + modern AMD USB drivers (AM5 chipsets especially) handle HID input events.
Older systems allowed software-level hooks (like XMBC and AutoHotKey) to suppress or “block” the original mouse event before it reached the system. On new AM5 boards, that suppression layer is bypassed by modern low-latency USB polling and input stack isolation.
AMD’s X870/X670 USB controller drivers use a newer asynchronous interrupt model.
Tools like XMBC and AHK can still see the event but cannot reliably swallow it.
Result: both MB5 and F13 are emitted.
This is not caused by the mouse, Discord, or XMBC config, it’s a low-level driver behavior difference.

Chatgpt found this information (so take it with a big scoop of salt).

Discord detects raw HID events (WM_INPUT) from real devices. It listens passively—it doesn’t intercept or cancel them. When a side button is pressed:
Discord sees XBUTTON1 or XBUTTON2 directly from the hardware.
Windows and your browser also see Browser_Back or Browser_Forward.
Discord does not consume or suppress the event, so both respond.
Software remaps (AHK, XMBC) inject synthetic events after the OS processes the hardware one, which Discord ignores for security.

G Hub (for example) functions differently:
It communicates with Logitech device firmware through the USB HID driver.
When you rebind a button, the firmware or Logitech driver intercepts the input before Windows receives it.
The driver either sends a replacement signal (F13) or nothing at all.
As a result, only the remapped output reaches applications—Browser_Forward never leaves the driver.

Therefore, Discord reacts only to true hardware or driver-level signals.
G Hub remapping works because it occurs before Windows or Discord handle input.
Tools like AHK or XMBC fail because they operate after the OS, too late to stop or alter Discord’s raw input capture.

[phil]

That description you found online is interesting. What is the source (out of interest)?

As I said, I do have an AM5 (9950X3D) based system and I haven't noticed this - but I confess I don't use that system as much as others that are not AM5 based. All my devices are running Windows 11 though, I would have expected to see this when I do rarely use my AM5 system (as I do for ALL XMBC development), I will have to have another, more careful, look particularly in Discord which is installed on my systems, but I haven't remapped to anything other than copy/paste (which I have not noticed a problem with yet).

I could understand some games etc. showing this behaviour, but I wouldn't have expected desktop software like discord to be using any lower level mouse messages - I've not seen that before (although there is no reason they couldn't generally its not worth the effort. If that is indeed the problem, then there wont be anything that can be done, because XMBC and/or AutoHotkey can not interfere with those low level messages, only the mouse hooks. It would require a signed mouse driver (or mouse filter driver) to intercept the lower level stuff, which would be outside of user space where these programs run. Driver signing is not something the average software dev/hobbyist can get into because of the financial constraints and registered company requirements placed which make it difficult for any hobbyist to get into (intentionally to protect the Windows kernel from bad actors - although they often do have the funds to accomplish their malicious means unfortunately, so Im not sure how effective such requirements are!!).

[Mojo89]

They talk about that stuff here https://ph3at.github.io/posts/Windows-Input/
But I really don't know how reliably it applies to this specific situation, so take it with a grain of salt.

Update:
I got myself an Endgame Gear XM2 mouse, since I hated the Logitech. I read that Endgame have the same robust feel as my favourite Zowie, and a "configuration tool" that might let me rebind mouse4/xbutton1/browser_forward to F13.
Plugged it in. Downloaded their tool thing.
First, I couldn't even bind it to F13, because their very shallow "configuration tool" does not allow F13 directly. I then used AutoHotKey to cheat the tool and get F13 in there. But that didn't work. I was at the same stage as with my Zowie mouse. It sent Mouse4+F13 in Discord. Big sigh.

But, since I could actually rebind mouse4 to some (more common) keyboard keys in their software, I used this to my advantage.
I discovered that if I set Mouse4 to ' in their configuration tool, then use AutoHotKey to rebind ' to F13, it works.
So the problem is juryrigged/somewhat solved.
I have a good robust mouse, and my PTT is working with F13.
Sadly I cannot use XMBC for this though (still sends MB4+F13).

If only these "luxury" mice companies (Zowie and Endgame Gear) would invest in some robust remapping software.

This obsession of mine is getting ridiculous, so now im gonna enjoy some Battlefield 6 with the boys and try to move on from this I think.
Sorry for probably being a pain in the ass.