Dualsense Vigem Plugin Failed more often than not.

[Kilrua]

Describe the bug
A clear and concise description of what the bug is.

When I start DS4 Windows it always finds my DualSense controller (even when its not on sometimes it's still in the control panel) but will give the "ViGEm Device Plugin Failed. Likely an internal ViGEmBus problem." error more often than not. Then it says DS4Windows Stopped and I'm unable to click start again (sometimes it still says stop). Sometimes it stops but still connects an Xbox 360 controller, while also giving a frozen start button until I restart the app.

To Reproduce
Steps to reproduce the behavior:

1. Go to "Start DS4Windows'
2. See error

Expected behavior
A clear and concise description of what you expected to happen.
I expect the controller to connect to DS4Windows and work.

Screenshots and Logs
If applicable, add screenshots to help explain your problem. Also, please add the most
log file (ds4windows_log.txt) from the Logs folder in your DS4Windows config folder.

2023-06-16 20:05:46.8739|INFO|DS4Windows version 3.2.11
2023-06-16 20:05:46.8739|INFO|DS4Windows exe file: DS4Windows.exe
2023-06-16 20:05:46.8739|INFO|DS4Windows Assembly Architecture: x64
2023-06-16 20:05:46.8739|INFO|OS Version: Microsoft Windows NT 10.0.19045.0
2023-06-16 20:05:46.8739|INFO|OS Product Name: Windows 10 Pro
ds4windows_log.txt

2023-06-16 20:05:46.8739|INFO|OS Release ID: 2009
2023-06-16 20:05:46.8739|INFO|System Architecture: x64
2023-06-16 20:05:46.8739|INFO|Logger created
2023-06-16 20:05:46.9464|INFO|LinkedProfiles.xml can't be found.
2023-06-16 20:05:47.6289|INFO|Running as User
2023-06-16 20:05:47.6289|INFO|HidHide control device found
2023-06-16 20:05:48.6559|INFO|Starting...
2023-06-16 20:05:50.6568|INFO|Using output KB+M handler: FakerInput 0.1.0.0
2023-06-16 20:05:50.6568|INFO|Connection to ViGEmBus 1.21.442.0 established
2023-06-16 20:05:50.6568|INFO|Searching for controllers...
2023-06-16 20:05:50.6568|INFO|Using Shared Mode
2023-06-16 20:05:50.7862|INFO|Found Controller: 7C:66:EF:48:08:B0 (BT) (DualSense).
2023-06-16 20:05:51.9384|WARN|ViGEm Device Plugin Failed. Likely an internal ViGEmBus problem. Closing connection. If the issue persists, please close DS4Windows and then reboot Windows.
2023-06-16 20:05:51.9384|INFO|Stopping Virtual Output Controllers
2023-06-16 20:05:51.9384|INFO|Closing connection to ViGEmBus
2023-06-16 20:05:51.9959|INFO|Stopping DS4 Input Controllers
2023-06-16 20:05:51.9959|INFO|Stopped DS4Windows

Desktop (please complete the following information):

• Controller Make and Model: Sony DualSense (CFI-ZCT1W)
• OS: [e.g. Windows 10 Pro 22H2 Build 19045.3086]
• DS4Windows Version 3.2.11, Also tried 3.0.13

Additional context
Coming back to DS4Windows after trying GlosC/GlosSi steam input for a while and uninstalling it. I've tried uninstalling & reinstalling FakerInput, HidHide, Vigem (As well as older versions), DualSense drivers, DS4Windows and disconnecting/reconnecting DualSense to bluetooth. Stop steam, razer, and any other apps that produce a xinput.dll from starting.

[Kilrua]

I also notice when the controller works, it generally will work until I restart the computer or disconnect and reconnect the controller.

[Ryusennin]

Can you reproduce the issue via USB?

[Kilrua]

Yes, I tried a USB connection and still had the same issues.
EDIT here's a verbose USB log if that helps.
ds4windows_log Verbose.txt

[Kilrua]

DS4 version 2.1.23 seems to be working best. Haven't had it freeze, crash, or fail. Only thing I miss from current version is Faker Input and mapping the mic button.

[Ryochan7]

Another problem with the ViGEm client library code? I am pretty sure DS4Windows did not try to catch ViGEm client errors in those earlier versions but controller emulation would fail regardless. Not sure which version of the ViGEm client library would have been bundled with that version of DS4Windows but it was probably at least two library versions prior. Pretty sure the current ViGEm library would not work with that old version of DS4Windows so that cannot be used to test the scenario.

[Kilrua]

Another problem with the ViGEm client library code? I am pretty sure DS4Windows did not try to catch ViGEm client errors in those earlier versions but controller emulation would fail regardless. Not sure which version of the ViGEm client library would have been bundled with that version of DS4Windows but it was probably at least two library versions prior. Pretty sure the current ViGEm library would not work with that old version of DS4Windows so that cannot be used to test the scenario.

I'm not sure if the ViGEm client library code is the same as the program but I'm running ViGEm Bus Driver 1.21.442, the current version listed on github. Is there a way I can check or update my client library code?

[Ryochan7]

I would have to look at the Git history to find out which version of the client library was included. The bundled versions use the template 1.0.0.0 version number in the base project rather than the actual number added for the official releases. Too bad I still need to include custom libraries for performance improvements and because the vanilla library still loses rumble events which can cause infinite rumble.

Also, suspend used to be the way to replicate this problem when I had a hard time getting my system to suspend. Adjusting some BIOS settings has finally allowed Windows to suspend properly on my PC but resuming has not caused the error to pop up. Need a different way to replicate the problem consistently before it can possibly be addressed.

[Ryochan7]

Looks like the library being used in DS4Windows 2.1.23 dates back to 2020/06/07. That was prior to ViGEmBus 1.17.333.0 which added the extended DS4 report API for Touchpad and Gyro data mapping.

https://github.com/Ryochan7/DS4Windows/commits/master/DS4Windows/libs/x64/Nefarius.ViGEm.Client

Likely old source:
https://github.com/Ryochan7/ViGEm.NET/tree/ryochan_api_changes
https://github.com/Ryochan7/ViGEmClient/tree/notification_queue

[Kilrua]

What did you change in the BIOS? Maybe that would help me?

[Ryochan7]

For some reason, Windows would only suspend correctly on my PC when Suspend Mode is set to S1 (POS) only on my motherboard bios. IIRC, Fedora has no problems suspending just using the default Auto option. Windows has previously worked with the Auto suspend mode so I do not know why the mode had to be changed now.

It might not make a difference when it comes to this problem though. If you are brave, maybe you can try the same problem in the test mapper. It is a bit better structured and it does not check for that exception that DS4Windows does. IIRC, the logs generated with that program are currently stored in the %APPDATA%\DS4Test\Logs folder.

https://github.com/Ryochan7/DS4MapperTest/releases/tag/v0.0.11

[Masamune3210]

Maybe make sure your chipset drivers are up to date in Windows? They are heavily involved in Power State handovers

[Ryochan7]

Just thinking about it, I believe I have run across this problem with the other mappers as well; it has happened maybe a couple of times in the past. Again, that exception is not handled so the mapper will do its job except no virtual controller will actually be present. In another issue, checking the error code given seems to indicate that some runtime exception within the ViGEmClient C++ code is at play (maybe a reference is not set) that is out of my control.

[Ryochan7]

Related issue #3023 (comment)

Turns out the main problem was a ViGEmBus driver issue. Although the problem would mostly occur while trying to resume from sleep, this issue has popped up while starting the app normally. It looks like this issue should mostly (cannot guarantee completely) be fixed in the next DS4Windows release.

[Ryochan7]

At least the root cause was found after all this time. Done what I can do regarding the problem without being able to distribute a fixed driver.