Fix game stutter on Win 10 1703-1809

That`s strange because there is nothing thread unsafe there.

PS Unless WMI notifications arrive in the same thread as they were subscribed. In that case "lock" will not work as intended (with one thread, but should work when you check from another thread). You can spy to the managed thread ID in handlers. I was under impression that WMI notifications use the thread pool.

 

So far, only using something like this seems quite efficient (at least on my end.):

Process[] processlist = Process.GetProcesses();

foreach (Process theprocess in processlist)
{
//DO something.
}

I'll do some more test preferably on lower end machine to see if there is any negative cost in performance.

 

That`s bad code because it queries all processes in the system. There is better WMI way which queries processes by names. And there is Win API way where snapshot is made and then needed processes are selected by names.
Are you sure you need to account apps launched before ISLC?

 

Not really sure yet. I'll evaluate.
I don't really see why queries all processes in the system is that bad tho. I hate more my foreach loop.

 

To be specific: this code is bad only for periodic polls, it is perfectly fine for one time use. You can get all process IDs by names and add them into the list right before starting the WMI subscription - that should solve problem with apps launched before ISLC.

It happens so that I will work tomorrow, and I will update source code in mediafire with all related source code scattered across my other projects.

 

Hi guys! Can I use the program (ISLC) without fear of the VAC ban and faceit anticheat?

 

The program is not modifying the game in any way, so yes should be very safe IMO.

 

@Wagnard

Updated
http://www.mediafire.com/file/t7h2oueppfhku6v/AppsMonitor.zip/file

I split the code between enumeration of running apps and monitoring of starting/stopping apps.
I implemented 3 variants of enumerators - pure Win API, old WMI code (System.Management), and new WMI code (Microsoft.Management.Infrastructure).
I implemented 3 variants of monitors - old WMI events (System.Management), new WMI code (Microsoft.Management.Infrastructure), and a polling one which just uses one of app enumerators to poll for running apps. Both WMI variants of monitor use enumerator to collect process IDs of already started apps (i.e. one time). Each monitor accepts instance of enumerator in constructor - so you can use any type of enumerator with any type of monitor.

That NuGet package Microsoft.Management.Infrastructure is referenced in solution as <PackageReference Include="Microsoft.Management.Infrastructure">.
It is considered that new code there is lightweight comparing to old one in System.Management - you can evaluate yourself.

 

Thanks man, I'll check that soon !

 

Forgot to test and to mention that may be elevation is not needed for this new WMI code (Microsoft.Management.Infrastructure). (But assembly needs to be distributed along with the ISLC, alas.)

 

Elevation is not a problem because ISLC elevate anyway.
Got an Issue with your code itself tho. Was there with previous version too.
If you run notepad and then start immediately (almost at the same time) you app, it will detect notepad.
Up there its ok.
Close notepad and it wont catch it. Still think it is open, tested multiple time with debugger too and saw that the value " return appIdentifiers.Count" would be random number . Sometime 14 sometimes 27.
There is just 1 notepad or cmd open.

Happens only when your app and the detected app is started almost simultaneously.
Any clues?

Edit: did not test the new poll yet.
Edit2 : Poll doesn't have the issue it seems and I like it so far.

 

Will test tomorrow. Are you sure you have no some processes/scripts launched in cmd.exe? There is no way for appIdentifiers to report 12 or 27 items when it is empty. You can actually browse appIdentifiers itself and consult task manager for processes with process IDs stored there.

PS Do you test my whole app (i.e. all monitors) or do you test monitors one by one?

PPS As for the poll, I assume that Win API enumerator is the most fast and lightweight.

Update: I got an idea on the way from work to home... Will refactor right now...

 

@Wagnard

Updated: an attempt to eliminate the risk of not getting the process ID, and the risk if getting the duplicated process IDs (WMI monitor class and CIM monitor class)
http://www.mediafire.com/file/t7h2oueppfhku6v/AppsMonitor.zip/file

PS I still reckon the combination of WMI or CIM monitor class with API enumerator class as a best solution, but of course you can use (and change) what is best for the needs of ISLC.

 

Thanks, testing.
What ISLC will use is the less CPU intensive option and of course a reliable one too.
Will let you know of the result.

Edit: I implemented the WMI + API enumerator. It's fast and work quite well now.

Edit2: Released on my website:
Changes since 1.0.1.7
- Added a process exclusion list. (All credits goes to Guru3d forum member mbk1969)
- Misc enhancements
SHA1: 9C550DEDF03082D2A91894D803EC7ED7BECBEEFA

The exclusion cannot be modified by the GUI yet. This will be added in a future version.

 

I'm going to give 1.0.1.8 a try, I'll let you know how it goes on my end here.

Thanks for all your work on this so far. It seems to be getting some attention, LevelCap mentioned it in one of his Battlefield 5 videos as being a big help to his stutters as well. I have a couple friends running it as well and it seems to help them also.

 

@mbk1969 @Wagnard

Amazing collaboration!


Kinda sad that it's still needed for certain games though -.-

 

So I'm in the new cod beta, looks like I'm upgrading my windows to 1903 ltsc enterprise, annoying that the only way to get to that is to upgrade windows from a fresh install so install windows twice basically. Here's hoping the memory management is better after all this time if not I'll be back here to try mbks or wagnards useful tools. edit: oh nvm, apparently 1903 for ltsc was a bug on microsofts part, nice. I don't know when it happened but apparently they fixed the memory management it seems like. Probably on one of the recent major feature updates for 1809 and 1903. I'm on win10 enterprise ltsc v1809 and the overcaching of ram isn't present on csgo anymore. EDIT: Looks like I spoke too soon, the cod mw beta seems to overcache standby ram, cs doesn't anymore but....nice.

 

Maybe it's OK for you. I still have to use script to clean memory every 3 sec or I stutter in every game

 

If you want to get rid of stutter without ISLC (thanks to Wagnard for making gaming perfect till i discovered this) the only way is to disable GLOBALLY the exploit protections of w10.
Per app it won't work.
If you think you might have problems with malwares and such just use a third party tool.
Worked for my and my friends on 1903.

 

So your saying if you have any one of the exploit protections enabled under system settings the issue happens but turn them all off and it's not happening?
It's not anyone or a few doing it, that is interesting if true.