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). :(
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 .
Quote from: edkiefer on August 17, 2015, 05:54:27 AM
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.
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) .
Thank for the bug report, I think the second workaround is adding ProcessLasso.exe into the ignore list of Emsisoft Internet Security. :)
BenYeeHua , I would say that is number one fix to try first but OP said he tried that already in first post .
Sorry for that, I am a bit losing my mind, so I somehow can't focus on many thing. :P
Quote from: BenYeeHua on August 19, 2015, 10:50:50 AM
Sorry for that, I am a bit losing my mind, so I somehow can't focus on many thing. :P
Hey, NP, thanks for input, I miss things too ;D
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!
Quote from: Jeremy Collake on August 19, 2015, 12:41:10 PM
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.
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).
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. :D
So, maybe, there was really no need to include the EIS processes in the tamper detection blocklist. :D
Maybe, it's really not the tamper protection that triggers the CPU usage, but it could just be EIS "looking" at the processes.
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!
Quote from: Jeremy Collake on August 20, 2015, 08:00:55 PM
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. :D I forgot about this one because it closes when the GUI is put to the tray. :D
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. ;D
Do you get similar results if you run Process explorer ?
That might show if EIS affects that to.
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.
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. :)
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!
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.
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/ (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. ;D
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?
Quote from: Jeremy Collake on September 02, 2015, 09:53:02 AM
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.
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.
This is what Fabian, an Emsisoft employee, said in the forums:
QuoteThe 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).
QuoteThe 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? ;D
Quote from: BenYeeHua on September 03, 2015, 03:46:48 PM
Well....
Are we talking the same software? ;D
I believe Fabian is still talking about Process Lasso when he said that.
Is that not what PL does?
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.
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.
Quote from: Jeremy Collake on September 03, 2015, 07:39:52 PM
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.
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.
Quote from: Jeremy Collake on September 03, 2015, 08:24:38 PM
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).
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!
Quote from: Jeremy Collake on September 03, 2015, 08:35:58 PM
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. :D
Thanks for your hard work, Jeremy! :D
Edit: I tried pausing the Refresh Interval of the GUI. And it seems that it solved the problem.
It will be interesting to know why this happen, as security software is always a mystery for most user. :D
Quote from: XhenEd on September 03, 2015, 08:38:48 PM
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.
Quote from: Jeremy Collake on September 07, 2015, 03:48:38 PM
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. :D 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.
QuoteIt 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. :D
About EIS hooking everywhere, yes, some security "experts" in the Wilders forums noticed it too. :D 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.
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.
Quote from: Jeremy Collake on September 09, 2015, 03:44:13 PM
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.
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.
Quote from: Jeremy Collake on September 10, 2015, 12:45:58 AM
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! ;)
QuoteI 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.
Quote from: BenYeeHua on September 10, 2015, 04:59:27 PM
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
can users edit the tamper-proof list?
No, not at this time.
Hmmmm just an idea. Maybe add edit tamper-proof list to version 9.
Quote from: arcanum on September 13, 2015, 12:06:00 PM
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. ;D
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. ;)
Quote from: parkd1 on September 23, 2015, 11:09:16 AM
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. :)
@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.
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! ;D
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/ (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.
QuoteWhat 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... :P
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. ;D
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.
Yes, and the bad thing is, the false sense/alarm always reporting the files with a heuristic analysis definition/name on it, so you never know if they are right or not... :P
Windows Defender also has weak spot, which don't detect low risk malware, and also hang the system while scanning exe, it did cached the scan result, but it is cleaned up after reboot, so it will be hang again after reboot. :P
---
And also one thing, the new type of Pen drive virus are smart now, they know the anti-virus only scan for special file types, so they just rename into random names with random file type(like awenoinisadw), then just create a shortcut to run it with rundll32.exe . ;)
Unless they scan unknown files loaded by rundll32.exe, then the anti-virus is useless for this type of virus, even they can detect this type of virus. :P
And anti-virus also don't unhide the files that has been hidden by the virus, so they might wonder why their folder can't be open after killing the virus...
Quote from: Jeremy Collake on September 27, 2015, 06:31:28 PM
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.
I used to only use the firewall portion of security suites as the default windows firewall does not come with any ability to be alerted when a program is attempting to access the internet and say yes or no. Then I came across Windows Firewall Control or WFC which does exactly this: takes the native Windows Firewall and adds alerts and easy allow/deny permissions to exe files attempting to access the internet. Not sure why Microsoft does not do this natively. This would encourage people to take responsibility for each and every program they allow through the firewall. I want to know every program trying to access the internet on my personal computers.
Because of average people don't care about it, Windows is design for newbie that don't know anything about computer, and just easy to use. ;)
Just to report that this is fixed. I don't know what and which of the programs changes. I'm just happy that this is fixed. :D No exclusions in EIS made. :D
Ya, you may check the "Programs and Features", the "Installed On" will showing when they are updated. ;)
Just to let you know the concern of Fabian Wosar, an Emsisoft employee, regarding Process Lasso: http://support.emsisoft.com/topic/18705-eis-consuming-cpu-because-of-process-lasso/#entry145944 (http://support.emsisoft.com/topic/18705-eis-consuming-cpu-because-of-process-lasso/#entry145944)
LOL, well that's certainly an obscure insult.
What 'wasteful resource use' would he possibly be talking about?
If we look at resource use of CPU, I/O, and memory, Process Lasso is as lean as it gets in all categories.
I am going to try to open a dialog with him so I can better understand what the issue is, so we can hopefully not toss around insults. I don't believe (I'll have to look back), that I ever threw such insults at EIS.
Quote from: Jeremy Collake on February 05, 2016, 07:21:13 AM
LOL, well that's certainly an obscure insult.
What 'wasteful resource use' would he possibly be talking about?
If we look at resource use of CPU, I/O, and memory, Process Lasso is as lean as it gets in all categories.
I am going to try to open a dialog with him so I can better understand what the issue is, so we can hopefully not toss around insults. I don't believe (I'll have to look back), that I ever threw such insults at EIS.
Thanks, Jeremy!
I don't believe him either about PL being wasteful. ;)
I have posted there, requesting a private dialog with him, so hopefully we'll get that going. I'll post updates as I have them.
EIS has been very responsive and I believe we will have a - blameless - amicable resolution to the interoperability issue in Process Lasso v9, though EIS has already adjusted their code to resolve the problem for now.
Until then, I recommend users set the refresh interval for the GUI and/or Governor to a higher rate. This is in 'Options / General / Refresh interval (*)' ... The more you increase the re-enumeration interval time, the less of an impact this issue will have. Decreasing the GUI to 2 seconds, from 1 second default, for instance, would reduce the problem 50%. Setting the GUI to run only when manually launched would further substantially decrease the problem.
I would said that, the driver/device is wasting CPU Power, not the software. :P
If you don't believe it, then monitor your CPU package power(HWiNFO, AIDA64 or Power Gadget or whatever), and don't open any software that using a lot resource like network or other PCI-E and USB devices.(to make sure they will be idle)
Disable your PCI-E and USB devices one by one(like Bluetooth, network card, WiFi network card, gaming mouse also if you has one, and remember to leave a keyboard for enabling back...), after you disable most of them, you will found out the CPU package power has drop a lot.
So yes, a driver or device that don't putting the PCI-E link into idle states(PCI-E got 2 idle states as far as I know) will consume a lot of power, more than Process lasso.
Believe me, you will love to drop away this devices than uninstall Process Lasso which consume very little power, compare to this bad designed guys...
Of cause there are faster ways to find which guys is causing it, but you need to sign NDA with Intel's guys, I don't think it worth it...
---
And yes, there is worst, the BIOS will also disabled the PCI-E power save, or manage themselves, but not handle it to the OS(Windows)...
Unless you added a Linux and change it before booting into Windows, then you really can't do anything about it.
It can be power save, balance or performance(means disable idle), but by handling to OS, they can tweak based on which powerplans you are using.
I have made the change to reduce process re-opens. While I wholly reject the claim by Emisoft (which I think he realized was wrong) that these opens were anything other than read-only. I think their hook system just wasn't efficient enough to handle this frequency of process open requests, and so they got a little defensive at what they perceived as 'unnatural'.
I actually had originally written Process Lasso to do very few process re-opens, but then changed the code to simplify at some point in the past since it didn't seem to make any real difference, as open requests are *normally* very rapid, unless you have security software evaluating each one, and that doesn't have good caching mechanisms and thus keeps re-certifying them, as opposed to passing previously approved requests right on through.
So far it is testing well. We'll see how it goes. It 'feels' good to me, as an engineer.
Although this is in v9, only a single low-level module was modified, so this is an easy backport to v8. However, first we have to run the change through it's paces.
Later, in v9, we can maybe do away with the tamper resistant process list - or at least we'll make an attempt to.
I have released an alpha version that makes a change that should fix all Emisoft issues. However, it's still in early testing, as part of v9 ALPHA. If the change tests well, I can back-port it to v8. It shows ~50% reduction in CPU use by the governor. Of course, CPU use was already negligible.
https://products.bitsum.com/forum/index.php/topic,5518.msg20820.html
I just saw the latest beta. Sadly, I won't install it because PL and EIS, as they are now in my laptop's system, are behaving nicely. That's why I'm not so sure what happened. I just don't want to disrupt this. haha...
As always, Jeremy rocks! :D
Also, Jeremy, the name is EMSISOFT, not EMISOFT. ;)
EMSISOFT, yuck, no wonder I couldn't remember it ;). I'll go with EIS ;p.
Since at present they 'fixed' it on their end, it doesn't matter that much, but I would recommend updating to the next final release for sure, once this adjustment is well-tested. It's a pretty simple and safe adjustment, which is why I went ahead and back-ported it to v8 beta, given the importance of it.
To be clear, there was nothing wrong with my original approach, but I did underestimate the overhead involved in process opens given security software hooking these open requests. Now a container holds all these process handles and doles them out as requested, so they only need opened once, instead of as-needed.
Never underestimate the POWER of security software. ;D