v215 Cold Boot Win7 Issue

[shinra358]

On cold boot, controller is already in the joy the cpl. when 1 controller is turned on, there are then 2 microsoft windows controllers in the joy.cpl and they don't work in game. Only when DS4windows is restarted is when everything works properly again.

[mika-n]

https://github.com/Ryochan7/DS4Windows/wiki/Exclusive-Mode-(Hide-DS4-Controller-config-option)-tips-and-issues

[shinra358]

Cold boot = no open apps yet 😂. V215, havent noticed this issue with this version yet. But i also havent shut pc off since. Ill test today to see if i should close issue.

[mika-n]

Maybe you have the ancient Windows "Windows fast startup" enabled? In practice it is no longer needed with SSD disks because the Windows boots up so fast anyway. The ancient "fast startup" was created for slow HDD disks to speed up the WinOS bootup. The side effect of this is that some system settings are persistent between WinOS reboots because the fast startup re-reads certain cached WinOS status data dump files. Try disabling the fast startup to make sure that "cold reboot" really is cold reboot and not partial reboot with certain cached data from the state right before the latest shutdown. https://www.windowscentral.com/how-disable-windows-10-fast-startup

[shinra358]

Nope. Ssd's management program been turned that off along with system restore so the huge file wouldnt be saved on the ssd ruining its lifespan. Had ssd since 2012. Still reads as 'good'. If it was this, issue would persist through every ds4 version. This is purely an issue with ds4w v214 and the virtual device system addition for multi xbox controllers are shown on start in joy.cpl. Will turn pc back on in 20min to see if issue is gone w v215.

On Sun, Aug 16, 2020, 9:13 AM mika-n notifications@github.com wrote:

Maybe you have the ancient Windows "Windows fast startup" enabled? In practice it is no longer needed with SSD disks because the Windows boots up so fast anyway. The ancient "fast startup" was created for slow HDD disks to speed up the WinOS bootup. The side effect of this is that some system settings are persistent between WinOS reboots because the fast startup re-reads certain cached WinOS status data dump files. Try disabling the fast startup to make sure that "cold reboot" really is cold reboot and not partial reboot with certain cached data from the state right before the latest shutdown. https://www.windowscentral.com/how-disable-windows-10-fast-startup

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Ryochan7/DS4Windows/issues/1414#issuecomment-674525150, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA6LIM72XX7WXEQQLVFUS5TSA7LN3ANCNFSM4PG64YXQ .

[shinra358]

So i didnt see quickboot in my bios but i saw fast boot. Turned off fast boot anyway and the issue still happens. A controller is seen in joy.cpl as soon as pc turns on. I go to output slots and clivk on the controller, it says dynamic and gives the option to unplug. When i push the unplug button nothing happens. Physical controller is not on at all. Controller doesnt function proper in emus and some pc games until i restart ds4w. Again, this issue is in v215 as well. Windows just has to startup up. It doesnt have to be cold.

On Sun, Aug 16, 2020, 9:23 AM Quan Chi shinra35888@gmail.com wrote:

Nope. Ssd's management program been turned that off along with system restore so the huge file wouldnt be saved on the ssd ruining its lifespan. Had ssd since 2012. Still reads as 'good'. If it was this, issue would persist through every ds4 version. This is purely an issue with ds4w v214 and the virtual device system addition for multi xbox controllers are shown on start in joy.cpl. Will turn pc back on in 20min to see if issue is gone w v215.

On Sun, Aug 16, 2020, 9:13 AM mika-n notifications@github.com wrote:

Maybe you have the ancient Windows "Windows fast startup" enabled? In practice it is no longer needed with SSD disks because the Windows boots up so fast anyway. The ancient "fast startup" was created for slow HDD disks to speed up the WinOS bootup. The side effect of this is that some system settings are persistent between WinOS reboots because the fast startup re-reads certain cached WinOS status data dump files. Try disabling the fast startup to make sure that "cold reboot" really is cold reboot and not partial reboot with certain cached data from the state right before the latest shutdown. https://www.windowscentral.com/how-disable-windows-10-fast-startup

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Ryochan7/DS4Windows/issues/1414#issuecomment-674525150, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA6LIM72XX7WXEQQLVFUS5TSA7LN3ANCNFSM4PG64YXQ .

[shinra358]

Also, quickboot is a feature not in win7. I think we talked about this b4 and how quick is diff from fast boot and that fast boot just doesnt initiate some stuff and has nothing to do with memory.

On Sun, Aug 16, 2020, 10:22 AM Quan Chi shinra35888@gmail.com wrote:

So i didnt see quickboot in my bios but i saw fast boot. Turned off fast boot anyway and the issue still happens. A controller is seen in joy.cpl as soon as pc turns on. I go to output slots and clivk on the controller, it says dynamic and gives the option to unplug. When i push the unplug button nothing happens. Physical controller is not on at all. Controller doesnt function proper in emus and some pc games until i restart ds4w. Again, this issue is in v215 as well. Windows just has to startup up. It doesnt have to be cold.

On Sun, Aug 16, 2020, 9:23 AM Quan Chi shinra35888@gmail.com wrote:

Nope. Ssd's management program been turned that off along with system restore so the huge file wouldnt be saved on the ssd ruining its lifespan. Had ssd since 2012. Still reads as 'good'. If it was this, issue would persist through every ds4 version. This is purely an issue with ds4w v214 and the virtual device system addition for multi xbox controllers are shown on start in joy.cpl. Will turn pc back on in 20min to see if issue is gone w v215.

On Sun, Aug 16, 2020, 9:13 AM mika-n notifications@github.com wrote:

Maybe you have the ancient Windows "Windows fast startup" enabled? In practice it is no longer needed with SSD disks because the Windows boots up so fast anyway. The ancient "fast startup" was created for slow HDD disks to speed up the WinOS bootup. The side effect of this is that some system settings are persistent between WinOS reboots because the fast startup re-reads certain cached WinOS status data dump files. Try disabling the fast startup to make sure that "cold reboot" really is cold reboot and not partial reboot with certain cached data from the state right before the latest shutdown. https://www.windowscentral.com/how-disable-windows-10-fast-startup

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Ryochan7/DS4Windows/issues/1414#issuecomment-674525150, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA6LIM72XX7WXEQQLVFUS5TSA7LN3ANCNFSM4PG64YXQ .

[shinra358]

this issue still persists in v217. win7u starts with controllers seen already in joy.cpl when no controller is on. ds4windows_log.txt

maybe this log can say something about it now? When the error in this log happened, start/stop was also greyed out. Again, this is on start up with nothing touched yet.

[mika-n]

This is very strange. DS4Windows app itself doesn't have any "cache" which would remember a connected gamepad, so for some reason WinOS there remembers gamepad connections between reboots. And because of this things go wrong at DS4Windows startup time and an exception is thrown. This leaves the internal state of the app in "unstable" state and therefore the start/stop button may be left in disabled state.

How it goes if you do this:

• Shutdown all DS4 gamepads via PS button (hold down the btn 10secs)
• Shutdown the PC (no hibername/sleep)
• Start up the PC
• What do you see in JOY.CPL gamepad list?
• Toggle WinOS bluetooth setting off and on
• What do you see in JOY.CPL gamepad list at this point?
• Launch DS4Windows app and see how it goes

And maybe doing this test with a debug version to generate more details: https://github.com/Ryochan7/DS4Windows/wiki/Troubleshooting#detailed-debug-log-file-from-gamepad-connection-problems

2020-08-30 10:14:46.7487|INFO|Found Controller: A5:15:66:37:7E:18 (BT) (DS4 v.1)
2020-08-30 10:14:46.9047|INFO|Found Controller: DC:AF:68:3D:E3:73 (BT) (DS4 v.2)
2020-08-30 10:14:46.9203|INFO|Gamepad data write connection is lost. Disconnecting the gamepad. LastErrorCode=1167

[shinra358]

I will try out the debug. Points 1-3 are always how i restart. My controllers were already off when i restarted bcuz i wasnt even using them. So points 1-4 is already this report. Bbl with the debug version report.

On Sun, Aug 30, 2020, 11:15 AM mika-n notifications@github.com wrote:

This is very strange. DS4Windows app itself doesn't have any "cache" which would remember a connected gamepad, so for some reason WinOS there remembers gamepad connections between reboots. And because of this things go wrong at DS4Windows startup time and an exception is thrown. This leaves the internal state of the app in "unstable" state and therefore the start/stop button may be left in disabled state.

How it goes if you do this:

• Shutdown all DS4 gamepads via PS button (hold down the btn 10secs)
• Shutdown the PC (no hibername/sleep)
• Start up the PC
• What do you see in JOY.CPL gamepad list?
• Toggle WinOS bluetooth setting off and on
• What do you see in JOY.CPL gamepad list at this point?
• Launch DS4Windows app and see how it goes

And maybe doing this test with a debug version to generate more details:

https://github.com/Ryochan7/DS4Windows/wiki/Troubleshooting#detailed-debug-log-file-from-gamepad-connection-problems

2020-08-30 10:14:46.7487|INFO|Found Controller: A5:15:66:37:7E:18 (BT) (DS4 v.1) 2020-08-30 10:14:46.9047|INFO|Found Controller: DC:AF:68:3D:E3:73 (BT) (DS4 v.2) 2020-08-30 10:14:46.9203|INFO|Gamepad data write connection is lost. Disconnecting the gamepad. LastErrorCode=1167

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Ryochan7/DS4Windows/issues/1414#issuecomment-683432538, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA6LIMY27PWSPEMW4PD6WVDSDJUH3ANCNFSM4PG64YXQ .

[shinra358]

Steps 1-4 with debug version: I see 2 controllers xbox 360 for windows in the joy.cpl ds4windows_log.txt

steps 5-7: with bt turned off in winos, i still see 2 controllers in the joy.cpl. exiting and restarted ds4 windows with bt still off, there is nothing showing in the joy.cpl ds4windows_log.txt

[mika-n]

There seems to be a "race condition" bug in DS4Windows ControllerView form where it crashes if the controller list is modified while the view is still being created and the list of gamepads is added to the view.

However, your PC seems to have some sort of "cold reboot" bug where it leaves the status of certain devices "alive" between reboots even when the gamepad is not connected. Why? I don't know any other reason but the MS "fast restart" option (which is useless crap these days with SSD disks) in some Win versions. If you can workaround that bug in your WinOS setup then the "race condition" bug won't be an issue.

Anyway. Let's see if the ControllerView bug can be smashed, but it is a bit difficult if the issue cannot be re-produced at this end. Meanwhile try to find out why your Win7 leaves the status of certain devices "alive" between cold reboots. It has nothing to do with DS4Windows app because it doesn't have any "reboot surviving cache status of DeviceManager devices". The persistent controller feature in DS4Windows is optional and those virtual gamepad controllers created by DS4Windows+ViGem won't survive over cold reboots (at least by means of DS4Windows app).

[shinra358]

I'd like to point out that this didnt happen before the virtual pads were added. Ive had the exact same setup for years and have been around this project before ryochan picked it up.

On Mon, Aug 31, 2020, 2:32 AM mika-n notifications@github.com wrote:

There seems to be a "race condition" bug in DS4Windows ControllerView form where it crashes if the controller list is modified while the view is still being created and the list of gamepads generated on the view.

