Xinput leaving a ghost(?) controller

[ponchojohn1234]

Starting ds4windows with an xbox 360 profile will start in Xinput Pad #1, if it's changed to a ds4 profile and then back to xbox 360 the Xinput pad a will move to #2, if this is done with hide ds4 controller enabled, disabling it with move the xinput controller to Xinput Pad #3, It is posible to go back to Pad #2 if hise ds4 controller is enabled again, but it is imposible to go back to #1

[Ryochan7]

It has been a while since I have seen this type of bug appear. DS4Windows does not handle the slot numbers used for XInput but relies on ViGEmBus to handle it. I would have hoped that the extra delay added to virtual device hotplugging would have worked around the driver problem but apparently the problem can still surface.

[Erquint]

Argh, goddangit, I want to confirm either this or #1176 but thing is: I got some symptoms from column A, some from column B and then some happy little BSODs on top of it, very definitely related to this general issue.

Maybe gonna have to create a new one but I'd like to use these two to pinpoint the details first, since I only started using DS4W recently.

[Ryochan7]

Unfortunately, I can only work around so much. I cannot find a consistent way to reproduce the issue so it has remained unsolved. The last time it happened to me, I temporarily switched over to a KB+M profile for a bit before switching back to an Xbox 360 profile. A new virtual Xbox 360 controller was not actually exposed though and I encountered a BSOD when attempting to reboot. During those times, trying to restart the ViGEmBus driver is not possible either as attempting to disable it just freezes the Device Manager.

I have not played around with the driver code in a long time. This type of issue would probably not really surface if it weren't for the virtual device switching that occurs in DS4Windows. I need that feature though particularly with some games that I play using KB+M controls that have problems when a controller is detected at the same time.

[Erquint]

encountered a BSOD when attempting to reboot

Windows tries to restart for about 5 minutes then BSODs with DRIVER POWER STATE FAILURE. That's been the only way I can restart/shutdown ever since I started using DS4W. Granted I only restart after XInput #1 virtual port gets borked. Which is about once a day. This is my life now.

During those times, trying to restart the ViGEmBus driver is not possible either as attempting to disable it just freezes the Device Manager.

Trying to merely refresh ("scan for hardware changes") also made it hang for me.

I'll keep my eye on reproduction steps. So far it seemed to may have been inconclusively related to this kind of scenario as well: DS4 runs out of battery charge, gets connected to a charger (not a PC/PS3), then turned on with PS button and/or turned off with the "special actions" shortcut while charging. One time it disabled the device/driver that way instead though.

[Ryochan7]

It happens that often for you? That stinks. I guess you probably have DS4Windows running in the background at all times.

Even with the problems that I have encountered with ViGEmBus, it still presents me with fewer issues than ScpVBus did back when it was being used in DS4Windows. All of this is still very experimental and it is surprising it works even as well as it does. I would have hoped for more of a community effort on the controller emulation front but each project seems to be its own island. There have been some major rifts that pretty much ensure that true cooperation will likely never happen.

[Erquint]

you probably have DS4Windows running in the background at all times.

In fact I do. Well, this usually happens during gaming breaks with the game still running, so I wouldn't wanna disable the emulation then. But otherwise, I saw no reason to close DS4W at other times either when I can just turn off the controller.

SCP was also prone to this phantom controllers issue, but at least there you could completely flush the entire state of emulation by restarting the service manually. I honestly see this lack of control over irreversible changes (in scope of an OS session) a huge technical drawback where even Windows has no idea how to handle it.

And sorry, can't help with C#. OOP makes me extremely sad every time I dabble in it. And no experience with coding drivers either. Had the SCP dev ever resurface?

[Ryochan7]

Don't know if the Scarlet Crush Productions dev ever published anything after ScpVBus. I don't know the current whereabouts of the dev. ViGEmBus is the only currently maintained driver that I know of for emulating an Xbox 360 controller at the system level.

In theory, it would be possible to make an ScpVBus version of DS4Windows still; it would probably be easier now than when DS4Windows version 1.7 came out. Obviously some features that depend on ViGEmBus functionality would be missing. I have not seen the need and the ScpVBus driver will likely break completely as Windows updates keep getting pushed out. It might be worth a test sometime but I have other projects that need some attention.

[Ryochan7]

Finally doing something I should have done a long time ago. Making a small example program to test out virtual device hotplugging. So far, I can make ViGEmBus skip slot numbers as virtual devices are connected and disconnected quickly in a loop. Now I can experiment and see what might be done to stop this behavior.

