Very high cpu usage while not being used

[marcmy]

I have noticed a few times now that while not using my controller or DS4Windows (app minimized in my system tray), DS4Windows CPU usage would get as high as 40%. Restarting the app usually fixes it. My PS4 Controller is connected via USB, and I'm running Windows 10 on an i7-2600k. I'm also using Exclusive mode with HIDGuardian if that matters, and UDP server is enabled.

[mika-n]

Maybe .NET engine is just doing its job with garbage cleanup of memory allocations? It may cause a sudden CPU peaks, but should level out pretty soon. Application level cannot do much about it (except changing radically how objects are allocated and re-allocated).

If the cpu load remains high for a long period of time and never seems to recover from it on its own then it may be some app level bug.

When the issue happens next time then try to open DS4Win settings (without restarting the app) and disable UDPServer checkbox option. This should shutdown the built-in UDPServer service. Does it help?

Remember that even when you don't have controllers connected then UDPServer may be running if it is enabled and it receives calls (udp packages) from client apps (Cemu emulator maybe?).

[marcmy]

The cpu load usually stays high, but I will try disabling UDP server next time. I'll let you know asap.

[glorbvr]

I also notice the high CPU usage due to DS4 when my PC wakes up from sleep. I don't have the UDP Server option enabled.

[Ryochan7]

Maybe a thread is constantly running when it should not? On my system, CPU usage stays around 1%.

[mika-n]

Same here. Never encountered any unusual CPU activity because of DS4Win. What could cause this in your scenario? Hmm....

Are you using an automatic profile switching feature of DS4Win app? These settings are set in "Auto Profiles" tab page in Settings screen. If those are enabled then DS4Win app monitors the name of the foreground process and based on that automatically chooses a defined profile. Maybe this feature does something unusual? I never use this auto-profile feature.

[glorbvr]

I'm not using the auto profile feature. I'm able to recreate the issue every time I put my computer to sleep while DS4Windows is running. I've attached a picture of my settings along with the task manager showing the high CPU usage. Also the Memory used seems to be climbing every second. It's currently at 95.9MB and going up by .1MB/s.

EDIT: Where are the settings saved? Using a fresh extraction seems to keep my previous settings.

[mika-n]

Click the "Profile Folder" link shown in your screenshot. It takes you to the configured profile folder. Global settings of ds4win app are one folder step above.

[mika-n]

If you press "Stop" and then "Start" button (see the bottom right corner of your screenshot) then is the high CPU/RAM consumption "fixed" without unplugging controller (USB cable?) or re-starting DS4Win app?

[glorbvr]

Stopping and starting or unplugging the DS4 doesn't fix the high CPU, only closing the program works. I also deleted the global folder and used a fresh folder, and it still didn't fix the problem. Latest version 1.7.11 still has this bug. Is there anything I can upload or information I can provide to help pinpoint this issue?

[Ryochan7]

I will give suspend a try again later. It worked fine the last time I tried it.

[Wolfybrz]

Try deleting all *.config files on ds4windows folder, it helped me with the high memory usage/leak, I never noticed high cpu usage on my machine, hope that helps.

[glorbvr]

Deleting the .config files solved the rising memory usage, but the ~14-15% CPU utilization is still happening when waking the PC from sleep.

[Wolfybrz]

I tried to replicate the issue, and yes it happens while connected via usb. It only stops if close the program, clicking "stop" or "start" on ds4windows doesn't affect the 15% cpu usage... weird bug.

Most of us use a bluetooth dongle, probably the reason no one noticed this before.

[marcmy]

Hi. I've also noticed it happens after waking from sleep. Does not seem to happen any other time. UDP server doesn't affect it either. Not using auto profile.

[Ryochan7]

I'm glad I waited before trying this out. It seems like I cannot even test this. My computer refuses to resume even after a fresh boot and going to sleep without DS4Windows running. I don't think I have any VMs at the moment.

[RobertoBiundo]

Just as a note. I was using a very outdated version of DS4Windows. Actually version 1.6.14. And after updating I also got this High CPU usage. Normally it was 2-3% of my CPU (I have a i7-8700k @4.7Ghz) and after the update it is 10-12% CPU Usage. I will attribute this to the fact that in 1.7 ViGEmBus was added. I'm not sure if this is actually the case. I will make some tests and report back.

[RobertoBiundo]

I can confirm my original idea. I rolled back to the 1.6.14 version and here are my numbers

With 1.7+ (i tried 1.7.11, 1.7.5 and 1.7.0) the CPU Usage is: 0% with no controller connected (Expected) 6% to 8% when polling rate 4ms 8% to 12% when the polling rate is set to max

With version 1.6.14 CPU Usage is: 0% with no controller connected (Expected) 0.1% to 0.4% when polling rate 4ms 0.4% to 0.8% when polling date is set to max

NOTE: All tests where performed over BT

