CPU problem fixed?

[RwRicardo]

I never used Eset Smart Security as my Security Suite, not because I didn't like it but because every time I tried it I had a problem that made the CPU usage to be always 100%. I read a lot about this before, and could never fix it after many tries. So I wonder, is this problem fixed in the Beta version? I find nothing about this in the changelog...

Thanks.

[zfactor]

i saw this issue myself on a number of occasions or on a dual core machine it would suck up near 50% and use one whole core same for quad core etc... i would also like to know if this has been addressed

[s4u]

I guess you need to try yourself. It is working opretty fine for me.

[Veniors]

no, today at some point it took up to 50% of my cpu and there was no clear reason why it was doing so. I have a core 2 duo @ 2.0 Ghz.

[Kosak]

Hello, you can define limits in Real-time file system protection.

[GES/POR]

Who cares about cpu spikes and more ram usage when the looks of the gui have been updated :thumb:

[nodyforever]

my scan enkrn.exe 50% CPU Core Duo E6600


Most Reagrds,
NF

[ASpace]

{QUOTE-> Who cares about cpu spikes and more ram usage when the looks of the gui have been updated :thumb: <-QUOTE}

;D ;D ;D

[xxJackxx]

I would guess that it won't be fixed until it is determined what the cause is. It must be a conflict with something else, because I run it on 3 different machines and have never had the problem. Someone that does have the problem will have to help the developers figure out why it is happening to them, because if they can't duplicate it, they can't fix it. ;)

[Marcos]

{QUOTE-> my scan enkrn.exe 50% CPU Core Duo E6600


Most Reagrds,
NF <-QUOTE}

Perhaps you could watch the statistics to find out what files are being scanned. This should give you a clue where to search for the culprit.

[agoretsky]

Hello,

If this happens again, try going to the Statistics Pane and seeing what is the last file or the last object scanned. Perhaps that will be revealing.

Regards,

Aryeh Goretsky

{QUOTE-> i saw this issue myself on a number of occasions or on a dual core machine it would suck up near 50% and use one whole core same for quad core etc... i would also like to know if this has been addressed <-QUOTE}

[CivilTaz]

{QUOTE-> Perhaps you could watch the statistics to find out what files are being scanned. This should give you a clue where to search for the culprit. <-QUOTE}

Very good from Eset to bring back that feature, like in the old and very good Nod32 V2

[nodyforever]

{QUOTE-> Perhaps you could watch the statistics to find out what files are being scanned. This should give you a clue where to search for the culprit. <-QUOTE}

check something right today Marcos.


Thank you

[zfactor]

i am seeing this also ill try to see whats being scanned for you tonight as soon as i get a chance i have a dual core and seeing 50% usage spikes, but some last for a min or two and makes working a pain in the neck

[jhuk]

{QUOTE-> Who cares about cpu spikes and more ram usage when the looks of the gui have been updated :thumb: <-QUOTE}


Is that the most sensible thing you can say ? ::)

The OP is not asking about 1% more CPU use for a newer Eye Candy GUI (it looks nothing special to me and the Tray Icon is ugly).

He is talking about the 100% CPU bug ESET had for many.many builds for many user that only recently been fixed.

It had nothing to do with Virus Scanning either, it simply happened as you opened a website or folder/files on PC and basically made PC unusable.

[Marcos]

{QUOTE-> i am seeing this also ill try to see whats being scanned for you tonight as soon as i get a chance i have a dual core and seeing 50% usage spikes, but some last for a min or two and makes working a pain in the neck <-QUOTE}

Have you followed my advice?
{QUOTE-> Perhaps you could watch the statistics to find out what files are being scanned. This should give you a clue where to search for the culprit. <-QUOTE}
What did you find out?

[psychokilla]

{QUOTE-> Who cares about cpu spikes and more ram usage when the looks of the gui have been updated :thumb: <-QUOTE}

It's had a lick of paint but I wouldn't say it's been updated, the colours are just different.

[zfactor]

{QUOTE-> Have you followed my advice?

<-QUOTE}

yes everything so far up untill to see whats scanning i have to wait to get back to the machine to watch and see. i will try asap to find out

[nodyforever]

{QUOTE-> Perhaps you could watch the statistics to find out what files are being scanned. This should give you a clue where to search for the culprit. <-QUOTE}



Hello,