[Ryochan7]

Still experimenting. Besides that, the last version of DS4Windows to use ScpVBus was version 1.6.14. Here is a link to the source code for that version. The main classes used to interact with ScpVBus are ScpDevice and X360Device.

https://github.com/Ryochan7/DS4Windows/tree/v1.6.14

https://github.com/Ryochan7/DS4Windows/blob/v1.6.14/DS4Windows/DS4Control/ScpDevice.cs https://github.com/Ryochan7/DS4Windows/blob/v1.6.14/DS4Windows/DS4Control/X360Device.cs

[Ryochan7]

I have not had any issues since implementing the longer device delay. I think there is a different issue regarding this particular problem but I cannot remember which one it was.

Either way, I am adding ScpVBus integration to the TODO list so this issue will act as the placeholder for the Work Board. It will be an experimental build with no official support. This issue report can stay open until that task is complete.

[Ryochan7]

Need to test it more but I have made a test ScpVBus implementation. It probably took only around 1 hour to write the code. It is confirmed to work in HTML5 Gamepad Tester at least.

[Ryochan7]

Got the code uploaded. I will get around to packaging a build in a bit.

https://github.com/Ryochan7/DS4Windows/tree/scpvbus_draft

[Ryochan7]

Here is a packaged version.

DS4Windows_ScpVBus_20200415.7z https://drive.google.com/file/d/1aoiA57ExOPC5zBRrCE5r3dQpq02If21e/view?usp=sharing

Be aware that you will have to install ScpVBus yourself if you don't have it installed already.

https://github.com/Ryochan7/DS4Windows/raw/v1.6.14/extras/Virtual%20Bus%20Driver.zip

[Erquint]

Thank you. I'm gonna try this version now. But which features am I to expect not working with it? Safe to migrate profiles?

[Ryochan7]

The obvious missing feature would be DS4 emulation support. Other than that, I don't think the 360 Steering Wheel routine will work as intended since old code is being used. Most other actions and options should work about the same. Profiles should not be affected.

Also, make sure to disable the Check for DS4Windows Updates at Startup option in the Settings tab.

[Erquint]

make sure to disable the Check for DS4Windows Updates at Startup

Sure did. It's working nominally. Now it's just time to wait and see if it fails at all and whether it fails safe when it does.

[Ryochan7]

Made an updated ScpVBus build from DS4Windows version 2.1. This will likely be the last ScpVBus compatible build.

https://drive.google.com/file/d/1rOiYEAMzwZgcUxQgzKCB6jkVzdjutQtn/view?usp=sharing

[SpiralCut]

I'm also having this issue. I can try testing if you have anything you need confirmed.

As of now, the SCP build above also does not seem to fix the issue (the xbox controllers are still getting removed when I disconnect from BT and on reconnect they are in a non-readable slot). Some other things I've noticed

• If I stop and start DS4Windows service from within the app (without actually quiting) it seems to fix the controller slot issue
• I don't know if this helps, but my event tracking program (eventghost) is actually detecting three controllers connecting everytime I connect with DS4Windows. Of these I've noticed the second HID entry will sometimes have different IDs (In the part after IG_00# and before the actual controller code). The data from Eventghost is below--First entry is the DS4 connecting, the other two are from DS4Windows as far as I can tell.:

System.DeviceAttached [u'\\\\?\\HID#{00001124-0000-1000-8000-00805f9b34fb}_VID&0002054c_PID&09cc#8&1d36f825&4&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}'] System.DeviceAttached [u'\\\\?\\USB#VID_045E&PID_028E#0000001#{a5dcbf10-6530-11d2-901f-00c04fb951ed}'] System.DeviceAttached [u'\\\\?\\HID#VID_045E&PID_028E&IG_00#3&7306911&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}']

One of the other entries I've had for the second HID: System.DeviceAttached [u'\\\\?\\HID#VID_045E&PID_028E&IG_01#3&37ba56f2&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}']

[Ryochan7]

At least the first DeviceAttached portion makes sense. When DS4Windows would tell ViGEmBus to connect a virtual Xbox 360 controller, Windows would see the virtual Xbox 360 controller as two devices. One would be the native XInput controller and the other would be the exposed HID DirectInput controller (the one with IG_* in the path). The last entry I think would imply that an XInput controller was already using slot 1 so the new device will use slot 2; not really sure if that is what it means though.

Unfortunately, I doubt the newest changes upcoming for version 2.1.1 would really help with this matter. I will mention that I have not been able to produce the slot skipping problem lately.

[Erquint]

Honestly, didn't have much time playing lately. (And one of stick potentiometers in my DS4 started heavily failing, which I'm waiting for a replacement for from Coronavirus Central...) Of those few days that I did though, the previous ScpVBus version you posted never failed to work as intended. I didn't even have to restart it like I had to do sometimes with the original SCP project. I do much prefer having it just work in a plain way to randomly stopping and BSODs. Thank you!

