ACS.exe and Config Disappearing

[admiralspeedy]

I love Process Lasso because it lets me set change my power profile automatically when I play games. I have paths setup for all of major game folders (Steam, Origin, Uplay, etc) and it works great except for two problems.

The first problem is with the config. I keep a backup of it because randomly I'll open PL to check things out and notice that my settings aren't right and then I check an all of my application power profiles are gone. I think this happens when the program updates and it means I have to import my config a lot.

The second issue is with the blacklisted process names. I noticed that no matter what, my application power profile setting would not work for Assassin's Creed Syndicate (ACS.exe) and doing further testing, it doesn't work for any process named ACS. I did some Googling and found out that you guys added ACS.exe to the list of tamper-proof processes way back some time in version 7. I understand that this was done because some antivirus had this name and caused issues. Can you please expose this list and let us allow processes that have been blacklisted? I don't use that anti virus and it simply hinders me for no reason.

[edkiefer]

I love Process Lasso because it lets me set change my power profile automatically when I play games. I have paths setup for all of major game folders (Steam, Origin, Uplay, etc) and it works great except for two problems.

The first problem is with the config. I keep a backup of it because randomly I'll open PL to check things out and notice that my settings aren't right and then I check an all of my application power profiles are gone. I think this happens when the program updates and it means I have to import my config a lot.

The second issue is with the blacklisted process names. I noticed that no matter what, my application power profile setting would not work for Assassin's Creed Syndicate (ACS.exe) and doing further testing, it doesn't work for any process named ACS. I did some Googling and found out that you guys added ACS.exe to the list of tamper-proof processes way back some time in version 7. I understand that this was done because some antivirus had this name and caused issues. Can you please expose this list and let us allow processes that have been blacklisted? I don't use that anti virus and it simply hinders me for no reason.

I'll have to check on the ACS.exe but one thing you should do is make sure you only use one type of trigger for a power plan.
Meaning if its a game, just use game mode and set power plan there, don't have any app that are games to be in the "configure application power plan" option of PL.
Only use one or other .

[Jeremy Collake]

Wow, these are some odd reports, and I'm very sorry for your experience.

Let us clean them up for you, then all will be right in the world! We appreciate your patience with this.

First, we need to identify what is going on. So, your actual INI file settings seem changed every once and a while? Is that correct? Changed to default (essentially empty), or something else? Or is just a power plan change you are seeing?

As you researched/know, most games have fairly sophisticated self-protection mechanisms that resulted in me deciding it's best for Process Lasso to just ignore them. After all, the focus of ProBalance is on keeping everything *else* in check.

I will at least publish a beta early next week that removes this game from the tamper-proof list, as an immediate action, and make another attempt to get rid of that list in it's entirety by identifying and complying with the restrictions of every app on that list, a labor intensive process, but one well worth it. Only issue is we then have to track updates to those apps. Maybe the community can help with that.

[admiralspeedy]

I'm incredibly impressed at how fast you replied.

I'll have to check on the ACS.exe but one thing you should do is make sure you only use one type of trigger for a power plan.
Meaning if its a game, just use game mode and set power plan there, don't have any app that are games to be in the "configure application power plan" option of PL.
Only use one or other .

I don't really like the game mode system so I don't use it. The way I have it set up is with wildcards in the normal "Configure application power profiles" setting.

An example being "d:\program files\steam\steamapps\*\*.exe" which changes the power profile to High Performance whenever an execetuble launches from steamapps, which is always a game. I have this set up for my Origin folder and Uplay folder as well as a few standalone games. It however is not the issue with ACS.exe, as confirmed by the other poster in this thread and it works fine for every other game I own.

Wow, these are some odd reports, and I'm very sorry for your experience.

Let us clean them up for you, then all will be right in the world! We appreciate your patience with this.

First, we need to identify what is going on. So, your actual INI file settings seem changed every once and a while? Is that correct? Changed to default (essentially empty), or something else? Or is just a power plan change you are seeing?

As you researched/know, most games have fairly sophisticated self-protection mechanisms that resulted in me deciding it's best for Process Lasso to just ignore them. After all, the focus of ProBalance is on keeping everything *else* in check.

I will at least publish a beta early next week that removes this game from the tamper-proof list, as an immediate action, and make another attempt to get rid of that list in it's entirety by identifying and complying with the restrictions of every app on that list, a labor intensive process, but one well worth it. Only issue is we then have to track updates to those apps. Maybe the community can help with that.