Extensions files:

ini - 47% - 50%

cab - 50% - 54%

zip - 50% - 54%

xml - 47% - 50%

int - 47% - 50%

chm - 47% - 50%

dat - 43% - 50%


___________________________ //____________



1 - Images representative jumping memory CPU

2- Configuration PC




MOst Regards,
NF

[GES/POR]

{QUOTE-> Is that the most sensible thing you can say ? ::) <-QUOTE}

I was being sarcastic, sorry to have waisted your time - cu

[GES/POR]

{QUOTE-> It's had a lick of paint but I wouldn't say it's been updated, the colours are just different. <-QUOTE}

http://en.wikipedia.org/wiki/Sarcastic

[Jenee]

I no longer have the cpu issue with Version 4. The programs that would cause the system to crawl under version 3 open normally under version 4. I have one program that I could not open under version 3 unless I disabled antivirus/antimalware in ESS but it opens immediately in version 4. I have even enabled advanced heuristics on file execution under real time file protection and I still do not have any cpu issues. :thumb:

[MasterTB]

{QUOTE-> Hello,


Extensions files:

ini - 47% - 50%

cab - 50% - 54%

zip - 50% - 54%

xml - 47% - 50%

int - 47% - 50%

chm - 47% - 50%

dat - 43% - 50%


___________________________ //____________


MOst Regards,
NF <-QUOTE}

From your picks it seems that what is causing the spikes is the scanning of files that need to be decompressed before the AV can look into them.
Perhaps it is a hardware problem?? something related as to how fast your machine can provide decompression of files??
Just guessing...:dry:

[spm]

CPU (over-)usage problem remains here - tested on 8 computers on 3 small business networks. With default settings, performance on logon is still debilitating (for many minutes) while NOD32 scans changing .log files.

[ASpace]

Have you tried to set the Kernel and the Real-time file system protection not to scan files with all kind of extensions but just the default set or just exclude scanning of .log files ?

[nodyforever]

{QUOTE-> From your picks it seems that what is causing the spikes is the scanning of files that need to be decompressed before the AV can look into them.
Perhaps it is a hardware problem?? something related as to how fast your machine can provide decompression of files??
Just guessing...:dry: <-QUOTE}



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

[spm]

{QUOTE-> Have you tried to set the Kernel and the Real-time file system protection not to scan files with all kind of extensions but just the default set or just exclude scanning of .log files ? <-QUOTE}
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.

[funkydude]

{QUOTE-> 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. <-QUOTE}

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.

[spm]

{QUOTE-> You see this "bug" isn't totally a bug. <-QUOTE}
Oh, it most definitely IS a bug.

{QUOTE-> 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. <-QUOTE}
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.

[funkydude]

{QUOTE-> Oh, it most definitely IS a bug. <-QUOTE}

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

{QUOTE->
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. <-QUOTE}

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.

[spm]

{QUOTE-> 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. <-QUOTE}
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?

[funkydude]

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.

[spm]

{QUOTE-> 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. <-QUOTE}
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...

[funkydude]

{QUOTE-> 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... <-QUOTE}

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

[spm]

{QUOTE-> Hey big man, I did you a favor since the search feature is disabled on your account it seems. http://www.wilderssecurity.com/showthread.php?t=207359 14 pages for you to catch up. Good luck! <-QUOTE}
Really, you are giving me a great laugh. Thank you. Now, I have important and mature people to interact with. Have fun.

[funkydude]

{QUOTE-> Really, you are giving me a great laugh. Thank you. Now, I have important and mature people to interact with. Have fun. <-QUOTE}

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. ::)

[spm]

{QUOTE-> 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. ::) <-QUOTE}
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...

[funkydude]

{QUOTE-> 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... <-QUOTE}

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".

[doktornotor]

{QUOTE->
Again, you're wrong, writing to a logfile several times a second is "pretty damn weak coding" <-QUOTE}

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.

[spm]

{QUOTE-> 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. <-QUOTE}
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.

[doktornotor]

{QUOTE-> it's not MY application that needs fixing. The software concerned is another vendor's. <-QUOTE}

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.

[spm]

{QUOTE-> 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. <-QUOTE}
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.

[Marcos]

{QUOTE-> 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. <-QUOTE}

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?

[spm]

{QUOTE-> 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? <-QUOTE}
I have sent you a PM.