However, your PC seems to have some sort of "cold reboot" bug where it leaves the status of certain devices "alive" between reboots even when the gamepad is not connected. Why? I don't know any other reason but the MS "fast restart" option (which is useless crap these days with SSD disks) in some Win versions. If you can workaround that bug in your WinOS setup then the "race condition" bug won't be an issue.

Anyway. Let's see if the ControllerView bug can be smashed, but it is a bit difficult if the issue cannot be re-produced at this end. Meanwhile try to find out why your Win7 leaves the status of certain devices "alive" between cold reboots. It has nothing to do with DS4Windows app because it doesn't have any "reboot surviving cache status of DeviceManager devices". The persistent controller feature in DS4Windows is optional and those virtual gamepad controllers created by DS4Windows+ViGem won't survive over cold reboots (at least by means of DS4Windows app).

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Ryochan7/DS4Windows/issues/1414#issuecomment-683588207, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA6LIMZJPMOTQ3SMLJ6XDWDSDM7XLANCNFSM4PG64YXQ .

[mika-n]

"Virtual pads"? Do you mean when DS4Windows was changed from using ancient ScpToolkit drivers to use newer VigEm virtual gamepad driver? In that case it may be some incompatibility between Win7 and the ViGem driver. I know that there used to be driver signing incompatibility in Win7 and ViGem driver, but it was fixed by some optional MS hotfix explained in ViGem documentation. However, it should have nothing to do with "cold boot surviving" virtual gamepad devices. https://github.com/ViGEm/ViGEmBus/releases

You do seem to have a bit older ViGem driver (based on logfiles), so maybe you should try to update to the latest ViGem driver. Well, the driver itself is the same in the latest 116 vigem version, but installer has some installation bug fixes. Doesn't hurt anything to try re-installing the latest ViGem driver and do the Win7 tricks explained in the above linked web page.

And maybe trying to disable hibernate feature and kick out the hibernate cache file completely in WinOS and then testing if gamepad device registrations are still surviving over cold boots. https://support.microsoft.com/en-us/help/920730/how-to-disable-and-re-enable-hibernation-on-a-computer-that-is-running (cmd shell as RunAsAdmin and powercfg.exe /hibernate off command)

[shinra358]

I mean this didnt happen before the virtualpads were added. Ya know, the feature under the output slots tab.

On Mon, Aug 31, 2020, 9:38 AM mika-n notifications@github.com wrote:

"Virtual pads"? Do you mean when DS4Windows was changed from using ancient ScpToolkit drivers to use newer VigEm virtual gamepad driver? In that case it may be some incompatibility between Win7 and the latest ViGem driver. I know that there used to be driver signing incompatibility in Win7 and ViGem driver, but it was fixed by some optional MS hotfix explained in ViGem documentation. However, it should have nothing to do with "cold boot surviving" virtual gamepad devices. https://github.com/ViGEm/ViGEmBus/releases

You do seem to have a bit older ViGem driver (based on logfiles), so maybe you should try to update to the latest ViGem driver.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Ryochan7/DS4Windows/issues/1414#issuecomment-683784391, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA6LIM4QJ2AM2J4XAD7RH3TSDORXHANCNFSM4PG64YXQ .

[shinra358]

Ok i will update vigem drivers

On Mon, Aug 31, 2020, 9:45 AM Quan Chi shinra35888@gmail.com wrote:

I mean this didnt happen before the virtualpads were added. Ya know, the feature under the output slots tab.

On Mon, Aug 31, 2020, 9:38 AM mika-n notifications@github.com wrote:

"Virtual pads"? Do you mean when DS4Windows was changed from using ancient ScpToolkit drivers to use newer VigEm virtual gamepad driver? In that case it may be some incompatibility between Win7 and the latest ViGem driver. I know that there used to be driver signing incompatibility in Win7 and ViGem driver, but it was fixed by some optional MS hotfix explained in ViGem documentation. However, it should have nothing to do with "cold boot surviving" virtual gamepad devices. https://github.com/ViGEm/ViGEmBus/releases

You do seem to have a bit older ViGem driver (based on logfiles), so maybe you should try to update to the latest ViGem driver.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Ryochan7/DS4Windows/issues/1414#issuecomment-683784391, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA6LIM4QJ2AM2J4XAD7RH3TSDORXHANCNFSM4PG64YXQ .

[mika-n]

Aaah. You mean "permanent controllers" feature.

Virtual pads have been in DS4Windows since the version 0.00001 because the idea of having re-mapped gamepad button events is based on virtual gamepad devices since the beginning of time.

Do you have something set in "Output Slots" tab page as "Permanent" or is everything in default "Dynamic" value? The "Dynamic" option behaves the same as always in DS4Windows. Only if some controller slot is set to "Permanent" value then things work a bit differently when physical gamepads are disconnected. What do you have here? If you have "Permanent" then how it goes with the default "Dynamic" value?

I believe none of the developers have Win7 anymore, so could be that there are corner cases in Win7 OS version.

[shinra358]

@mika-n I do have ViGEmBus_Setup_1.16.116 installed. I even just uninstalled and reinstalled ViGEmBus_Setup_1.16.116. However, it still states ViGEmBus 112 is being used in the logfile @.@

[mika-n]

@mika-n I do have ViGEmBus_Setup_1.16.116 installed. I even just uninstalled and reinstalled ViGEmBus_Setup_1.16.116. However, it still states ViGEmBus 112 is being used in the logfile @.@

Yes. The 116 version is "just" installler app bug fix and the underlying driver is still 112, so the logfile doesn't lie.

[shinra358]

@mika-n i don't have anything set under the output slots tab.

but i just downloaded it again and reinstalled and it is saying 112 but you just told me i have an old version. v112 was showing in my first logs.