[SpiralCut]

I can confirm 2.1.1 does not fix the slot issue for me.

Is it possible to add an option to prevent DS4Windows from removing any virtual Xbox 360 controllers that have been added since the DS4system started whenever the ds4 is disconnected from bluetooth? This would solve all of my issues.

[Ryochan7]

Tried once before but failed. The most recent release has some changes that should make the process easier. Need to give it another shot sometime.

[Ryochan7]

Also, there are no logs posted here. Which version of the ViGEmBus driver are you using? I only support the current release of 1.16.112.0. I know some people have posted logs showing ViGEmBus 1.14.3.0 being used.

[SpiralCut]

I'm using ViGEmBus 1.16.112.0.
Here are some logs. The first one (ds4windows_log.txt) I just did a quick restart of ds4windows, connected the controller, then disconnected and reconnected. After the reconnect I was assigned the second Xbox controller slot. ds4windows_log.txt Logs.zip

Here's also the logs from eventghost for that same process shown in ds4windows_log.txt. I connect, disconnect, connect again, open joy2key to see how the controller assignment is working, disconnect etc. Eventghost Log.txt

[Ryochan7]

The DS4Windows log shows that adding any extra device plugin delay won't affect things. It is already set at 500 ms for plugin and unplug events. Also, I am testing with my old physical 360 controller and it looks like the IG number does not increment sequentially although the proper slot LED is lit.

[Ryochan7]

Current attempt at persistent output device support. It is already further along than my previous attempt. It currently assigns a permanent Xbox 360 controller upon program startup. Some GUI and config file work will have to be developed later.

https://github.com/Ryochan7/DS4Windows/tree/persistent_dev_draft

[Ryochan7]

I still have no real direction regarding this potential feature. I don't know what I want. There is a somewhat working version now in the persistent_dev_draft branch.

[Ryochan7]

Added a couple of minor fixes and tweaks. One minor point is that the list now displays if an output device is being used by an input controller. At this point, the only idea that I have left is adding some kind of preferred slot setting in profiles. I need to check the originally proposed use cases for this feature as I might not have a direct use for it myself.

[SpiralCut]

Thank you for all the work you are putting into this.

So my use case for this would be something like 1) Create permanent virtual xbox360 controllers that appear always attached to the system. This could either be permanently and persistently across reboots (if possible) or from the time the matched DS4 (see below) is first connected for that boot until after the DS4windows service is stopped/system rebooted. 2) Allow some way of assigning a real device (say by mac address) to the virtual xbox360 controller so that the same DS4 will always be the same x360 ID even if the DS4 is disconnected & reconnected. This setting should be persistent so even if the machine reboots or DS4windows is restarted the DS4 can be consistently connected to the same virtual xbox360 controller

This would have two benefits, first it would allow the DS4 to always connect to the controller in a given slot and second, you could launch games without thinking about whether the controller was connected because it always would be.

I like the plug/unplug you've added as well, this would work as an option to detach any of the xbox360 controllers that have been added.

[Ryochan7]

One thing to take into consideration is that specifying slot numbers would require having multiple virtual controllers plugged in at all times. Currently the program will attempt to find the first relevant output slot available. It is a two step process with the first step looking for an existing inactive virtual controller of a certain type and then the routine will attempt to find any unused Dynamic slot.

One extra feature that I wanted was allowing plugging and unplugging of permanently assigned output slots. That feature would definitely be necessary when playing some games like Warhammer 40K: Space Marine; that game throttles the mouse sensitivity if it detects a controller present even when unused.

One more thing, I might have unintentionally resolved a timing issue that would have left an output controller plugged in after swapping output controller types. That fix would not resolve the problem in the OP but it would resolve a major bug nonetheless.

[dkolb]

