EIS 10 Consuming CPU Power Due to PL

[XhenEd]

I recently installed Emsisoft Internet Security 10. Then, I noticed that it consumes 2-4% of CPU power all the time. To cut the long story short, I closed PL just to see if it has something to do with EIS's problem (I know that PL "looks" at processes, so it may trigger AV's anti-tampering protection). To my surprise, it did solve the problem. EIS now is running at 0%, but I closed PL.

I hope this gets fixed, so that I can use both flawlessly. 
Until then, I think I'm gonna hold off using PL (I tried putting PL's processes to exclusion of EIS, but it still doesn't solve the problem). 

[edkiefer]

What happens when you close PL GUI but leave Processlasso governor running ?
were you running graph open with GUI, there are refresh rate settings for both GUI and governor .

[XhenEd]

What happens when you close PL GUI but leave Processlasso governor running ?
were you running graph open with GUI, there are refresh rate settings for both GUI and governor .

You're actually right!
When I close the GUI but not the Governor, EIS calms down. So, the problem is with the GUI. I can still, then, use PL, but without its GUI until it's fixed.

[edkiefer]

ok, so either run GUI so it doesn't run at startup , PL will still do all the work through governor .
You can also set the refresh from default 1sec to 2sec, 5sec etc or whatever you like (you can manually edit ini file value in between too) .

[BenYeeHua]

Thank for the bug report, I think the second workaround is adding ProcessLasso.exe into the ignore list of Emsisoft Internet Security.

[edkiefer]

BenYeeHua , I would say that is number one fix to try first but OP said he tried that already in first post .

[BenYeeHua]

Sorry for that, I am a bit losing my mind, so I somehow can't focus on many thing.

[edkiefer]

Sorry for that, I am a bit losing my mind, so I somehow can't focus on many thing.

Hey, NP, thanks for input, I miss things too 

[Jeremy Collake]

I think your guess that the GUI is triggering EIS's tamper detection is right. Can you give me a run-down of EIS process names? Otherwise, we will of course research ourselves, but this may save time.

Thanks!

[XhenEd]

I think your guess that the GUI is triggering EIS's tamper detection is right. Can you give me a run-down of EIS process names? Otherwise, we will of course research ourselves, but this may save time.

Thanks!

a2guard.exe
a2service.exe

a2service.exe is the one that would consume 2-4% CPU power.

[Jeremy Collake]

Thanks, I've added these to the tamper-proof list as of 8.7.0.3 beta (unreleased), so please let me know how it goes when that version is published (likely tomorrow).

[XhenEd]

I'm running the latest beta, but the problem is still there.  
As soon as I close the GUI, the problem is gone.

One thing I notice also, when the GUI is on, is that EIS calms down if I disable Surf Protection and Behavior Blocker. If I just disable one of them, the problem still persists, but if I disable both of them, the problem is gone.


Edit: I found the solution. I "edited" the Application rule for ProcessLasso.exe to "Don't alert when this file changes". And now, even if the GUI is running, EIS is normal.

So, maybe, there was really no need to include the EIS processes in the tamper detection blocklist.
Maybe, it's really not the tamper protection that triggers the CPU usage, but it could just be EIS "looking" at the processes.

[Jeremy Collake]

I actually did add the two processes you listed in the most recent beta, 8.7.0.5 beta.

There may be other Emisoft processes though? If you can check any log Emisoft has, that may tell us what it's triggering on.

Thanks!

[XhenEd]

I actually did add the two processes you listed in the most recent beta, 8.7.0.5 beta.

There may be other Emisoft processes though? If you can check any log Emisoft has, that may tell us what it's triggering on.

Thanks!

Actually, there is one. I forgot about this one because it closes when the GUI is put to the tray.
a2start.exe


But, there is no problem already. I think PL can't do anything to stop the CPU usage of EIS.
I think it's by design of EIS to monitor every process. Since PL constantly looks at processes, EIS might also be constantly looking at PL's behavior. I already put the PL's processes into exclusion of EIS, but the problem is still there. So, I think the problem is with EIS, not with PL. I checked the "Don't alert when this file changes" in the Application rule for PL in EIS. After that, all is well even if PL's GUI is on.

