DS4Windows now always opens in Shared Mode despite Running As Administrator

[p3rcy]

An issue where DS4Windows now runs in Shared Mode despite Running as Administrator, which usually engaged HidGuardian in order to gain exclusive control.

I feel like I might be missing something but this issue has only arisen since the version 2.0 update.

Cheers!

[p3rcy]

Here is a log export, can't get it to run in exclusive mode for the life of me:

12/29/2019 01:51:20: DS4Windows version 2.0.1 12/29/2019 01:51:21: Starting... 12/29/2019 01:51:21: Connection to ViGEmBus 1.16.112.0 established 12/29/2019 01:51:21: Searching for controllers... 12/29/2019 01:51:21: Using Shared Mode 12/29/2019 01:51:40: Stopping X360 Controllers 12/29/2019 01:51:40: Closing connection to ViGEmBus 12/29/2019 01:51:40: Stopping DS4 Controllers 12/29/2019 01:51:40: Stopped DS4Windows 12/29/2019 01:51:40: Starting... 12/29/2019 01:51:40: Connection to ViGEmBus 1.16.112.0 established 12/29/2019 01:51:40: Searching for controllers... 12/29/2019 01:51:40: Using Shared Mode

[Ryusennin]

DS4Windows runs in shared mode if HidGuardian is installed. It's always been the case. It will only run in exclusive mode if you enable "Hide DS4 Controller" (which you shouldn't if using HidGuardian).

[p3rcy]

I think I may have just gotten confused. Thanks for the heads up. It seems to be working normally then!

[Chrisnetika]

"Hide DS4 Controller" is only way to get exclusive mode to work. Some kind of Hid-Cerberus Whitelister service may work as it does for InputMapper but tbh it not needed if so i imagine it low priority thing being "Hide DS4 Controller" works.

[Chrisnetika]

But also like to note in case the developers are interest as I do not wanna bog up this ticket is I done some tests on my own to kinda pinpoint why the hidguard helper is not working right, that I am willing to share and help work out if developers are interested :).

[mika-n]

If "Hide DS4 Controller" option in DS4Windows works then it can be used to hide the physical controller. However, it is very sensitive to other apps and non-DS4Windows related things can easily break that functionality.

For example FIFA goes woooooow if the gamepad is disconnected and re-connected in the middle of the game when "Hide DS4 Controller" (=exclusive mode) is used. The problem is that by the time gamepad is disconnected and this way exclusive access to the gamepad is momentarily lost, running FIFA game process "steals" a connection to the physical controller right away when the gamepad is re-connected. This is enough to prevent DS4Windows to re-enable exclusive mode. Only way to recover from this is to close FIFA and re-connect the gamepad while FIFA is not running (or any other similar app which steals a gamepad connection automagically when a new gamepad is connected).

HidGuardian driver tool and HidGuardianHelper app in DS4Windows is an alternative way to hide the physical controller and because HidGuardian is a kernel level driver it can do much more than user mode DS4Windows app can do. For example, the disconnect/re-connect or "those apps stealing a connection" are not a problem for HidGuardian driver.

Anyway. Use whatever mechanism works for you (no need to use both HideDS4Controller option and HidGuardian driver at the same time). If you see warning messages about "Hide DS4 Controller" option failed to acquire an exclusive access then please refer to the following web page. There is not much DS4Windows app itself can do in those problematic cases, except recommending to switch over to use HidGuardian tool if nothing else helps. https://github.com/Ryochan7/DS4Windows/wiki/Exclusive-Mode-(Hide-DS4-Controller-config-option)-tips-and-issues

Anyway. This explains why you see "Shared mode" message in DS4Windows logfile when you use HidGuardian tool to hide the physical gamepad HID device. DS4Windows app itself doesn't know what HidGuardian driver does so from the app perspective the gamepad connection is opened in "Shared mode" even when HidGuardian does the trick behind the scene (it AffectedDevices and Whitelisted HidG sysreg entries are properly setup).

[Chrisnetika]

Yea that has totally happened to me before in my game (Final Fantasy XIV) where I removed and reconnected my controller and even tho exclusive mode is on the game got in the middle and borked it.How I have it now with hidguardian and hidcerberus set right I totally able to firewall my gamepad to where the actual device does not show up in controllers.It been working thus far as a safety net.If anyone is curious this is what I use https://www.autohotkey.com/boards/viewtopic.php?t=34890 Oddly it works with everything but DS4Windows. I disabled InputMappers whitelister server and used that tool on InputMapper and it worked... just with DS4Windows.. no dice. Like I said I am willing to help iron out the kinks in that whenever the development team ready to cross that bridge.Thank you all again for your insights!

[Ryusennin]

"Hide DS4 Controller" is only way to get exclusive mode to work.