[shinra358]

I just did a reboot since i just reinstalled the drivers. Nothing is in the joy.cpl now. Hmm. Maybe something was wrong w my previous installation and reinstalling fixed it? If the issue doesnt return in the next 3 days i will close this.

On Mon, Aug 31, 2020, 9:55 AM mika-n notifications@github.com wrote:

@mika-n https://github.com/mika-n I do have ViGEmBus_Setup_1.16.116 installed. I even just uninstalled and reinstalled ViGEmBus_Setup_1.16.116. However, it still states ViGEmBus 112 is being used in the logfile @.@

Yes. The 116 version is "just" installler app bug fix and the underlying driver is still 112, so the logfile doesn't lie.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Ryochan7/DS4Windows/issues/1414#issuecomment-683794003, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA6LIM2ZPVOSBRGLWS4RW4TSDOTUNANCNFSM4PG64YXQ .

[shinra358]

ds4windows_log.txt Ok, so false alarm. This is still happening. I just forgot to turn BT emitter back on, that's why nothing was showing after that restart. So when I turn BT back on and restart, 2 xbox controllers are shown in the joy.cpl again. The log says that it is plugging in the virtual controllers at start @.@

When i go to output slots, my physical controllers are off. but it shows 2 controllers as active and dynamic with the unplug button able to be pressed. But when I try to press unplug button, nothing happens.

So is dynamic supposed to be normal functionality and permanent supposed to be virtual controllers that show forever? Maybe somehow the program is defaulting to permanent at the start (but never says permanent in the app)?

But it is indicated in the output tab that controllers are there when they are not even on. Pressing unplug at this time does nothing but if I turn on the controller right after, the ds4windows freezes and so does the whole pc at an interval. I then have to hard exit the program via task manager.

At start, if I press stop, and then start, nothing is checked in the output tab. But if I restart and look at output tab, 2 controllers are checked but it's on dynamic. So it absolutely must be getting it's wires crossed and think it's on permanent at first start when it's not, causing this issue.

Edit: If I turn off automatic startup and restart, and turn on ds4windows manually, only 1 controller is shown in the joy.cpl. So I then have to manually press stop and then start and everything is ok (if i press unplug, it will still freeze the program if I turn my controller on right after pressing unplug). I'd really hate to make an ahk script just to do this to fix the issue :(

Im very curious about this: 2020-08-31 15:19:49.5088|INFO|Gamepad data write connection is lost. Disconnecting the gamepad. LastErrorCode=1167 since i have the program to start with the task for admin rights

I see these posts with the same code: https://www.qdxingtu.com/key/Controller%20keeps%20intermittently%20disconnecting.html https://www.reddit.com/r/DS4Windows/comments/holtwy/ps4_controller_unable_to_maintain_a_bluetooth/

I doubt idle disconnect is the issue considering no controller is on at start up. And I doubt my controller's bluetooth is bad because they work fine after I start/stop ds4windows and again no controller is on at start.

On Mon, Aug 31, 2020 at 10:05 AM Quan Chi shinra35888@gmail.com wrote:

I just did a reboot since i just reinstalled the drivers. Nothing is in the joy.cpl now. Hmm. Maybe something was wrong w my previous installation and reinstalling fixed it? If the issue doesnt return in the next 3 days i will close this.

On Mon, Aug 31, 2020, 9:55 AM mika-n notifications@github.com wrote:

@mika-n https://github.com/mika-n I do have ViGEmBus_Setup_1.16.116 installed. I even just uninstalled and reinstalled ViGEmBus_Setup_1.16.116. However, it still states ViGEmBus 112 is being used in the logfile @.@

Yes. The 116 version is "just" installler app bug fix and the underlying driver is still 112, so the logfile doesn't lie.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Ryochan7/DS4Windows/issues/1414#issuecomment-683794003, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA6LIM2ZPVOSBRGLWS4RW4TSDOTUNANCNFSM4PG64YXQ .

[mika-n]

"So is dynamic supposed to be normal functionality and permanent supposed to be virtual controllers that show forever? Maybe somehow the program is defaulting to permanent at the start (but never says permanent in the app)?"

The default behavior "Dynamic" in OutputSlots means that when a physical controller is disconnected then the virtual output controller will be disconnected at the same time.

When you have successfully connected a DS4 gamepad and you have these slots set as dynamic then is the virtual xbox360 gamepad removed from the WinOS when you disconnect the DS4 gamepad (holding PS button for 10 secs)? The virtual xbox360 gamepad device should be gone when you close DS4Windows app.