But, of course, correct me if I'm wrong. 

[edkiefer]

Do you get similar results if you run Process explorer ?

That might show if EIS affects that to.

[Jeremy Collake]

I added the a2start.exe tamper-exclusion in v8.8 final, which is building now. It may or may not have any impact on Emisoft's issues, but better safe than sorry. Thanks!

And note that security software often treats 'common' task managers like Process Explorer a bit differently, so it's not necessarily a valid test.

[BenYeeHua]

Yup, it should be the CPU usage for monitoring the behavior of PL, and it is good to see the security software supported this feature, so that it can detect unknown virus based on the behavior of the process, like modifying a lot for doc, pic = CryptoLocker.

[XhenEd]

Do you think that I should report this to Emsisoft, so that they can, at least, do anything about it? I'm sure there are also EIS or EAM users who also use Process Lasso. They might be experiencing this problem with or without their knowledge. 

Edit: I just want to report that, surprisingly, EIS isn't acting bad even if I unchecked the "Don't alert when this file changes". So, meaning, excluding the three processes of EIS from PL might have been the solution.
Thanks, Jeremy!

[Jeremy Collake]

It couldn't hurt to report it to them. After all, even if it's their tamper detection crap, it's triggering when Process Lasso only *looks* at their process with read-only rights, *AND* it's doing so in a way that 'floods' their log. In other words, they keep repeating the same tamper detection event over and over to infinity. Of course, that is only an assumption since I haven't checked it out myself.

That said, it will depend on what kind of company they are as to if reporting to them accomplishes anything in our lifetime ;p.

I'll definitely check this myself in a test bed for a first-hand look, just haven't had a chance yet with everything else going on, the new site, and ParkControl Pro.. so busy.

[XhenEd]

I finally had a time to report this problem to Emsisoft.
The link to my thread at Emsisoft forums is this: http://support.emsisoft.com/topic/18705-eis-consuming-cpu-because-of-process-lasso/

It's confirmed that the problem is because of EIS. A staff of Emsisoft said that putting ProcessLasso.exe into EIS's whitelist will solve the problem. But the problem will appear again after a system restart because whitelisting (exclusion) of the processes only works if EIS loads before the whitelisted processes. Since ProcessLasso.exe loads before EIS, then the problem about EIS consuming CPU power resumes. And this behavior of EIS needs a major release from Emsisoft before there will be a fix.

So, I think, as long as I use Emsisoft products, I'll have to disable the auto-start of PL's GUI. At least, however, I will still be able to take advantage of Process Lasso because of the Governor. 

[Jeremy Collake]

Well at least they responded .

Even though the issue is with EIS, I am still attempting to work-around it. So you're still seeing it? Any other processes I should add to the tamper-detection avoidance list?

[XhenEd]

Well at least they responded .

Even though the issue is with EIS, I am still attempting to work-around it. So you're still seeing it? Any other processes I should add to the tamper-detection avoidance list?

I think the workaround really is to delay the startup launch of PL's GUI. I'm just about to test this using Startup Delayer. 

Edit: I have no luck modifying the startup order of PL. Anyway, I can live with having only the Governor running in the background. The problem now is not really deal breaker since the problem is gone as long as I would manually run ProcessLasso.exe.

[Jeremy Collake]

I guess I will need to install a trial of EIS 10 and find out what process it's still triggering on. It shouldn't be a problem.

[XhenEd]

This is what Fabian, an Emsisoft employee, said in the forums:

The problem is not that they [Process Lasso] are looking. The problem is that they are opening a whole bunch of processes with rights that allow them to modify and change the process in rapid succession over and over again.

So, I think Fabian does not believe that it's tamper detection that enables high CPU usage. He believes that PL's behavior that is detected by EIS enables that CPU usage.