You're mistaken. While it can still do the job for many old games, the built-in DS4Windows exclusive mode has become unreliable over the years. HidGuardian is the surest way to get exclusive mode with DS4Windows, as long as the driver is installed and the AffectedDevices registry key properly configured.

In my experience, the WhiteKnight server is a mess and not recommended.

[Ryochan7]

There might be a need to specify more states than a bool can convey. As it is, DS4Windows will only attempt to open the DS4 in Exclusive Mode if the "Hide DS4 Controller" option is enabled. Shared mode is used by default.

Although HidGuardian is typically used to give one application access to a device, it is still possible for multiple programs that are compatible with HidGuardian to open a device together. Opening the device with the Exclusive flag would still be required to force it.

[mika-n]

How I have it now with hidguardian and hidcerberus set right I totally able to firewall my gamepad where the actual device does not show up in controllers.It been working thus far as a safety net.If >anyone is curious this is what I use https://www.autohotkey.com/boards/viewtopic.php?t=34890 Oddly it works with everything but DS4Windows.

HidCerberus would work with DS4Windows for sure, but if you use it just with DS4Windows then there is no need to use HidCerberus/WhiteKnight at all.

DS4Windows comes with HidGuardHelper.exe app which takes care of updating Whitelist sysreg entry when DS4Windows process is launched (ie. HidGuardHelper adds process id of DS4Windows to Whitelist sysreg entry).

Only thing left is to pre-setup AffectedDevices sysreg entry, but it can be done either manually (one time thing) or using HidGuardienTestInstaller tool to install HidGuardian and to setup default AffectedDevices sysreg entries for DS4 v1 and v2 gamepads identifiers. If you have custom 3rd party gamepads then HID path of those gamepads need to be added manually to AffectedDevices sysreg entry (different value per gamepad brands).

https://github.com/Ryochan7/DS4Windows/wiki/DS4Windows-and-HIDGuardian-Install-and-Setup-Guide#hidguardian-test-installer

[Chrisnetika]

I am no means a developer or even a professonal at this stuff, i'm just end user that been trying so hard to get something to work that according to everyone should been as easy as pie.So far only thing that remotely has been working is the things I shouldn't use or "is a mess".I have stated before I tried setup ds4 and everything on a system with a fresh install of windows 10 and have not been able to get it to work... that in itself should peak your interest why.You can say this and that the surest way to do it but I beg to differ it has not been so.I am no idiot, i been working with computers for better part of my life so I do know bit more than avg user so that why I gone out my way to try different things.I am not trying sound like an ass here, I been offering to help in some way figure out what is the issue and instead of any1 asking why it not working on fresh install of windows you are starting to batter down only things that HAS worked for me so far.I am 100% certain my hidguardian installation is correct, my gamepad is being hidden from non whitelisted apps including windows joystick interface.Only issue now is getting DS4 app whitelisted.So far what I been using has been able to whitelist everything including inputmapper but DS4 and curious what makes it so diff where it doesn't. Sorry for the long comment, it is obvious i am not only person having issue with it.. perhaps even more that doesn't even come on github that do as well.

[Ryochan7]

HidCerberus is not used directly by DS4Windows due to weird performance concerns with interfacing with it and running the service in general. The first part would probably not be a problem anymore but the second problem is beyond my control. I would have to test it again to make sure that my old findings are still valid.

I have always just used the template AffectedDevices list from my own installer. I had thought of making a small manager similar to HIDer(?) but I keep finding other tasks and I don't use HidGuardian regularly.

[Ryochan7]

Sorry for the long comment, it is obvious i am not only person having issue with it.. perhaps even more that doesn't even come on github that do as well.

I have made it a policy a long time ago that I am mainly concerned if it works for myself; this is still largely a scratch your own itch project. I try to help others when I can but people have to give me a way to reproduce a problem in order for something to be addressed by myself. Other problems that I do not encounter will require a pull request to fix. This would be a higher priority issue if I regularly used HidGuardian.

As it is now, HidGuardHelper is doing its job with 2.0.1 when HidGuardian is installed. I have not tested the other tools in a while but looking at the source code for HidGuardHelper shows that it actually nukes all the currently defined whitelist keys before creating its own; there are very likely to be conflicts when using other tools. That was needed because many tools don't use volatile keys so stray whitelist entries will likely still exist in the registry especially if a program crashes. DS4Windows uses volatile keys for the worst case scenario so a reboot will nuke any stray keys.

A process check should have been added to the program a while ago but it never did.

[Ryochan7]

I ended up making a couple of changes to the HidGuardHelper app that should make it to the next DS4Windows release. Firstly, the stale key purge pass was not working anyway. A new version has been made that corrects the original issue. Also, a process check has been added to the routine so no whitelist entry that is associated with an existing process will be deleted.