"Permanent" outputSlot option means that if the physical controller is disconnected then the virtual xbox360 (or dualshock4 if profile uses that controller output mode) device is still left in connected state. Some games don't like if the gamepad disconnects while the game is running, so this option solves that issue (physical accidentally disconnected, but the virtual gamepad is still in connected state so the game won't see disconnection-reconnection events). However, when DS4Windows application is closed then these "permanent" controllers are disconnected because the ViGem object dies when DS4Windows app is closed. These "permanent" virtual gamepads should not survive over reboots (and doesn't survive at least here in Win10).

When you close DS4Windows app then check whether those virtual output controllers are gone in JOY.CPL controlPanel applet.

Still, I suspect there is something wrong in your Win7 setup when it leaves the status of some devices intact over reboots because DS4Windows app itself doesn't have any capabilities to do something like that.

You use "exclusive mode" (=Hide DS4 Controller) option (good, because many games require it). But, as a test run try to untick this HideDS4Controller option and see if the problem stays the same (ie. virtual gamepad devices survive over reboots).

HidGuardian driver solution is an alternative way to hide the original physical controller from games. https://github.com/Ryochan7/DS4Windows/wiki/Exclusive-Mode-(Hide-DS4-Controller-config-option)-tips-and-issues

[shinra358]

"When you have successfully connected a DS4 gamepad and you have these slots set as dynamic then is the virtual xbox360 gamepad removed from the WinOS when you disconnect the DS4 gamepad (holding PS button for 10 secs)? "

Yes.

"When you close DS4Windows app then check whether those virtual output controllers are gone in JOY.CPL controlPanel applet."

No matter the mode, they are gone in cpl when ds4windows is closed.

"Still, I suspect there is something wrong in your Win7 setup when it leaves the status of some devices intact over reboots because DS4Windows app itself doesn't have any capabilities to do something like that."

If this were true, i wouldve had this issue before permanent mode was added or anytime in the past. Issue only started when permanent output slots were added.

"But, as a test run try to untick this HideDS4Controller option and see if the problem stays the same (ie. virtual gamepad devices survive over reboots)."

With hide ds4 controller off, on boot, it just says 1 wireless controller. But then changes to 1 xbox360 controller for windows after a few seconds.

I also notice when controllers are in joy cpl on boot, if i press stop and then start, the controllers in joy.cpl disappear but active box is still checked for the 1st controller and it still says x360 as current instead of empty in output slots tab. But when ds4windows is completely restarted, all slots say empty and all active boxes are unchecked. Maybe there's an error in the start/stop function coding where it forgets to empty all of the slots content when stop/start is pressed. Let's start with that. Then we'll see if this issue can progress.

So please put out a quick update to ensure all virtual devices seen in output tab empties when stop/start is pressed.

[mika-n]

Quote1: "If this were true, i wouldve had this issue before permanent mode was added or anytime in the past. Issue only started when permanent output slots were added." Quote2: "So please put out a quick update to ensure all virtual devices seen in output tab empties when stop/start is pressed."

To answer the Q1 could be that the "weird cold boot surviving virtual output devices" issue has been there in your Win7 setup already before the persistent controller feature, but you were just lucky enough to get a way from that problem without issues in DS4Windows app. Now with the persistent controller feature (=Output slots tab page is a new thing) this bug in your Win7 environment hits back and causes side effects in DS4Windows app during startup. This is because of unexpected controller removal event while the DS4Windows app is launching and creating the OutputSlots tab page content for the first time. Yes, this is an exception handling bug in DS4Windows app, but it is difficult to track down when the issue cannot be replicated here. No one else seem to suffer from that issue, so fortunately the problem is not widespread. You are unlucky to suffer this issue, but if you can work out why your Win7 has this device caching issue then the bug won't hit back.

And Q2. Confirmed. When DS4Windows app is closed it removes all virtual output devices (ViGem created devices). And you can confirm this yourself by looking at JOY.CPL list after you have closed DS4Windows app or pressed "Stop" button. Those persistent controllers are kept alive only as long DS4Windows app is running. So, if those devices all in a sudden comes back after cold reboot (even when DS4Windows app is not set to autolaunch) then root issue is in your Win7 setup (incompatible with the latest ViGem or you have some registry problem causing ViGem driver to "open" those devices automagically when the driver is loaded at boot time). . Sorry, but when the issue cannot be replicated here it is very difficult to track down.

If the issue can be resolved by starting and stopping DS4Windows two times then maybe you can automate that "workaround" by creating a batch script to launch DS4Windows app and the batch script does those start-stop-start things automagically. https://github.com/Ryochan7/DS4Windows/wiki/Command-line-options

[shinra358]

uninstalled and reinstalled x360 drivers. now there's 2 xbox controllers in joy.cpl that show when ds4windows is started automatically. So I the 2 dinput controllers turning into 1 xbox was just something got messed up by the driver stallation which probably happened around the time the new version started coming and my controllers tried to looking for the drivers again. windows may have allocated both controllers to the same p1 spot.

But anyway now that, that is settled and there are 2 x360 controllers showing now, I think for some reason 'hide dinput' isnt properly initializing on startup up before ds4w turns them into v x360 pads and that is why it's ds4w is thinking 2 x360 pads are on. But yeah, this issue has happened before in the past and was solved by adding some checks by ryo and the original ds4w guy.

but that is just my hypothesis. i could be full of &^%$ xD

[shinra358]

aaaaaaaaand, it's back to one xbox gamepad after restart lol. (startup=2 dinput pads turn into 1 xbox pad when ds4w initializes joy.cpl. Pressing stop/start= 0 pads in joy.cpl)

v219. my braaaain xD

And when I immediately press stop and then start:

[mika-n]

Do you have two gamepads? One as DS4 revision1 and the other as DS4 revision2 (released with PS4-Slim and PS4-Pro)? Nowadays all genuine Sony gamepads sold in stores are DS4v2 revision2 gamepads, because Sony haven't manufactured DS4v1 gamepads for years.

What happens if you use DS4Windows app with just one gamepad? Or if you really have just one physical gamepad then I wonder from where the other DS4 gamepad device is popping up.

Any other apps creating ViGem gamepads because if ViGem is used to create dualshock4 gamepad then it has DS4v1 hardware ID? Autohotkey? InputMapper? OculusRift with custom controllers (some old versions of Oculus used ViGem to create virtual gamepads)?

2020-08-31 14:51:23.3053|INFO|Found Controller: A5:15:66:37:7E:18 (BT) (DS4 v.1)
2020-08-31 14:51:23.4769|INFO|Plugging in virtual X360 Controller
2020-08-31 14:51:23.4769|INFO|Associate X360 Controller for input DS4 #1
2020-08-31 14:51:23.4925|INFO|Found Controller: DC:AF:68:3D:E3:73 (BT) (DS4 v.2)
2020-08-31 14:51:23.5237|INFO|Plugging in virtual X360 Controller
2020-08-31 14:51:23.5237|INFO|Associate X360 Controller for input DS4 #2

[shinra358]

This is w no gamepads on at all. Both are sinc'd to pc but are not touched period. These pics are w both of them off.

During this time, actually using one pad acts like only p2 is being used. If i restart ds4w, both controllers function as normal. I have no other apps associated w using the controllers that i know of. No special setups.

On Thu, Sep 3, 2020, 3:08 PM mika-n notifications@github.com wrote:

Do you have two gamepads? One as DS4 revision1 and the other as DS4 revision2 (released with PS4-Slim and PS4-Pro)? Nowadays all genuine Sony gamepads sold in stores are DS4v2 revision2 gamepads, because Sony haven't manufactured DS4v1 gamepads for years.

What happens if you use DS4Windows app with just one gamepad? Or if you really have just one physical gamepad then I wonder from where the other gamepad is popping up. Any other apps creating ViGem gamepads because if ViGem is used to create dualshock4 gamepad then it has DS4v1 hardware ID?

2020-08-31 14:51:23.3053|INFO|Found Controller: A5:15:66:37:7E:18 (BT) (DS4 v.1) 2020-08-31 14:51:23.4769|INFO|Plugging in virtual X360 Controller 2020-08-31 14:51:23.4769|INFO|Associate X360 Controller for input DS4 #1 2020-08-31 14:51:23.4925|INFO|Found Controller: DC:AF:68:3D:E3:73 (BT) (DS4 v.2) 2020-08-31 14:51:23.5237|INFO|Plugging in virtual X360 Controller 2020-08-31 14:51:23.5237|INFO|Associate X360 Controller for input DS4 #2

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Ryochan7/DS4Windows/issues/1414#issuecomment-686700970, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA6LIM2EYLTRES22FE5SOO3SD7SSFANCNFSM4PG64YXQ .

[shinra358]

Yes both my controllers are from 2 diff generations

On Thu, Sep 3, 2020, 3:12 PM Quan Chi shinra35888@gmail.com wrote:

This is w no gamepads on at all. Both are sinc'd to pc but are not touched period. These pics are w both of them off.

During this time, actually using one pad acts like only p2 is being used. If i restart ds4w, both controllers function as normal. I have no other apps associated w using the controllers that i know of. No special setups.

On Thu, Sep 3, 2020, 3:08 PM mika-n notifications@github.com wrote:

Do you have two gamepads? One as DS4 revision1 and the other as DS4 revision2 (released with PS4-Slim and PS4-Pro)? Nowadays all genuine Sony gamepads sold in stores are DS4v2 revision2 gamepads, because Sony haven't manufactured DS4v1 gamepads for years.

What happens if you use DS4Windows app with just one gamepad? Or if you really have just one physical gamepad then I wonder from where the other gamepad is popping up. Any other apps creating ViGem gamepads because if ViGem is used to create dualshock4 gamepad then it has DS4v1 hardware ID?

2020-08-31 14:51:23.3053|INFO|Found Controller: A5:15:66:37:7E:18 (BT) (DS4 v.1) 2020-08-31 14:51:23.4769|INFO|Plugging in virtual X360 Controller 2020-08-31 14:51:23.4769|INFO|Associate X360 Controller for input DS4 #1 2020-08-31 14:51:23.4925|INFO|Found Controller: DC:AF:68:3D:E3:73 (BT) (DS4 v.2) 2020-08-31 14:51:23.5237|INFO|Plugging in virtual X360 Controller 2020-08-31 14:51:23.5237|INFO|Associate X360 Controller for input DS4 #2

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Ryochan7/DS4Windows/issues/1414#issuecomment-686700970, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA6LIM2EYLTRES22FE5SOO3SD7SSFANCNFSM4PG64YXQ .

[mika-n]

I have to say that I'm running out of ideas. Really weird issue. Cannot duplicate the bug here, so can't do much about it. When "Output slots" is set as dynamic then the "persistent" feature is not used at all (%APPDATA%\DS4Windows\ folder should not have OutputSlots.xml file or the file has nothing but couple version tag xml tags).

If persistent outputSlot feature is used then DS4Windows creates a virtual xbox360 device automagically at DS4Windows launch time even when a physical DS4 gamepad is missing. But that is by design and the virtual gamepad just sits there doing nothing and waiting for the first physical controller to be connected and linked to this persistent slot.

But why you are experiences those weird app exceptions? Don't know.

[shinra358]

I have my outputslots.xml set to the program folder (program is not on system drive) and youre right, doesn't have much in it:

<?xml version="1.0" encoding="utf-8"?>

On Fri, Sep 4, 2020 at 8:36 AM mika-n notifications@github.com wrote:

I have to say that I'm running out of ideas. Really weird issue. Cannot duplicate the bug here, so can't do much about it. When "Output slots" is set as dynamic then the "persistent" feature is not used at all (%APPDATA%\DS4Windows\ folder should not have OutputSlots.xml file or the file has nothing but couple version tag xml tags).

If persistent outputSlot feature is used then DS4Windows creates a virtual xbox360 device automagically at DS4Windows launch time even when a physical DS4 gamepad is missing. But that is by design and the virtual gamepad just sits there doing nothing and waiting for the first physical controller to be connected and linked to this persistent slot.

But why you are experiences those weird app exceptions? Don't know.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Ryochan7/DS4Windows/issues/1414#issuecomment-687116202, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA6LIMYEJHUBVACNAD672HDSEDNNTANCNFSM4PG64YXQ .

[mika-n]

Hmmm.. There has been cases in the past where things doesn't quite work right when the app and/or config files have been installed in programFiles (or progarmFiles(x86)) folder because Windows enforces there extra security permissions. But, could be that those security tweaks are not in Win7. Anyway, it won't hurt anything if you re-install DS4Windows to use the default appdata folder instead of program folder (that is if by "program folder" you meant the WinOS programFiles or programFiles(x86) folder and not some custom folder).

[shinra358]

As i stated, it's not installed on the system drive (so it's not in program files). And i do not want to use appdata. I like my programs portable and not all over the pc. Im the guy who requested that feature long ago ;)