High CPU usage is solved through whitelisting. But it is not persistent. After a system restart, EIS would return to consuming 2-5% of CPU usage. And Fabian said that it's because EIS needs to load first before before any whitelisted processes. If a whitelisted process loads first before EIS, then EIS wouldn't apply its whitelisting to that particular process. This is what happens to ProcessLasso.exe.

They are planning to change this behavior of their products with their next major release, which will take, more or less, a year (I think).

[BenYeeHua]

The problem is that they are opening a whole bunch of processes with rights that allow them to modify and change the process in rapid succession over and over again.

Well....
Are we talking the same software?

[XhenEd]

Well....
Are we talking the same software?

I believe Fabian is still talking about Process Lasso when he said that.

Is that not what PL does?

[Jeremy Collake]

We open processes with minimal read-only rights. I am not sure what privilege they are flagging to be honest, but I'd like to know.

We don't go around opening processes with full access, or even intentional write access of any kind, unless some operation is to be performed on it.

I would guess there is some 'in the middle' benign permission they are flagging. To get certain information about running processes, we have to look at their virtual memory, for instance. That may be it.

Of course, in any event, yes, Process Lasso monitors running processes, so it does have to look at them. I would say that EIS's tamper detection system response to *any* scenario should:

1. Include throttling to reduce repetitive events
2. Have white-listing that is persistent

So, we could play the 'blame game', but I'd prefer not to do that. I intend to evaluate EIS myself and will simply exclude whatever processes of theirs that I've missed thus far. It will no longer be listed by Process Lasso, but that's alright.

[Jeremy Collake]

Ok, I have EIS installed in a test bed. It actually seems to do alright with the last Process Lasso final (v8.8.2), though I have now also added 'a2wizard.exe' to all future builds.

Note that if you do NOT see any more *repetitive* and *continual* Process Lasso tamper detection events in EIS, then the CPU consumption by EIS may NOT be related to Process Lasso (issues already fixed).

Security suites like this always have a fairly heavy footprint since they have to do so much real-time scanning.

Originally there was surely an issue with Lasso setting off it's tamper detection repetitively, but testing the most recent final build of Process Lasso, I don't see any interoperability issue due to the previously added exclusions.

There may be some sporadic cases where Process Lasso trigger's EIS's tamper detection, but a few events in its log is nothing. The only *problem* is when EIS starts logging repetitive events, continually, without throttling them in any way, which *can* lead to excessive CPU use.

All security suites have heavy footprints, so will inherently consume a lot of system resources.

[XhenEd]

Ok, I have EIS installed in a test bed. It actually seems to do alright with the last Process Lasso final (v8.8.2), though I have now also added 'a2wizard.exe' to all future builds.

Note that if you do NOT see any more *repetitive* and *continual* Process Lasso tamper detection events in EIS, then the CPU consumption by EIS may NOT be related to Process Lasso (issues already fixed).

Security suites like this always have a fairly heavy footprint since they have to do so much real-time scanning.

Originally there was surely an issue with Lasso setting off it's tamper detection repetitively, but testing the most recent final build of Process Lasso, I don't see any interoperability issue due to the previously added exclusions.

There may be some sporadic cases where Process Lasso trigger's EIS's tamper detection, but a few events in its log is nothing. The only *problem* is when EIS starts logging repetitive events, continually, without throttling them in any way, which *can* lead to excessive CPU use.

All security suites have heavy footprints, so will inherently consume a lot of system resources.

There are actually no "logs" found in EIS. The logs in EIS are just about the rules created and modified.
Try a system restart.

[Jeremy Collake]

Sorry, I have dealt with tamper detection issues of other security suites, so assumed it did have a log somewhere it is writing to. It may do so and not display it to the user.

I'm updating that test bed and will try a restart.

These exclusions I've added cause Process Lasso to not even *touch* the Emisoft processes, and I think I've hit all the resident ones. a2wizard.exe, of course, only runs during the setup, and is now added as of 8.8.3.3-beta.

Definitely this *was* an issue in older versions. The question now is whether it is still an issue.

