CPU problem fixed?

Not problem hardware....occurs in version 3 and 4, with multi-core processors


We can see several users of the forum say they have a Core 2 Duo processor and ekrn.exe uses 50% of CPU




Versions 3 and 4 support multi-core processors?


It is that these problems do not occur with version 2 of the same product.



MOst Reagrds,
NF

 

Of course, and that works around the problem, but it does not solve the problem. The issue is that NOD32 (v3 and the v4 beta) has an inherent and fundamental bug, for which Eset and people like you persist in saying: "It's OK for the software to have bugs, and it's OK for Eset not to fix them. Instead, the onus is on the user to reduce security in order to avoid the bugs." This kind of low standard is what encourages developers to believe they can get away with poor quality. That's what Eset are doing. I know software has bugs - all software does - but what is unacceptable is that oft-reported bugs remain untouched by developers for such a long time. It has been a good year now in this case. It just isn't good enough.

 

I actually agree with you, to a point. You see this "bug" isn't totally a bug. This and the other post are a merge of different problems with different solutions.

There are a few problems with people having files that are constantly refreshed which creates the problems which, I'm sure you will agree, isn't ESET's fault, that's pretty damn weak coding, to refresh a file like that.

There is a really obvious bug with the way certain files are packaged that upsets advanced heuristics. I've been researching this for a long time on my XP machine and located it exactly to a specific exe file, Age of Empires 3.

I proceded to send this file to the ESET dev's who will remain nameless and they themselves said they would add a "workaround" to the advanced heuristics for this kind of file, as it was creating a long loop thus 100% cpu usage.

That was 3 weeks ago and I'm still waiting for the heuristics update.

People can help by identifying the files in question and contacting ESET about it, although my experience has been less than a good example, I've been told they have been testing it all this time.

 

Oh, it most definitely IS a bug.

That is complete nonsense. Particularly in corporate environments, log files are are an essential source of troubleshooting, and frequent writing to them, under the right circumstances (such as this one) is a necessity, not "pretty damn weak coding". It is Eset's fault that their product is incapable of coping with such files. Of all the many antivirus solutions I have put through this test, NOD32 is the only product which fails.

 

No, it's not, you should read through the real thread.

Again, you're wrong, writing to a logfile several times a second is "pretty damn weak coding", if you think that's normal, please list me the programs you write so i never install them.

 

Mmm. Who said anything about several times a second? Be clueless if you like. In any case ... didn't you know that computers can actually do more than one thing a second? Revolutionary, eh?

 

Clueless, you're making wild statements without reading the real thread? Congratulations! Now go study up and don't post again until you do. You have a long thread to go through.

 

As if you can tell me what I can do. Ha. A hint for you ... understanding is better than reading without understanding. Of course, if you can't understand...

 

Hey big man, I did you a favor since the search feature is disabled on your account it seems. https://www.wilderssecurity.com/showthread.php?t=207359 14 pages for you to catch up. Good luck!

 

Really, you are giving me a great laugh. Thank you. Now, I have important and mature people to interact with. Have fun.

 

I'm glad I amuse you, since making people happy is my number 1 past time. It's a shame you can't make people happy by telling them to study a problem before coming to a forum and spewing rubbish assuming they know everything about it.

 

You think you are enhancing your reputation here? Mmm. Good for you. While I retain my amusement at your behaviour, I feel you will (read: will not) understand that you have also become tiresome. I'll leave you to yourself. Yawn. Byeeee...

 

Yes, you clearly understood the point of this argument, it was all about enhancing my Wilders reputation, not arguing about your bad statement at an ESET "bug".

 

Well, +1 on this... IOW, if you have a huge log file that's getting changed all the time, set up an exception to exclude it from realtime scanning (also, what's the point of setting up your real-time protection to scan plaintext log files in the first place goes beyond me).

At minimum, consider fixing your application to rotate the logs regularly to mitigate such issues.

 

To be clear on this ... despite some clueless person having implied otherwise it's not MY application that needs fixing. The software concerned is another vendor's. Also, it is Eset that sets up NOD32's defaults so that .log files are scanned - and so they should. Don't make the mistake of calling .log files 'plain text' files. Files with a .log extension are just that - i.e., files whose names follow a particular naming convention - the extension guarantees nothing about their content being text. A file whose name has a .log extension can easily be a program file, and a malicious one at that. Indeed, there are infections around that name their wares with a .log (or other supposedly innocuous) extension. Excluding .log files from scanning therefore decreases security.

 

Well, then ask them to fix the issue as said above, meanwhile you can work around it by excluding the file. And please note that having to deal with huge perpetually changing logs will slow you down and cause resource hogging issues with pretty much any realtime AV if you choose to scan them.

 

I know how to workaround the issue, but as I have said it is not a solution. I work with facts and observations, not speculation. The log files in question are not huge - they are often in the range of 30MB - 50MB in size - and they are not perpetually changing. They change frequently during startup and logon only, but NOD32 chokes the whole system for a number of minutes at this time. That is the problem. While you might speculate that other AVs exhibit the same bad behaviour as NOD32, that is just not the case. You will note that I have already posted above to confirm NOD32 is the only one of several AVs that has this issue.

 

Please add the log(s) to the exclusion list for now or set a size limit for scanning. Could you please compress the log(s), put them on an ftp and PM me a link to them?

 

I have sent you a PM.