I still need to try out some of the other HidGuardian related tools again. The only one I have checked out again is HIDer.

https://github.com/samehb/HIDer

Also, have you verified that HidGuardHelper.exe is running while DS4Windows is running? Besides looking in Task Manager for the process, I would also recommend that you install Process Explorer as well. Check the properites for the value of "Command line" to make sure it is using the current DS4Windows PID.

https://docs.microsoft.com/en-us/sysinternals/downloads/process-explorer

[Ryochan7]

Downloaded WhiteKnight and HidCerberus again. The HidCerberus install nuked my old AffectedDevices registry value. Anyway, my old findings still hold up today. Input lag is much more prominent while HidCerberus is running even when a device is not blocked by HidGuardian. Killing the service makes input latency go back down to normal. When HidGuardian is used to block the device and HidCerberus is running, I find the input lag bad enough to make a game borderline unplayable. The use of the custom HidGuardHelper.exe app is still justified in my mind.

These tests are with using vanilla HidGuardian 1.14.3.0. For the few times I decide to actively use HidGuardian, I end up using a custom version as vanilla doesn't quite do what I want. The old Exclusive Mode workaround usually works well enough for my use so I don't usually bother even using the custom HidGuardian.

https://github.com/Ryochan7/HidGuardian/tree/gottagofast

[Chrisnetika]

Vanilla hidguardian you use is the one in the wiki? I had zero issues with latency mainly bc I been using hide ds4 option

[Chrisnetika]

ahh nvm, just clicked the link at the end your comment, will try that version and test

[Ryochan7]

There is no binary version. It is only the source code. There is no reasonable way to distribute a pre-compiled version due to the hoops users would have to go through to get it running. The normal driver install process is pretty much behind a walled garden that requires paying Microsoft ~$300 to get your driver digitally signed IIRC.

[Chrisnetika]

if i compile, no way to install it unless i disable driver signature enforcement?

[Ryochan7]

Correct. You will need to run Windows in Test Mode.

[Ryochan7]

The main thing that the custom version does is remove HidGuardian from being responsible for forwarding

[Ryochan7]

Oops. Continuing. The custom HidGuardian will only intercept CreateFile requests. The vanilla version intercepts other calls to the HID device and just forwards those request up the chain. Removing that unnecessary step does help with responsiveness and it removes a part of HidGuardian that is not really necessary.

[Ryochan7]

A long aside post. HidGuardHelper.exe has come in handy with some recent experiments that I have done with the Touchmote project. I recently bought a wheel shell for my Wiimote and I wanted to try it out by playing Star Wars Episode 1: Racer. Unfortunately, when opening the Wiimote in Touchmote, Star Wars Episode 1: Racer would detect an inactive game controller exposed by the DolphinBar rather than the virtual Xbox 360 controller.

I had to compile the gottagofast branch of HidGuardian and install it. The proper Hardward IDs were added to HidGuardian so that all four exposed controllers would be blocked; they all have unique Hardware IDs due to the interface number (MI). HidGuardHelper.exe was passed the current Touchmote PID and that would cause the program's device check routine to detect and then open the Wiimote. With the Wiimote blocked from the game, the game could actually detect the virtual Xbox 360 controller and controls could then be mapped in game.

[Ryochan7]

It might be useful at some point to create an alternative to HIDer. HIDer has not been maintained since early 2018 and it kind of runs a bit slowly. Leaving the application open at all times would not be advisable.

It is funny that I have now started to use HidGuardian more regularly for my minor experiments with Touchmote than I have ever run it with DS4Windows.

[Ryochan7]

I finally got around to coding an HIDer replacement app. Not a great app but it does what I want. The app does provide some unique functionality and I think it is slightly better than HIDer used to be.

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

Source: https://gitlab.com/ryochan7/hidhidetest

[Chrisnetika]

In a sense a Hid Cerberus alternative?

[Chrisnetika]

believe it or not it still does not work right in exclusive mode unless I use hide ds4 controller haha.Your new tool shows that hidguardian helper is updating the PID but still.. odd.Works well with input mapper.If i do not have inputmapper set in hidguardian and i load it, input mapper does not detect my controller but once I set inputmapper in allowed .. bam the controller shows up.

[Ryochan7]

HidGuardian is likely doing its job. The Exclusive check won't be visible in DS4Windows unless DS4Windows attempts to open the device with exclusive access (Hide DS4 Controller). Even when using HidGuardian, multiple processes can still have access to the same blocked device if the processes are whitelisted.

The only way around the issue would be to add a third state to the Exclusive check and add a registry check while enumerating devices to detect if a device is affected by HidGuardian.