Yes, the INI file reverts to default. Probably half a dozen times now I've opened up PL to add a game folder to the power profile list and all of my settings will be back to default and all the power profile rules I have set are just totally gone. I started keeping a backup of the INI and just import it whenever this happens now. It actually happened yesterday and I believe it happened right after I updated the program.

[edkiefer]

I'm incredibly impressed at how fast you replied.

I don't really like the game mode system so I don't use it. The way I have it set up is with wildcards in the normal "Configure application power profiles" setting.

An example being "d:\program files\steam\steamapps\*\*.exe" which changes the power profile to High Performance whenever an execetuble launches from steamapps, which is always a game. I have this set up for my Origin folder and Uplay folder as well as a few standalone games. It however is not the issue with ACS.exe, as confirmed by the other poster in this thread and it works fine for ever other game I own.

Ok, then just make sure game mode is upchecked along with changing power profiles in game mode option

Yes, the INI file reverts to default. Probably half a dozen times now I've opened up PL to add a game folder to the power profile list and all of my settings will be back to default and all the power profile rules I have set are just totally gone. I started keeping a backup of the INI and just import it whenever this happens now. It actually happened yesterday and I believe it happened right after I updated the program.

That is weird, I never had that happen , did you change the default path for the logs/config.ini and what OS is this ?

[admiralspeedy]

About the default path, yes and no. When I install Windows I use a script to relocate the entire user folder to my secondary drive so that appdata and user files aren't filling up my primary SSD. However, the actual path is the same, just a different drive letter and it's set that way in Windows so it should not have any effect on PL.

This happens in Windows 8.1 and 10.

[Jeremy Collake]

I use junction points a lot myself, and you're right, they shouldn't matter.

However, something is making a difference. The update process should never kill the configuration. I need to spend some time thinking about this, then we may need to send a debug build so we can capture a debug trace/log about why it's doing what it is doing.

Do you have this in a state where you can reproduce it at-will by chance? Is it seen every update? This is definitely a new one to us, I've never heard a similar report.

[admiralspeedy]

I use junction points a lot myself, and you're right, they shouldn't matter.

However, something is making a difference. The update process should never kill the configuration. I need to spend some time thinking about this, then we may need to send a debug build so we can capture a debug trace/log about why it's doing what it is doing.

Do you have this in a state where you can reproduce it at-will by chance? Is it seen every update? This is definitely a new one to us, I've never heard a similar report.

I'm not able to reproduce it myself. It just kind of happens.

[Jeremy Collake]

I can say that *if* Process Lasso was unable to open the configuration file, a default one would be created (and later saved).

Is the disk you have the junctions pointing to always mounted? e.g. no TrueCrypt partition that is dynamically mounted? Or removable drive?

Once we go through this, we'll surely figure it out. Thanks for your continued patience.

[admiralspeedy]

It's always mounted. It's a RAID 0 configuration of two 1TB Seagate drives.

I really think the only way to actually figure it out would be to have a debug build that logs when the config file is changed.

[Jeremy Collake]

There is also Process Monitor (procmon) from SysInternals. You'll need some filters, of course, else it will be overwhelming, but it will reveal every attempted access to the INI config file, and we can see if there is a failure.

As for a debug build - I will publish a new one later today. An old one is available here: https://bitsum.com/files/debug/processlassosetup64.exe . Now, whether or not the right debug logging is even emitted is questionable, but I can add more output if not. I haven't targeted this problem since we've never seen issues in this part of the code.

BTW, as for ACS, are you aware of the menu option 'Options / General / Ignore problematic processes'? If you uncheck that, it should have unfettered access to that process.

[admiralspeedy]

BTW, as for ACS, are you aware of the menu option 'Options / General / Ignore problematic processes'? If you uncheck that, it should have unfettered access to that process.

I tried that before I started this thread and it didn't work, it actually caused Process Lasso to randomly crash whenever I opened the UI.

[Jeremy Collake]

Ah, and that is why the process made it to the list. It's protection mechanism causes the crash, or otherwise manifests it.

[admiralspeedy]

It crashes even if ACS is not running though.

[Jeremy Collake]

There is most likely a separate infrastructure for the actual protection. The game doesn't do that *itself*. I would imagine a system service controlling a device driver, and even a session-mode process and globally mapped hook DLL to inject into other processes. This would cover all levels. It may even hide it's presence like a rootkit.

If you really wanted to find out, you could uninstall that game and see if it still crashes I suppose. That's assuming it removes whatever crap is protecting the game.

[admiralspeedy]

I don't think the game is doing that. I must have another "problematic process" that doesn't like PL.

Anyhow, the whole config thing is really not that big of an issue so I wouldn't focus on it. I will keep checking PL regularly and see if I can determine what action causes the config to disappear.