On Fri, Sep 4, 2020, 11:31 AM mika-n notifications@github.com wrote:

Hmmm.. There has been cases in the past where things doesn't quite work right when the app and/or config files have been installed in programFiles (or progarmFiles(x86)) folder because Windows enforces there extra security permissions. But, could be that those security tweaks are not in Win7. Anyway, it won't hurt anything if you re-install DS4Windows to use the default appdata folder instead of program folder (that is if by "program folder" you meant the WinOS programFiles or programFiles(x86) folder and not some custom folder).

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Ryochan7/DS4Windows/issues/1414#issuecomment-687221796, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA6LIM3YS32WT6HDGLKJDEDSEEB5TANCNFSM4PG64YXQ .

[shinra358]

New bug presented itself with this. Could only close the program by task manager.

[mika-n]

closed as inactive and Win7 is already ancient history. Developers of DS4Windows no longer have Win7 systems, so cannot test it. All I can recommend is to upgrade to Win10 if you don't have any apps or devices requiring Win7 PC. Win10 really works great and the anti-Vista/Win8 arguments doesn't have any relevance with Win10 anymore.

[shinra358]

You got win 10 money? 😂

On Mon, Nov 23, 2020, 4:58 AM mika-n notifications@github.com wrote:

Closed #1414 https://github.com/Ryochan7/DS4Windows/issues/1414.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Ryochan7/DS4Windows/issues/1414#event-4026756805, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA6LIM2X5CDQBVXBM7HYXSTSRIW2TANCNFSM4PG64YXQ .