BUT, without the logs, what makes you think the CPU use is from Process Lasso interacting with it? Is there some other way you are correlating the apparent excessive CPU use of EIS processes (which of course can fluctuate dramatically depending on what it's doing) with Process Lasso?

If you're unsure, you may want to try uninstalling Process Lasso for a day or two, and see if there is any real change to EIS's CPU use.

[XhenEd]

Sorry, I have dealt with tamper detection issues of other security suites, so assumed it did have a log somewhere it is writing to. It may do so and not display it to the user.

I'm updating that test bed and will try a restart.

These exclusions I've added cause Process Lasso to not even *touch* the Emisoft processes, and I think I've hit all the resident ones. a2wizard.exe, of course, only runs during the setup, and is now added as of 8.8.3.3-beta.

Definitely this *was* an issue in older versions. The question now is whether it is still an issue.

BUT, without the logs, what makes you think the CPU use is from Process Lasso interacting with it? Is there some other way you are correlating the apparent excessive CPU use of EIS processes (which of course can fluctuate dramatically depending on what it's doing) with Process Lasso?

If you're unsure, you may want to try uninstalling Process Lasso for a day or two, and see if there is any real change to EIS's CPU use.

I know that it's ProcessLasso.exe because whenever I close that process during EIS's abnormal CPU usage (2-5% CPU usage), EIS's process (a2service.exe) goes to normal (0% CPU usage).

[Jeremy Collake]

Ok, great, I was going to suggest simply closing Process Lasso, but I would not have expected such a dramatic difference.

Please allow me some time to verify this and see what in the world is going on so I can give a more certain answer without haphazardly guessing and making these rapid-fire posts.

Thanks!

[XhenEd]

Ok, great, I was going to suggest simply closing Process Lasso, but I would not have expected such a dramatic difference.

Please allow me some time to verify this and see what in the world is going on so I can give a more certain answer without haphazardly guessing and making these rapid-fire posts.

Thanks!

Okay, take your time, Jeremy. This is not really a very big issue for me. It has a workaround, so I'm not really sad about this.
Thanks for your hard work, Jeremy!

Edit: I tried pausing the Refresh Interval of the GUI. And it seems that it solved the problem.

[BenYeeHua]

It will be interesting to know why this happen, as security software is always a mystery for most user.

[Jeremy Collake]

Edit: I tried pausing the Refresh Interval of the GUI. And it seems that it solved the problem.

This makes sense. That, well, pauses the GUI's refresh of the processes. You can still hit F5 to refresh the view.

It seems EIS keeps a watch on *everything* going on with the system. I'm still evaluating it fully, but man it definitely injects it's hooks everywhere. Therefore, what is setting it off may not be any tamper-detection mechanism, as was the case with other security software, but rather simply that it is having to deal with so many 'open process' operations that it can't efficiently handle (or not efficiently enough).

Lowering the refresh rate, instead of pausing it entirely, will also work.

If I can't create a fix, I'll at least do something to mitigate the problem, such as automatically reducing the refresh rate when EIS is detected.

[XhenEd]

This makes sense. That, well, pauses the GUI's refresh of the processes. You can still hit F5 to refresh the view.

Lowering the refresh rate, instead of pausing it entirely, will also work.

If I can't create a fix, I'll at least do something to mitigate the problem, such as automatically reducing the refresh rate when EIS is detected.

Okay, thanks! But I really hope it will work even after system restarts. I'll test this later today. Thanks, Jeremy!
But, really, Emsisoft must be the one to fix their own security software. The exclusion for PL works. But it doesn't persist after system restart. Sadly, they are going to fix this behavior on their next big release, which will take maybe more (or less) than a year.

It seems EIS keeps a watch on *everything* going on with the system. I'm still evaluating it fully, but man it definitely injects it's hooks everywhere. Therefore, what is setting it off may not be any tamper-detection mechanism, as was the case with other security software, but rather simply that it is having to deal with so many 'open process' operations that it can't efficiently handle (or not efficiently enough).

This was and is my point. Only that, you said it better.
About EIS hooking everywhere, yes, some security "experts" in the Wilders forums noticed it too. It's maybe for EIS' Behavior Blocker.


Edit: Even if I put the refresh rate to 2 seconds or more, the problem would still be present after system restart. I really think that we can't do anything about this until Emsisoft releases a fix.

[Jeremy Collake]

OK, what I've got on the agenda presently, for a partial solution, is to reduce the GUI refresh rate to 5 seconds (from 1 second default) when EIS is detected. This isn't a full solution, but is a good start, as it will cut EIS load caused by Process Lasso substantially.

Is it just me or does EIS seem to really drag the system down in general? It *may* just be my virtual machine.

[XhenEd]

OK, what I've got on the agenda presently, for a partial solution, is to reduce the GUI refresh rate to 5 seconds (from 1 second default) when EIS is detected. This isn't a full solution, but is a good start, as it will cut EIS load caused by Process Lasso substantially.

Is it just me or does EIS seem to really drag the system down in general? It *may* just be my virtual machine.

Thanks, Jeremy! But I think I'm gonna just close the GUI because it stops the EIS' CPU usage. But your partial solution is good for those Emsisoft users who also use Process Lasso.

I don't think EIS is dragging my system down. However, I notice that my system restart is slower than usual after I installed EIS. Someone reported it already, and the Emissoft team said that they would look into it.

[Jeremy Collake]

Yes, it's the system restart that seems a bit slugglish in particular, probably as EIS builds it's scan cache, or loads it into memory from prior scans. Once built, it then doesn't have to rescan all those objects, so then is faster (guessing)...

Anyway, keeping the GUI closed is certainly a fine and appropriate solution. If I can figure a way to adjust the process operations to not trigger EIS at all, I will do so, but that's more major work I'll have to reserve for v9 .. which is coming soon.

[XhenEd]

Yes, it's the system restart that seems a bit slugglish in particular, probably as EIS builds it's scan cache, or loads it into memory from prior scans. Once built, it then doesn't have to rescan all those objects, so then is faster (guessing)...

Anyway, keeping the GUI closed is certainly a fine and appropriate solution. If I can figure a way to adjust the process operations to not trigger EIS at all, I will do so, but that's more major work I'll have to reserve for v9 .. which is coming soon.

Thanks for the hard work, Jeremy! 

[BenYeeHua]

I don't think EIS is dragging my system down. However, I notice that my system restart is slower than usual after I installed EIS. Someone reported it already, and the Emissoft team said that they would look into it.

This is normal, except you want to get virus not detected while booting.

Some anti-virus just delay the loading of the monitoring(and also engine) for booting, so they are completely useless for 1-2 min after booting.

[arcanum]

This is normal, except you want to get virus not detected while booting.

Some anti-virus just delay the loading of the monitoring(and also engine) for booting, so they are completely useless for 1-2 min after booting.

Completely useless 1-2 min after booting? Do you have papers for that? As far i know, at least my firewall driver runs on a "ring 0" kernel drive mode. So the driver denys all arp etc connections during boot up.
But im happy with my Eset Smart Security + PL Combo. No stupid tampering vice and versa Althought Eset processes can be terminated quite easilly...oh well..

But what about Jeremy...the best indie coder i ever know...one man coder with the best support for the customers. Jeremy, for my cents, Emsisoft are also bunch of individuals, mebbe your kernel coding skills...you know the rest. Remember, im not involved with Emsisoft. But Emsisoft is bunch of an individuals. Peter Ferrie is a god of assembly. Nuff said.

-arc

[4EverMaAT]

can users edit the tamper-proof list?

[edkiefer]

No, not at this time.

[parkd1]

Hmmmm just an idea. Maybe add edit tamper-proof list to version 9.

[BenYeeHua]

Completely useless 1-2 min after booting? Do you have papers for that? As far i know, at least my firewall driver runs on a "ring 0" kernel drive mode. So the driver denys all arp etc connections during boot up.

Nope, but you can try, their name are 360 TS or 360 TSE or 360安å...¨å«å£« or 360杀æ¯'.(of cause it is under the same company)

You can check that, their virus definitions and engines files will be loaded after the boot, but they may using cloud engine before the local engine loading?
I will not trying to test a virus to prove that.

And yup, they don't has Firewall too, because the Windows Firewall is too strong enough, which blocking all of the connection/programs that are not added into the white-list.

[BenYeeHua]

Hmmmm just an idea. Maybe add edit tamper-proof list to version 9.

Ya, for user to testing it easily, so they will know did it will be avoided after they added the anti-virus processes into it, then it can just hard-coded into the list.

[Jeremy Collake]

@park1d: This isn't a simple addition to the tamper-proof list, unfortunately. Emisoft seems to be going nuts on *every* process Process Lasso looks at, not just it's own. That was the first thing I tried .

What BenYeeHua means is that most security suites are cloud based these days, and thus they have to get their latest update from the cloud, which may not occur until a few minutes after boot.

Keep in mind, once you are infected, any security software is usually completely useless at cleaning your PC. You really have to reinstall Windows to be sure of anything.

Security software itself has a terrible track-record. Look at the malware problems in the world. That isn't because people are running out of date security software, it's because malware is custom-crafted to always bypass the latest security software. Meanwhile, as security software ramps up to try to detect all possible threats, they end up with a bunch of false positives. So, it's a dubious proposition. To stay safe online, you really have to behave safe online, and even then, do quarterly reinstalls/re-imaging of Windows (imho). Better yet, always browse from within a virtual machine.

Anyway, it's a difficult issue to address here, but the *only* solution I've come up with so far is to automatically decrease the GUI refresh rate when EmiSoft is detected.

[BenYeeHua]

Yes, it is because anti-virus is too strong for any malware, so they focus on bypass the anti-virus as they can, like "This is a Keygen/Crack/Patch and it will be false reported by anti-virus, please disable your anti-virus before download it.", then the user just trust it and boom!

So it is really mainly a user issues, not a anti-virus issues, unless it has a unclear name on it, they normally reporting like this.(you can also saw some anti-virus just listed as Trojan while it is not...)

1.HackTool.Keygen (Not a Virus)
2.HackTool:Win32/Keygen

https://www.virustotal.com/en/file/b2bbd0a45236a05614cd531c5e44c419c74968be49986e65e75a5d7877c1fcdf/analysis/

And that's why normally PUP(Potentially unwanted program) detect are not enabled as default, because user can't understand how anti-virus works, and using it smartly.

Remember, anti-virus is still a tools that told you there is something wrong, and it is you to decide which one you/it will do.

What BenYeeHua means is that most security suites are cloud based these days, and thus they have to get their latest update from the cloud, which may not occur until a few minutes after boot.

And nope, they did loaded the engine after the boot, as their engine are not inside the driver, but just a dll.(unless I am wrong)
I guess it is because China user love lightweight anti-virus(by judge it with the system boot time first, then Memory usage etc...), and that's the effect of it.

---Edit
And yes, there are more.

My friend said that the laptop is booting slow, and I check for it, it is because of Avast want to finish booting first, then it will allow the other software to start booting, so that it can monitor them.

I also found that, in the Printer/Photocopy Shop, they has Kaspersky, but it is expired long time ago.

So as you can see, it is really just the user don't understand about anti-virus, and also don't know how to maintain it...
That's why you can see that, Windows 10 forcing user to keeping their Windows 10 up-to-date now.

Except Kaspersky which causing a lot of bug for Windows after Windows 8.

[Jeremy Collake]

Oh, I didn't realize that some security suites literally were user-mode scanning only, or deferred scanning until post-boot. It makes sense, as none of them want to be held responsible for slow boot times. I haven't fully audited all security suites by any means, because I don't use any. I often have Windows Defender turned off even. I never have problems, because I don't rely on the false sense of security that security suites bring.