Not related to this. But interesting What I also realized thanks to this experiment is that the RAM usage increases in a rate of about 1Mb every 15 secs (this stats are for version 1.6.14). I imagine that this is due to variable allocation and that the .NET garbage collector will pick this up eventually. It would still be interesting to figure out which variables cause this and the possibility of optimizing this. I know that .NET will pick it up eventually but allocating ram that often leads to performance degradation. I'll still monitor if .NET picks this ram up or if this is a memory leak situation

[schm0]

I have the same high cpu usage issue after sleep on my system. To workaround this, you can create a task that triggers on event -> system -> power-troubleshooter -> ID: 1 to stop and restart ds4windows.

[mika-n]

I have tested the latest version of DS4Windows app with USB connectivity and laptop in idle, in-use and after sleep/resume cycles. I use HidGuardian to hide the original device.

Sleep/Resume worked just fine and when the laptop resumed from a sleep (ie. sleep, not hibernate state) state and CPU load of the DS4Windows process itself was the usual <1-2% (ie. ds4win cpu%, not the overal PC cpu%). RAM consumption increased for a while but the it leveled out and didn't increase dramatically. It is usual that the RAM allocation keeps rising for a while when the DS4Win app is launched, but it should never consume giga bytes of memory because .NET GC should kick in automatically. Of course performance is decreased if .NET spends too much time in GC cycle.

Did you monitor the CPU load of the PC or DS4Windows process? Did yo use Win10 PerfomanceMonitor tool to get a more detailed view than looking at TaskManager?

By the way, PerformanceMonitor allows to monitor .NET garbage collector metrics also (fex ".NET CLR Memory/% time in GC" and "# GC 0-2 Collections"). Those perf counters give a good indication if a .NET app is allocating and releasing objects too fast and too many, so GC cannot keep up with the pace.

If the sleep/resume and CPU consumption issue is because of ViGem device driver and not DS4Win app then it will be very difficult to track down unless someone comes up with a use case to replicate the issue.

Maybe some configuration specific issue has something to do with this? Check at least "Flush Hid" profile option. Don't enable it because if causes extra burden to WinOS HID device driver level.

[RobertoBiundo]

I monitored the process of DS4Windows on the windows task manager. I actually did not think of spending some extra time on a full analysis using the PerfomanceMonitor.

I can also confirm the memory allocation stops at some point (at least in verision 1.6.14 that I decided to keep using as my main). This makes it even more interesting. For me this is around 281.6Mb. There no GC Time before or after this at all.

Also interesting is that I cannot see where the memory allocation goes.

of IL Bytes Jitted Stays at 130.000

Bytes on heap stays the same as well Maybe is some weird .Net behavior.

Anyway memory usage was not the point of this thread. I'll work on the weekend reinstalling the newer versions and looking at CPU usage then

[Ryochan7]

I have a triple boot setup now and sleep works in Windows 7. I have tested putting my PC to sleep while having DS4Windows running and it is working as expected on my machine. There is a minor tweak that I will commit later that might help in cases when the controller threads don't close quickly enough.

The GC will kick in eventually. Server mode garbage collection is enabled in the DS4Windows.exe.config file so the GC is much less aggressive with memory cleanup than normal. Having normal workstation GC mode enabled results in a good increase in input lag. I have not looked in some time but DS4Windows memory usage tops out at about 70 MB on my machine. You can re-enable workstation GC mode by editing the DS4Windows.exe.config file located in the main installation folder. Change the enabled attribute for the gcServer tag to false.

<gcServer enabled="false"/>

One other factor that might result in increased CPU load during normal use is due to how force feedback is handled by the ViGEm library. Each controller now runs a thread in the background listening for notification events from the bus device. Force Feedback used to be handled in the main controller reader thread after the controller state was sent to the bus device. So there will now be +1 thread for each detected controller compared to DS4Windows releases that used ScpVBus.

[RobertoBiundo]

I will just leave this here as a note for anyone in the future.

I tried out the new version 1.7.12 and my CPU usage is now back to 0.1%. Although this did not happen until i reinstalled the VS 2017 - 2019 C++ Redistributable Package.

RAM usage still hovers over the 200Mb. I tried changing the GC type and it reduces the RAM usage. But as pointed out by @Ryochan7 this could lead to increased latency. Do not change this unless you really need the extra RAM. May be the case for upcoming Raspberry 4 builds running windows.

[marcmy]

Installed new version today. Just woke up from sleep.

Edit: tried RobertoBiundo's idea of reinstalling the Vusual C++ Restributables. Same result.

[James-T1]

Same as marcmy above, except mine is a constant 10-20% CPU utilization after waking from sleep in Windows 10 with controller connected to USB. DS4Windows version 1.7.12. I'm using the task scheduler run on wake workaround from schm0. Here's some additional details to get that working:

Setup a task to automatically kill and restart DS4Windows when Windows returns from sleep: General - Run only when user is logged on. Triggers - On an event: Log: System, Source: Power-Troubleshooter, Event ID: 1 Actions - Start program: taskkill /f /im "DS4Windows.exe" Actions - Start program: timeout 2 Actions - Start program: "<>\DS4Windows.exe"

[Slayer5934]

How is this issue not fixed by now? This is a terrible issue to have for literally EVERYONE using this program, I was wondering wtf was going on with stuttering in games and now here I am.. Been over a month now, this should be like # 1 priority..

[Ryochan7]

Can't fix a problem that doesn't exist on my end. How have you not submitted a pull request with the fix yet?

[mika-n]

Define "EVERYONE"? For example, I'm not suffering from this issue, so difficult to say where the problem is. Is it in PC setup, profile settings, DS4Win app, Vigem driver, DS4 connectivity BT dongle (if BT is used) or Win7/10 settings?

And are you referring to a case where CPU load goes high after the PC went through sleep-wakeup procedure? If yes then there is a workaround. Simply re-start the DS4Windows app or attach batch files to do this automatically in sleep and wakeup system events.

Or if you are having a different kind of CPU load issue then why not investigate the issue and provide more details or even a fix to the issue if you can replicate the issue every time by doing certain steps? What are those steps?

If you use bluetooth connection then take a look at Wiki pages of DS4Win app (Troubleshooting tips) for tips about how to tweak BT performance settings in Win7/Win10.

[Ryochan7]

I tried to replicate the issue, and yes it happens while connected via usb. It only stops if close the program, clicking "stop" or "start" on ds4windows doesn't affect the 15% cpu usage... weird bug.

This was the magic comment that got me to look into USB connections specifically. And by coincidence, the problem occurs for me when using a USB connection. BT and Sony Wireless Adapter connections do not exhibit this problem. My primary connection type is the Sony Wireless Adapter although I believe I tested this with Bluetooth in the past as well.

That was information that I could actually use. Now I have a trail to follow to maybe squash this bug. Just complaining with an attitude and underlying entitlement does me no good.

[glorbvr]

I can confirm that the high cpu usage after sleep only happened to me when my controller was connected by usb to my pc. I haven't encountered the issue again after the suggestion of using bluetooth. Now I just connect my DS4 through bluetooth, and keep the controller charging and plugged to my monitor.

[Ryochan7]

The problem really seems to be due to wakeup. Testing only shutdown seems to work. Many tweaks have not helped. Most of the time threads seem to be operating as normal. The only thing that has seemed to help is adding a sleep period on wakeup before starting the control service.

[Ryusennin]

I never use sleep/suspend on my Win7 desktop machine, but I gave it a try with DS4W 1.7.13 and I can confirm that the app constantly uses 8% of my Ryzen 2600X after wake-up (over USB).

No problem with a regular shutdown/restart.

(As a matter of fact, I also have a notebook which I always shutdown instead of suspending. Sleep mode is prone to weird behaviours and IMO useless with an SSD anyway.)

[Slayer5934]

I'm a dev for a very large modpack called Tekxit and also dev a mod called chococraft, I understand that you need information to get a solution and complaining usually wont help at all...

I recently got done quitting a job where I was getting mentally screwed over by a crazy boss who yells at everyone and was also trying to make my wife do things like taking xrays and touching feces while she is possibly preggo, so I'm sorry for how I acted earlier and I hope you will forgive me..

Anyways.. I can confirm that the bug only occurs when my controller is plugged in via usb, and if there's anything I can do to help let me know but it seems you have figured out the issue.. You could have the program itself detect when it's doing something it shouldn't and possibly have it restart itself? Seems like a possible solution, temporarily anyways until you can figure out a permanent fix..

[Ryochan7]

Well the initial change fixed it on my end. Taking another stab at this. Tested this further. I hate to say this but it might legit be a problem with ViGEmBus. The problem never happens when using a profile with the Use DInput Only option enabled. Adding a delay to the ViGEm target connect method, or not calling the connect method at all, also keeps the CPU usage at a normal state. Running the routine normally causes the massive CPU spike despite no detected hung threads in DS4Windows.

I can only guess that something might be happening with the background force feedback thread that the ViGEmClient library creates. Maybe the driver is not ready at that point? I don't have my old setup to test that library directly since reformatting my PC and suspend does not even work on my current Windows 10 install. I have to use Windows 7 to test suspending and I am about to hit the 40 GB limit I set for that partition. Reinstalling would also force me to reinstall Ubuntu as well.

[Ryusennin]

1.7.14 seems to have fixed the CPU usage on my Win7+Ryzen desktop config. I tested a couple of suspend/wakeup and each time DS4W idled at 0%.

[Ryochan7]

The only real related change with 1.7.14 is that I doubled the interval of the initial delay on wakeup. I left the minor routine changes that I was testing in the code but that did not help with the CPU issue.