[mika-n]

Did it for free back then 👍

[Masamune3210]

You got win 10 money? 😂 … On Mon, Nov 23, 2020, 4:58 AM mika-n @.***> wrote: Closed #1414 <#1414>. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1414 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA6LIM2X5CDQBVXBM7HYXSTSRIW2TANCNFSM4PG64YXQ .

For reference, 7 has been Officially EOL from Microsoft for almost a year now. The 10 upgrade as of now is still free as long as you have a valid license to 7 or 8

https://www.google.com/amp/s/www.theverge.com/platform/amp/2020/1/14/21065140/how-to-upgrade-microsoft-windows-7-10-free-os

[shinra358]

Right now, would it be too much to ask for a command line tab where viewers can see a list of command line options they could use for ds4windows? And to easily rectify this problem on my own for win7u, can you add cmdline options for STOP, START, RUN AS TASK, EXIT, and the few output slot options available? A cmdline trigger that detects battery level >90% would be useful as well as well as a timer to accompany it that tells ds4w to call the STOP function and then the START function right after, after a certain time interval to hack fix my charging issue as well. Thank you. This way, I can make a bat or ahk exe that can remedy this automatically.

On Mon, Nov 23, 2020 at 10:39 AM Masamune3210 notifications@github.com wrote:

You got win 10 money? 😂 … <#m-7961058595232083938> On Mon, Nov 23, 2020, 4:58 AM mika-n @.***> wrote: Closed #1414 https://github.com/Ryochan7/DS4Windows/issues/1414 <#1414 https://github.com/Ryochan7/DS4Windows/issues/1414>. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1414 (comment) https://github.com/Ryochan7/DS4Windows/issues/1414#event-4026756805>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA6LIM2X5CDQBVXBM7HYXSTSRIW2TANCNFSM4PG64YXQ .

For reference, 7 has been Officially EOL from Microsoft for almost a year now. The 10 upgrade as of now is still free as long as you have a valid license to 7 or 8

https://www.google.com/amp/s/www.theverge.com/platform/amp/2020/1/14/21065140/how-to-upgrade-microsoft-windows-7-10-free-os

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Ryochan7/DS4Windows/issues/1414#issuecomment-732239060, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA6LIM2C2IF5ELSTAJNBTE3SRJ6ZPANCNFSM4PG64YXQ .

[mika-n]

Existing command line options are documented here: https://github.com/Ryochan7/DS4Windows/wiki/Command-line-options

There is also a link to an addtional (optional) DS4WindowsCmd.exe tool which makes it a bit easier to integrate those command line calls into WinOS batch scripts if you need to query property values or synchronize command execution in the batch script (ie. the previous command is completed before the batch script runs the next command).

Querying the battery or charging status is not supported at the moment via the cmdline interface, but I can see how it might be useful in some scenarios. I just added a support for new "-command Query.1.Battery" and "-command Query.1.Charging" cmdline options to query this status. The next release should have those new battery related command line commands.

[shinra358]

didn't even know about this. can you include this in the releases in a tools folder? in case you guys disappear, this will be always available.

also, which one controls output slots dynamic and permanent?

On Tue, Nov 24, 2020 at 11:19 AM mika-n notifications@github.com wrote:

Existing command line options are documented here: https://github.com/Ryochan7/DS4Windows/wiki/Command-line-options

There is also a link to an addtional (optional) DS4WindowsCmd.exe tool which makes it a bit easier to integrate those command line calls into WinOS batch scripts if you need to query property values or synchronize command execution in the batch script (ie. the previous command is completed before the batch script runs the next command).