I'm honestly more concerned with Assassin's Creed.

[Jeremy Collake]

I will have to run ACS in a test bed to know for sure. Until then, it's all speculation. I can only say that crashes are not normal with that setting on or off .

The config issue definitely is something more important. Did you download the debug build? https://bitsum.com/files/debug/processlassosetup64.exe . It may not be the latest (now), but I'll keep updating it. You will need to run DebugView in the background and collect what will be a good bit of logging. You can limit history depth to X to help deal with the virtual memory use of DebugView during long-term logging. Once the issue occurs, save the log and post it here, or send it to me at jeremy@bitsum.com for more privacy. Then I'll see if it has a clue. if not, I'll go through the code and add some more debug tracing around applicable code.

Then there is the Process Monitor I mentioned - but it has an even bigger issue with 'too many events', so will be more useful if you have managed to reproduce the issue 100% of the time. In fact, if you found a scenario where it always happened, then that would be the fastest path towards resolution.

Hopefully we can figure it out, it's a bit disconcerting to hear the config being wiped out like that.

[Hotrod]

acs.exe is also the name of one of Agnitum's Outpost security software files as well as Atheros WLAN driver set. Could this be a side effect of Agnitum processes being dealt with internally?? 

[Jeremy Collake]

That is a very good observation Hotrod!

Please hold and I will see if I can dig up the rationale for the addition of ACS.EXE to the 'tamper-proof list'.

Similar to admiralspeedy though, I'm more disturbed by the possibility of a configuration loss under any scenario. It should never happen. I am auditing the code now, will pinpoint any possible logic paths that could cause this, and we'll try to identify what is going on.

I'm also going to add a safety in v9 to detect the loss/reset of a configuration, perhaps this will let us catch any anomaly in testing for users that may not have otherwise noticed.

[Jeremy Collake]

Hotrod called it right - ACS.EXE was originally added to the tamper-proof list as part of Agnitum's Firewall, per this thread: https://products.bitsum.com/forum/index.php?topic=4509

Whether any game protection, or any issue exists at all, with Assassin's Creed Syndicate ACS.EXE is UNKNOWN, but seems unlikely. We will have to test it in a test bed.

Also, it's unclear whether there is even any serious issue with Agnitum's Firewall that would warrant it being on the tamper-proof list. It may just need to be a ProBalance exclusion. Again, we'll have to set up a test bed.

We already have new technology to better differentiate processes instead of relying on filenames, but it has not been introduced into v8 - it was put off until v9. Fortunately, v9 alpha is beginning, so I'll integrate this ASAP.


EDIT: Also note that we've tested the 'Ignore problematic processes' feature and found so far found NO PROBLEM with it disabled (we are continuing extended testing). Process Lasso will restart itself after it's toggled, which might be seen as a crash? Otherwise, it should work. The fact that a crash happens when this is toggled off may be related to the odd issue with the config reset. The whole situation smells of something strange, and I hope we find out what.

[admiralspeedy]

Like I said, I must have another process running on that problematic list. I've actually confirmed that ACS works fine if I rename it to ACS2.exe. It triggers my power profile settings fine. However, doing this breaks launching it through Uplay and updates unless I rename it back to ACS.

I will install that debug version if you'd like, but I'm not sure what information you want from it.

EDIT: The problematic process crash doesn't seem to happen now. I know it restarts but then moments later it was crashing with a "Stopped Working" Windows dialog and I tried it like four times that night and it did it every time, even without ACS running. Also, I don't think the problematic process thing is related to the config. The first time I ever even toggled that setting was when I was trying to get ACS working and I had the config disappear several times before.

[Jeremy Collake]

Well, none of the processes on that list should cause a crash, so I am just wondering what is going on. It could be some DLL mapped into Lasso's address space and causing trouble doing whatever it is doing - that has been known to happen. You could check the list of loaded modules into ProcessLasso.exe with Process Explorer.

In the debug version, if a crash occurs, you may get some data. Otherwise, there is going to be a mountain of data via DebugView, and until we can replicate the INI config reset, there is nothing to look for. When the INI reset next happens though, save the entire log and I can go through it to check for any relevant events.

I would recommend updating it every couple days by manually re-downloading it. I'll keep it moving forward and maybe add some new log events.

The 'INI reset detected' mechanism is something I will add very early in v9 alpha, to the point it may be our best hope of pinpointing what is going on. At least then you, or anyone affected, will know when this occurs without having to notice by accident.

[admiralspeedy]

Ok, also check my edit above for some more info.

I will install the debug version and keep an eye on it.

As a programmer, this really intrigues me