KB5086672: New XInput1_4.dll

[Valkirie]

Hey @Nemirtingas, it appears Windows has replaced the XInput1_4.dll with its latest update: KB5086672. Likely to accommodate some new controller logic. Replacing the dll with OpenXInput dll will cause a crash loop from explorer.exe. I have no clue how hard it'd be to check for what has changed.

[Nemirtingas]

Hi, if you can provide me the new Xinput dll that would be nice. I'm stuck on Win10 cause I won't install that shitty Win11 and probably will switch to a Linux flavor at some point 😄

[Valkirie]

Here you go: System32.zip. FYI, I realized something had changed because the IOCTL_XUSB_GET_LED_STATE logic we'd use to figure out the userIndex of a controller from its DevicePath would now always return 0...

[Nemirtingas]

GET_LED_STATE shouldn't be used anymore, its here for retro-compat with XBox 360 led protocol. ;)

[Valkirie]

GET_LED_STATE shouldn't be used anymore, its here for retro-compat with XBox 360 led protocol. ;)

Indeed, but that's the only method I'm aware of that can provide a userIndex from a device path. With it gone, I was planning to replace the system32 xinput1_4.dll with an edited openXinput one to get the path from userIndex and vice versa.

[Nemirtingas]

I think GetBaseBusInformation can be used for that purpose. The device handle is also available with OpenXInputGetDeviceHandle. Get the native handle and use it to find the device path should be easy.

[Valkirie]

I think GetBaseBusInformation can be used for that purpose. The device handle is also available with OpenXInputGetDeviceHandle. Get the native handle and use it to find the device path should be easy.

I believe GetBaseBusInformation can only return VendorID and ProductID. I can't find anything online on XInputGetDeviceHandle. Is this undocumented ?

[Nemirtingas]

Its not in XInput, its from OpenXinput https://github.com/Nemirtingas/OpenXinput/tree/feature/get-device-handle, base bus also returns some extra bytes, maybe they can be used to find the real device path

[Valkirie]

Its not in XInput, its from OpenXinput https://github.com/Nemirtingas/OpenXinput/tree/feature/get-device-handle, base bus also returns some extra bytes, maybe they can be used to find the real device path

So I'd ship my application HC with the OpenXInput dll and use it to get the handle from a userIndex and compare it against my handle : https://github.com/Valkirie/HandheldCompanion/blob/51759a7096a80279234e1eea13847d387adeb2ad/HandheldCompanion/Managers/DeviceManager.cs#L772 ? Correct ?

[Nemirtingas]

You can try. I don't know if handles are unique for the same device or not. I though there was a way to find the device path from the handle but it seems not.

[Nemirtingas]

Another way would be to use the XInput hooks. https://github.com/Nemirtingas/OpenXinput/blob/OpenXinput1_4/src/OpenXinput.cpp#L2186. Thoses hooks are the real one in XInput.dll, so you can also use them on Microsoft's XInput

[Messenils]

Dont know if i am useful, but had a quick compare between files. changes i could see were a new ordinal 109. And existing 8 and 101 were changed. Propably more changes

[Nemirtingas]

Hmmm, I don't detect any change in 8 and 101. Only 109 has been added and a lot of stuff regarding wil (whats that?)

[Nemirtingas]

This branch should match the new dll:
https://github.com/Nemirtingas/OpenXinput/tree/feature/xinput-1-4-win11

But strangely enough, the new function XInputGetSystemButtons gets my controller share button where the XInput.dll you provided does not for some reason. After some debug, the driver doesn't even return the bExtraButtons (https://github.com/Nemirtingas/OpenXinput/blob/feature/xinput-1-4-win11/src/OpenXinput.cpp#L871) value, where my implementation does?

That quite makes no sense to me ;), both dlls rely on the driver's IOCTL, so there might be something blocking that in the new dll.

[Valkirie]

This branch should match the new dll:
https://github.com/Nemirtingas/OpenXinput/tree/feature/xinput-1-4-win11

But strangely enough, the new function XInputGetSystemButtons gets my controller share button where the XInput.dll you provided does not for some reason. After some debug, the driver doesn't even return the bExtraButtons (https://github.com/Nemirtingas/OpenXinput/blob/feature/xinput-1-4-win11/src/OpenXinput.cpp#L871) value, where my implementation does?

That quite makes no sense to me ;), both dlls rely on the driver's IOCTL, so there might be something blocking that in the new dll.

That was fast. Thanks again. Next challenge, that's likely unrelated to XInput dll, (i'll look into the branche), is the input capture logic Microsoft implemented with Fullscreen Experience (FSE) and GameBar. When any of them is summoned it capture all inputs, preventing any background app from reading controllers.

[Valkirie]

While looking into the XInput dll update, could you indeed notice anything related to gameinput redirection, background input ? I'm still trying to understand how input capture/redirection works when GameBar is summoned.