Just to add on: If you have Windows 8/10 Fast Startup enabled you can run into this issue consistently. I have DS4Windows setup to run at startup as a task. Shutting down the computer with the controller still connected results in some state being saved to the hibernation file. Whether it's DS4Windows or ViGEmBus I couldn't tell you.

Upon powering on the computer again, DS4Windows "finds" my controller, plugs it in, and then errors out and says it's powered off or needs to be charged. At this point, if I turn on the controller it ends up in the next XInput slot and games like FFXIV will show two 360 controllers.

Disabling fast startup resolves the issue. I have a SSD so it's not really a big deal for me. But worthwhile for anyone else searching through the issues with the same problem.

[Ryusennin]

For people with a PS4: a sure way to force DS4W to use a new slot is to unplug the gamepad from the USB (the pad will switch off) and then turn your PS4 on with the pad via Bluetooth. After that, power down the PS4 (the pad will turn off), then plug it back in the PC via USB. It will be attributed to a new slot.

I can reproduce this every time.

[Erquint]

Sadly, I can confirm my issue is not related to ViGEmBus. I've been using the SCP version @Ryochan7 built and shared since.

Today I ran into the same issue, complete with Device Manager symptoms and a driver power state failure BSOD on trying to restart. The only difference being that a new XInput slot was not being occupied on top of the phantom ("live" but inactive) one. Restarting the bus (which I presume the "Start"/"Stop" button in GUI is for) did nothing. Never had anything close to a driver failure happen with the original SCP project.

This has to mean that the root of the issue is in DS4W itself. 😔

P. S. Again, it happened while the controller was passively charging and, presumably, gone offline having finished charging. Still can't say for sure how prominent this mode is as a symptom.

[Ryochan7]

This reminds me, here is a new release of the ScpVBus build. It is based on version 2.1.2. Although it incorporates some minor changes from up to commit b18f70706114bb2340cda140844e634e0f7f5b15.

DS4Windows_ScpVBus_20200607.7z: https://drive.google.com/file/d/1yhaEhlZWV9pGgJjQuJJR7yOKtpnRx9Om/view?usp=sharing

[Erquint]

Got to play more lately and kept having this issue again about once every other day with extensive use.

Device HID\VID_045E&PID_028E&IG_00\3&1a7937a&0&0000 was not migrated due to partial or ambiguous match.

Last Device Instance Id: USB\VID_054C&PID_09CC&MI_03\7&11790c4e&1&0003
Class Guid: {745a17a0-74d3-11d0-b6fe-00a0c90f57da}
Location Path: 
Migration Rank: 0xF000FFFFFFFFF120
Present: false
Status: 0xC0000719

That's the last event on the stuck virtual device. Definitely wasn't charging this time and was powered off manually. Didn't note if the device borked while powering off, on or inbetween.

Heard the persistent feature is online in the latest release. It's not the most authentic experience in terms of emulation, but it's sure to help avoid this issue. (But also devalue fixing it.) And since this issue isn't limited to ViGeMBus, there's no point to deny the features provided by the mainstream version. I was, however, postponing updates since my experience with profile migration wasn't as smooth as I hoped last time.

Well, I'm off to trigger another (hopefully last) BSOD again by restarting and then get the latest version set up.

[dkolb]

I just remembered I still needed to comment here. :-D The persistently connected outputs feature resolved this issue for me.

[SpiralCut]

Just tried updating and the persistently connected inputs work great for me as well!

[Erquint]

Yep, as very much expected, having no device migration occurring at all prevented device migration-related mishaps. Not to mention that it naturally also helps sidestep issues where some games have difficulty recognizing a controller if you went away and it disconnected during a session. There are however some rare games that rely on hotplugging, but hopefully I won't have to run into those.

[Ryochan7]

Released a new ScpVBus test build. It is based on version 2.1.8 as stated in the filename.

https://github.com/Ryochan7/DS4Windows/releases/download/v2.1.8/DS4Windows_ScpVBus_2.1.8_x64.7z

[Ryochan7]

Just going to post an update taken from a different post.

Been testing this type of scenario with ViGEmBus 1.17.333.0 and I have not run into this problem yet. The latest ViGEmBus driver has fixed a couple of other issues that I have encountered with previous releases. I made a small test program when testing the initial migration and even something like accessing the User index of a controller was extremely flawed with the 1.16.112.0 driver.

https://gitlab.com/ryochan7/vigemplugtest

