DsHidMini player slot changing after unknown duration of time

Hey! Sorry to bring this here. I have researched this issue to heck and back trying to find a solution myself and am just having no luck. I would like to point out that this issue also existed in SCPToolkit.

For some reason, the player number the controller is assigned doesn't like to stay the same. Let me explain. On a fresh boot, the first controller is set to player one as expected. It will stay there for the duration that it's plugged in. However, if it's plugged in for more than a few hours, it will be destined to change slots upon the next connection. So, if the controller is connected as player one for around a few hours, disconnected, and then reconnected, it'll be assigned as player two according to xinput.

I've tried uninstalling all drivers in relation. Temporary HID controller drivers. Xbox emulation controller drivers. Everything except the Nefarious Bus have I uninstalled. No matter what though, it will always remain player two until reboot. It also never progresses further. It will only go as far as player two. Additionally, plugging in an actual xbox controller will have that controller assign as player one while DsHidMini is stuck as player two.

This is with the DS4Windows method, keep in mind. However it's confirmed that the issue is not due to said program. This is aided by the fact that this issue existed in SCPToolkit. I am looking for any solution here if one can be provided. I'm at my witts end because a few games need you to be player one in order to use a controller. According to device manager, USBdev, and Printers and Devices, there are no controllers detected while the controller is unplugged, so it's not a controller being detected that doesn't exist. HIDHide also did not help as only one controller is detected as it's connected and none when it's not.

That's all the info I can provide other than the system being Windows 10. Again, would seriously appreciate any help!

Sounds like some app like Nvidia's stellar GeForce Experience is keeping a handle open to XInput DLL, that typically causes the observed issues, no matter if SCP or any other solution.

This is a shot in the dark since you need proper tools to diagnose this but you can try if this is enabled, disable it and see if it's fixed:

Cheers

I'm willing to use the proper tools if necessary to figure this out. It's driving me bonkers, all things considered. Sadly, I already had the Nvidia Overlay disabled. Never found any utility from the thing.

I can't edit posts after a specific duration of time, so I apologize for the double post. What tools would I need to diagnose the issue? I had meant to ask.

@re11ding you can use Sysinternals Process Explorer to search for processes holding an open handle to any XInput* DLL and kill it and try to see if that fixes it.

EDIT: here's a guide.

@nefarius Thanks for the advice. I have done so, but the issue remains unresolved. There were some Nvidia handles and DLLs being used but once they were gone, once all the results disappeared from Process Explorer, the issue persists. Any other ideas?

@re11ding not really I'm afraid

@nefarius No worries. I decided to check a bit further myself. I didn't mention it, but Steam was also handling xinput as well. I shrugged it off because closing steam and then plugging it in didn't fix it. Not only that, but if steam was the issue, you would think this problem would be more heavily reported. However, it made me think about something. There was a possibility that Steam always had a grip on the controller hence why after so long, it sort of does the player switch. This theory was backed up by the fact that you could execute certain functions by holding the middle button of the controller and pressing certain things. For example, the quick disconnect shortcut always opened the magnifier tool and I didn't know why.

This was apparently Steam's doing. I have now hid the controller from Steam using the in-steam controller settings and am awaiting results to see if it moves to player 2 at any point. Not only that, but unlike Nvidia (when the overlay is disabled anyway), who uses a 1.9 variant of the DLL, Steam uses the same DLL as most other programs do, the 1.4 DLL, adding to the suspicion. I'll post with an update if it ends up being the solution! Hopefully it's the cause!

Nope, no dice. It looked promising but it just did it today. Oh well, go figure.