Querying the battery or charging status is not supported at the moment via the cmdline interface, but I can see how it might be useful in some scenarios. I just added a support for new "-command Query.1.Battery" and "-command Query.1.Charging" cmdline options to query this status. The next release should have those new battery related command line commands.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Ryochan7/DS4Windows/issues/1414#issuecomment-733085978, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA6LIM6FLYJC2GBGR7YE4U3SRPMKNANCNFSM4PG64YXQ .

[mika-n]

Those new Battery and Charging cmdline options are already in the official code, but the new version is not yet released. The next official release should have those new options.

Meanwhile you can give a test run with the debug version because there those new options (Battery and Charging) are already available. And the linked cmdline document page already lists those even when the official release doesn't have those (the doc is a bit ahead of time). https://github.com/Ryochan7/DS4Windows/wiki/Troubleshooting#detailed-debug-log-file-from-gamepad-connection-problems

[shinra358]

I know that but i asked which one controlled the dynamic and permanent options for i am unsure.

On Wed, Nov 25, 2020, 2:42 PM mika-n notifications@github.com wrote:

Those new Battery and Charging cmdline options are already in the official code, but the new version is not yet released. The next official release should have those new options.

Meanwhile you can give a test run with the debug version because there those new options (Battery and Charging) are already available. And the linked cmdline document page already lists those even when the official release doesn't have those (the doc is a bit ahead of time).

https://github.com/Ryochan7/DS4Windows/wiki/Troubleshooting#detailed-debug-log-file-from-gamepad-connection-problems

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Ryochan7/DS4Windows/issues/1414#issuecomment-733912665, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA6LIMZB7SHNWPHKA3LKMADSRVMY7ANCNFSM4PG64YXQ .

[shinra358]

Unless youre saying they will be in new version. If so, then ok gotcha.

On Wed, Nov 25, 2020, 4:19 PM Quan Chi shinra35888@gmail.com wrote:

I know that but i asked which one controlled the dynamic and permanent options for i am unsure.

On Wed, Nov 25, 2020, 2:42 PM mika-n notifications@github.com wrote:

Those new Battery and Charging cmdline options are already in the official code, but the new version is not yet released. The next official release should have those new options.

Meanwhile you can give a test run with the debug version because there those new options (Battery and Charging) are already available. And the linked cmdline document page already lists those even when the official release doesn't have those (the doc is a bit ahead of time).

https://github.com/Ryochan7/DS4Windows/wiki/Troubleshooting#detailed-debug-log-file-from-gamepad-connection-problems

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Ryochan7/DS4Windows/issues/1414#issuecomment-733912665, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA6LIMZB7SHNWPHKA3LKMADSRVMY7ANCNFSM4PG64YXQ .

[mika-n]

As documented in the following page there is NOT an option to control dynamic vs permanent option (at least not yet). https://github.com/Ryochan7/DS4Windows/wiki/Command-line-options

[shinra358]

Ok. Thanks.

On Wed, Nov 25, 2020, 4:28 PM mika-n notifications@github.com wrote:

As documented in the following page there is NOT an option to control dynamic vs permanent option (at least not yet). https://github.com/Ryochan7/DS4Windows/wiki/Command-line-options

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Ryochan7/DS4Windows/issues/1414#issuecomment-733953858, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA6LIM46PIPTABKA27C5U73SRVZH3ANCNFSM4PG64YXQ .

[mika-n]

The latest V2.1.18 is released and it has various OutputSlot related cmdline options. https://github.com/Ryochan7/DS4Windows/wiki/Command-line-options

Also, see the additional DS4WindowsCmd tool to make it easier to integrate these commands to a Windows batch script. https://github.com/mika-n/DS4WindowsCmd/releases

Here is an example batch script demonstrating how to use the cmd tool. https://github.com/mika-n/DS4WindowsCmd/blob/master/ExampleScript.bat

[shinra358]

Thanks, I'll check it out.

On Sat, Nov 28, 2020, 2:42 PM mika-n notifications@github.com wrote:

The latest V2.1.18 is released and it has various OutputSlot related cmdline options. https://github.com/Ryochan7/DS4Windows/wiki/Command-line-options

Also, see the additional DS4WindowsCmd tool to make it easier to integrate these commands to a Windows batch script. https://github.com/mika-n/DS4WindowsCmd/releases

Here is an example batch script demonstrating how to use the cmd tool. https://github.com/mika-n/DS4WindowsCmd/blob/master/ExampleScript.bat

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Ryochan7/DS4Windows/issues/1414#issuecomment-735281835, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA6LIM2UMHLZALG6Z6NDMBDSSFHCRANCNFSM4PG64YXQ .

[shinra358]

Can you add a cmdline options tab to view all info in those links inside of the program or bundle a pdf showing all this info with the program while bundling the ds4 command tool?

On Sat, Nov 28, 2020 at 2:44 PM Quan Chi shinra35888@gmail.com wrote:

Thanks, I'll check it out.

On Sat, Nov 28, 2020, 2:42 PM mika-n notifications@github.com wrote:

The latest V2.1.18 is released and it has various OutputSlot related cmdline options. https://github.com/Ryochan7/DS4Windows/wiki/Command-line-options

Also, see the additional DS4WindowsCmd tool to make it easier to integrate these commands to a Windows batch script. https://github.com/mika-n/DS4WindowsCmd/releases

Here is an example batch script demonstrating how to use the cmd tool. https://github.com/mika-n/DS4WindowsCmd/blob/master/ExampleScript.bat

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Ryochan7/DS4Windows/issues/1414#issuecomment-735281835, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA6LIM2UMHLZALG6Z6NDMBDSSFHCRANCNFSM4PG64YXQ .

[mika-n]

Now I didn't quite understood what did you mean. What info? When you run DS4WindowsCmd.exe command without any options then it dumps out usage info. And to see what those Query parameters actually return then simply run through those commands to see the result.