100% CPU Usage

[Bakker]

Hello NakNak,

You could try to figure out what nod32 is actualy scanning when you open CAD.

Download Process Monitor from http://technet.microsoft.com/en-us/s...PHPSESSID=d926

Open it and set it to filter for ekrn.exe and have it auto scroll. Then start cad and watch what it's doing.

I used this to figure out that NOD32 wasn't able to scan large .html files and would cause it to hang and consume a lot of CPU power for minutes on end.

[newcoventry]

Regarding the CAD program. I am curious if you follow the steps I listed above. Except instead of selecting ThinkPad under Program Files select the Program Files Directory for you CAD Program.
Let me know if that helps...

[xircon]

I am also suffering the same problem on one machine only. It is a w2000 pro machine and i have had to disable nod to make the machine usable.

I get very slow scanning with *.aif files and a long 99% cpu hit, nearly freezing, with *aif files above 50MB. These are audio files just like *.wav files.

[pennybomber]

I have a same problem here is my hijackthis

Logfile of HijackThis v1.99.1

~Log removed. See this Post. - Ron~

Im running xp, home edition version 2002 pentium 4 cpu 1.70ghz 1.69ghz, 256mb or ram.

[ronjor]

Hello pennybomber,

You should remove any other antivirus programs that are running real time to prevent conflicts.

[Darken]

100% CPU usage with this file (under Vista x86) > vlc-0.8.6h-win32.exe >> http://www.videolan.org/vlc/download-windows.html

[Marcos]

Originally Posted by Darken

100% CPU usage with this file (under Vista x86) > vlc-0.8.6h-win32.exe >> http://www.videolan.org/vlc/download-windows.html

This is not a problem, the self-extracting archive contains 439 files. The scan time was reasaonable, between 4-6 seconds with both v2 and v3.

I've been experiencing the same problem for sometime myself over all versions of EAV since we upgraded from v2.7. Most recently, I have seen it happen on my home machine which is Vista X64 SP-1 running EAV v3.0.657.0 and at work where we have a mix of W2K3 servers and XP Pro PCs all running EAV business v3.0.650.0. In all cases, the only way to get out of the 100% CPU usage situation seems to be to either reboot or to End Task the ekrn.exe / ekrn.exe*32 process through task manager

One thing I have found at home is that after a reasonable amount of time surfing the internet using IE7, if I do a "Delete All" on the browsing history, ekrn.exe*32 will almost always go straight to 100% CPU for quite some time. I guess this is the kernel scanning the files as they are being deleted out of IEs cache? Anyhow, what I have noticed is that sometimes ekrn.exe*32 drops back down to virtually 0% after a while but, other times, it seems to stick at 100% until it is terminated by me.

[Darken]

Originally Posted by Marcos

This is not a problem, the self-extracting archive contains 439 files. The scan time was reasaonable, between 4-6 seconds with both v2 and v3.

Hummm, okay... try this file > http://www.quickpar.org.uk/Download-0.9.1.0.htm

[4d6]

Hello, [sorry for the very long post that follows :-P]

I just registered to say that I'm also having the same problem on several machines, and to give some technical details of my experience with this issue.

I've done some logging and stack profiling using ProcMonitor (stack summary), and the excessive CPU usage is always in fltmgr.sys. This is the Windows Filter Manager; running fltmc gives me a list of filters running:

PROCMON13 - process monitor fiilter driver
eamon - NOD32 AMON filesystem filter driver
udfilter - undelete server (excelent software to catch files deleted from network shares)
dfsdriver - windows 2003 DFS service
Datascrn - windows 2003 file screening checks (?)
quota - windows 2003 quota services

With these filters, I did the following tests:
- removed udfilter, datascrn, quota and procmon; problem still occurs
- disabled ALL modules in NOD32 GUI (including anti-stealth, real-time filesystem and startup scans); this does NOT remove the filesystem filter, and the problem still occurs, even with NOD32 disabled. This should reduce the lines of code that you have to check
- uninstalled NOD32: eamon filter is removed, problem goes away

The one test I haven't yet done is remove the dfsdriver filter to see if it works ok; this is problematic because this filter is needed to provide the network shares on the domain.

Other informations:

- NOD32 v3.x; this problem exists since v3.0.621, I think. Build 657 does not fix it.
- The affected servers ALL have Windows 2003 x64 SP2, and are ALL quad-core Intel machines
- The affected workstations are ALL Windows XP x64 SP2, and are ALL dual or quad-core Intel machines
- On the workstations the main problem is the one described some posts above, where the user can't launch AutoCAD with NOD32 running; disabling NOD32 fixes it. I haven't done any profiling on these machines, though.
- fltmgr is a kernel process, so it doesn't show on your average task manager; I usually see most of the CPU taken by CSRSS, or sometimes EKRN, since these are the processes that make the system calls to ntoskrnl/fltmgr.
- Triguering the 100% CPU issue on the affected servers is easy; there's usually some trivial filesystem operation that sets it off, but strangely it's not always the same on different machines and it might be different on your next reboot.
- On one server, all I had to do was rename any file on any drive to cause a 20 second freeze; on the next reboot, the renaming worked ok but the system froze whenever I tried to access some folder with lots of files (that worked ok on the previous reboot).
- On another server, the freezes came when opening Outlook Express with a large IMAP mailbox store; when that worked, something else failed; users accessing files from the network would notice a progressive or sudden loss of speed. Strange behaviour...
- on another server, whenever I do a simple "dir" on a DOS box on a folder with 3000+ files, the CPU will jump to 100%, the mouse begins to stutter and I have micro-freezes all over windows. This issue on this server is surviving reboots, so I'm using it for tests. This is where I tested with procmon and found that fltmgr/eamon was the apparent culprit.


Taking into account all the different behaviours, this seems to be some kind of race condition between eamon and some other kernel module/function. At least with me, this only occurs on multi-core x64 machines. I tried (this patch), and it seemed to fix that specific issue - I had 100% cpu on Winsrv.dll and csrsrv.dll (belonging to CSRSS.EXE), and this patch fixed winsrv, but not csrsrv.dll - this one still calls fltmgr and freezes in there. One strange thing: csrsrv.dll was updated in Win2003 SP2 x86 (version 5.2.3790.3959), but it remained at the previous version in Win2003 SP2 x64 (v5.2.3790.1830). Maybe some multi-core patching was forgotten for x64 ?

I hope this helps you guys at ESET to fix this problem. In the meanwhile, I'll have to revert to v2.7 and wait for better days. Some of my clients are already saying that if a fix does not come out quickly, they'll not renew their license.


Disclaimer: I'm a reseller of NOD32 products; I install and manage NOD32 for some of our clients as part of maintenance/sysadmin contracts.

[naknak]

Interesting observation:
The ekrn.exe is bursting up to 100% while I launch a CAD application on a PC constantly connected to the LAN/Internet and freezes the PC for a few minutes. Eventually the application will start in about 5 to 6 minutes. However, when I disconnect the LAN from the PC the ekrn.exe hardly riches 5% upon the application launch and almost immediately goes down to 0% and the CAD application starts in just a few seconds....

[zer0l0gic]

Does the new 3.0.667 have the high CPU utilization fix in it?

[WilliamP]

No it doesn't.

[Bubba]

Originally Posted by zer0l0gic

Does the new 3.0.667 have the high CPU utilization fix in it?

As it was with the past builds, there are a number of users experiencing max CPU usage and a number of users that aren't. So unless those with the issue attempt to use a methodical approach to what on there box wants to rumble on the same playground as Nod32, there likely never to successfully be able to run Nod 3.0.

So "Does the new 3.0.667 have the high CPU utilization fix in it?" ....Yes it does for many users.

[Thankful]

Follow these directions:
http://www.eset.com/support/kb.php?o...s&articleid=93

If you are still having problems, run Eset Sysinspector and send the log file with a description of the problem to support[at]eset[dot]com. If there is problem that needs to be fixed in a future release, we all will benefit.

[Chalawah]

Hi,

I am running NOD32 3.0.667.0, XP Home SP3, SAS Pro 4.15.1000 on an AMD Athlon XP 2800+ with 2GB RAM

The computer didn't have the '100%' ekrn.exe issue, until:

I installed Second Copy 7.1.0.3 and set up my first backup profile to backup My Documents to an external hard-drive.

As soon as Second Copy started the first ever run of the backup ekrn.exe ran at 98% and the computer became unresponsive.

Using Procmon to filter ekrn.exe as directed in a previous post [thanks for that advice] I could see that at the time 98% CPU was being indicated was with the scanning of files being transfered to the the external backup location, and the creation of files by NOD32 such as C:\WINDOWS\Temp\NOD1CCB.tmp. The particular folder being moved [to the external backup] at the time was 'My Downloads' folder - this contains d/l software, updates, patches, and MS Service Packs.