https://github.com/ViGEm/ViGEmBus/releases/tag/setup-v1.17.333

[dkolb]

I've been using the permanent output slots as a workaround for this issue which comes with it's own hilarious drawbacks[1]. Looking at the change log version 2.2.0 says:

• Allow passthru of Touchpad and Gyro to output virtual DS4. Requires ViGEmBus 1.17.333.0 and Windows 10

Does this mean if I'm running version 2.2.0 or greater I have ViGEmBus 1.17.333.0, that I need to follow the above instructions to install it myself, or that I can just do an uninstall/reinstall to get the new version of ViGEmBus?

[1]: Windows 10 apparently believes a plugged in XBox Controller is reason enough to never go to sleep or turn on the screensaver.

[dkolb]

Just wanted to come back and mention that since my last comment I've been running with Fast Startup and can regularly get the error message on boot "Controller 1 was removed or lost connection." However, upon powering up the controller it reconnects to the first XInput slot.

So TL;DR: The issue seems fixed for me after a reinstall of the ViGEmBus driver.

[Mircosfot]

i have still the Problem with 2 controllers. reinstalled vigemBus withot succsess. when i use DInput the problem is away but not all games outthere suppots DInput. Gamepadtester shows 2 controllers up: playin some games with it is nearly impossible.

[Mircosfot]

EDIT: the 05c4 is my, the 09cc is a virtual one?! This happens everytime when i connect my dual/sense/shock with DS4Windows. Hideninja shows strange stuff, someone with a solution? cant play games with DS4Windows because i have 2 inputs at the same time

[mika-n]

05c4 is either physical DS4 revision1 gamepad or ViGem created virtual DS4 gamepad. 09cc is a physical DS4 revision2 gamepad. So, you probably have DS4 rev2 gamepad (the 09cc is the physical one and 05c4 the virtual gamepad created in DS4Windows/Vigem in dualshock4 output mode).

If you use HidGuardian then nowadays the recommended alternative is HidHide (successor of HidGuardian tool). See the following page for more details how to uninstall HidGuardian in a safe manner (if hidGuardian is uninstalled in a wrong way then you may end up without kbd and mouse support). Reboot PC after uninstallation. Then follow instructions to install and setup HidHide tool. https://vigem.org/projects/HidHide/Simple-Setup-Guide/

[Mircosfot]

hidehide is showing up the two listet gamecontrollers, the SCE one is my and the SIE is the virtual i think. i set a mark on the SIE- one and it doesnt work, is still online. games are still not playablr for me

[Mircosfot]

EDIT: in Steam there is only one controller up in the device manager and all is working very well with steamInput. Steam is the best for me. the vigembus is rly strange and sux.

[Softernet]

Mircosfot DS4Window->Settings->"Hide DS4 Controller" doesn't work?

[Ryusennin]

1. You need to whitelist HidHideClient.exe as well.
2. You're hiding the wrong controller. You must block your physical Sony Wireless Controller and unblock your HID-compliant controller (which should actually appear as "Xbox 360 for Windows" if you have whitelisted HidHide).

"Hide DS4 Controller" in DS4Windows is obsolete and shouldn't be used with HidHide/HidGuardian.

[mika-n]

@Softernet You seem to have a bit of misunderstanding how "double controller" issue is supposed to be solved by HidHide tool. You have not configured HidHide correctly. The basic principal is as follows: Hide the PHYSICAL gamepad in HidHide from ALL applications except from DS4Windows app

• Choose the PHYSICAL gamepad in Devices tab page to be hidden from apps, but leave the virtual output gamepad visible (ie. don't tick the virtual gamepad).
• Tick only DS4Windows in the Applications tab page to whitelist DS4Windows to see the hidden physical gamepad, all other apps won't see the gamepad you have ticked in Devices tab page and that's how it should be.

Now you have a setup where only DS4Windows app sees the physical gamepad, reads those physical gamepad inputs, does all sort of remap rules and macros you have set in DS4Windows profile and then outputs those gamepad events to the virtual output gamepad (either in xbox360 mode or dualshock4 mode as set in DS4Windows profile options). Games won't see the physical gamepad, so you no longer have "double controller" issue, games can see only the virtual output gamepad.

https://github.com/Ryochan7/DS4Windows/wiki/Exclusive-Mode-(Hide-DS4-Controller-config-option)-tips-and-issues https://vigem.org/projects/HidHide/Simple-Setup-Guide/