I have NOD32 set up with Blackspears settings...I ?think? I read that files such as NOD1CCB.tmp are created when NOD32 processes files using 'advanced heuristics', which are enabled in my settings.

I added Second Copy to the Exclusuions list in NOD32's Advanced Setup, but that didn't reduce the 98% CPU usage by ekrn.exe, so I removed the entry.

As soon as I added the backup destination folder to the Exclusion list in NOD32 the CPU usage by ekrn.exe remained within its previous sate before installing and running Second Copy.

I am learning here, so I am thinking to myself, no scanning by NOD32 of the backup in progress solves the extreme CPU usage. And I am thinking that there is probably no need to scan the backup folder anyway as as the files written to the origin folder - My Documents - will have been scanned by NOD32 previously anyway.

Is excluding the backup folder a secure option?

Is this a safe and recommended 'fix' for the 98% CPU usage by ekrn.exe?

Or is there more to it?

Your comments and advice most welcome.

Rgds,

Chalawah.

[Darken]

Originally Posted by zer0l0gic

Does the new 3.0.667 have the high CPU utilization fix in it?

No.

[Magritte]

Originally Posted by zer0l0gic

Does the new 3.0.667 have the high CPU utilization fix in it?

Sorry, but I couldn't bring myself to read the whole thread...

I'm having 100% CPU activity from ekrn on 2 XP machines I recently upgraded to 3.0.667 from 3.0.642 and 3.0.621. They were working better before, but since the upgrade they keep getting stuck at 100% causing the machines to slow to a ridiculous speed.

This seems to happen during Windows Update. I'm not sure if it happens anywhere else.

On my Vista machine, I'm not having this issue.

Was the quote above facetious or has ESET actually reproduced the problem and has a fix coming out? This is more than a trivial bug but the only acknowledgement I've seen on the forum seems to be of the form, "**shrug**, try reinstalling."

Thanks.

[PizzZak]

I am a Network Admin with about 4000 XP computer, running 657, have not tried the new version. Some computers are having the 100% CPU usage and some are not. For the ones that are, I noticed if I exclude the C:\Windows\Installer folder, reboot the computer that the CPU usage returns to normal. I would like to be able to keep this directory as a regularly scanned folder, but in the mean time that is the fix for my environment.

[Atlan62]

I had the same problem - but after deinstall and a new install of NOD32 3.0.667.0 on the XP Prof. SP3 system its better (not good but better)

[saffron]

Originally Posted by piranha

Just downgrade back to v2.7

Switching back to v2.7 is an UPGRADE!

[cdysthe]

This is not good at all! I used NOD32 a couple of years ago (2.x) and was really happy with it. So when my company now selected NOD32 as AV I thought I was in good hands. I have installed 3.0. I have all kinds of problems with the friggin' ekrn.exe hogging cpu, locking up other programs, slowing down copying etc. This is my work computer. I simply can't deal with it. My AV just have to work. So I go back to Avira. At this point I do not know what's more annoying, a virus or ekrn.exe!

P.S. I've tried to disable this, that and the other based on forum posts. But what use is an AV if you can't have it's features turned on?

[Thankful]

In my opinion, there are still problems with the install/uninstall procedure. I have to run uninstall more than once to remove NOD. I used to be able to run Faronics Anti-Executable but can longer do so, even after uninstalling NOD32.

[Marcos]

Originally Posted by cdysthe

This is not good at all! I used NOD32 a couple of years ago (2.x) and was really happy with it. So when my company now selected NOD32 as AV I thought I was in good hands. I have installed 3.0. I have all kinds of problems with the friggin' ekrn.exe hogging cpu, locking up other programs, slowing down copying etc. This is my work computer. I simply can't deal with it. My AV just have to work. So I go back to Avira. At this point I do not know what's more annoying, a virus or ekrn.exe!

P.S. I've tried to disable this, that and the other based on forum posts. But what use is an AV if you can't have it's features turned on?

In cases with high cpu utilization by ekrn.exe, we'd need to need the following:
1, if the problem occurs with advanced heuristics and runtime packers disabled in the real-time protection on access (default setting)
2, if setting the real-time protection to scan files with default extensions instead of all files (default setting) makes a difference
3, if the problem goes away after uninstalling ESS/EAV. Since all http/pop3 traffic is routed through ekrn.exe, you might see ekrn utilizing the cpu instead of that application (e.g. a known bug in Windows Installer, see http://support.microsoft.com/kb/916089 for details)