high CPU usage of NOD32 AV 4.2.35

Discussion in 'ESET NOD32 Antivirus' started by rpremuz, Apr 9, 2010.

Thread Status:
Not open for further replies.
  1. rpremuz

    rpremuz Registered Member

    Joined:
    Jan 18, 2005
    Posts:
    100
    Location:
    Croatia
    Hi!

    I have problems with Eset NOD32 AV Business Editioin v. 4.2.35 on MS Windows XP Pro. SP3 (with latest MS updates installed) in a MS Windows domain.

    A typical desktop PC has at least AMD Sempron 3200+ and 1 GiB DDR RAM, while laptops have at least Intel Pentium M 1.8 GHz and 1 GiB DDR RAM.

    When executables are started (both from local HDD or from a network share) high CPU usage (almost 100%) can often be noticed and the Windows becomes unresponsive. Process Explorer shows that the cause of the problem is ekrn.exe process. The high CPU usage may last quite long for some executables which makes users (and the admin) unhappy.

    Here is a capture of the Process Explorer data that shows the execution of the following two commands from the command prompt (the asdf.exe has 2 MiB, a grid cell corresponds to 5 seconds):

    Code:
    C:\temp>copy \\myserver\myshare\asdf.exe .
            1 file(s) copied.
    
    C:\temp>\\myserver\myshare\asdf.exe
    ekrn1.jpg

    The first instance of high CPU usage corresponds to the file copying, which is quite slow, while the second one corresponds to invoking the same EXE file, which is also quite slow.

    The following image was captured while starting GIMP v.2.6.7 from the C: partition:

    ekrn2.jpg

    If the real-time file system protection is disabled in NOD32, the above two commands finish in a split second, while GIMP also starts much faster.

    The MS Windows Server 2003 that provides the \\myserver\myshare has NOD32 AV v. 4.0.474 installed with the real-time file system protection enabled but the shared directories are excluded from real-time scanning.

    I'm attaching the NOD32 configuration of the MS Windows XP (with some confidential data excluded).

    Does anyone know how to solve this problem?

    -- rpr.
     

    Attached Files:

  2. Cudni

    Cudni Global Moderator

    Joined:
    May 24, 2009
    Posts:
    6,956
    Location:
    Somethingshire
    update to latest version, if you possible. is it set to scan the network drives?
     
  3. Marcos

    Marcos Eset Staff Account

    Joined:
    Nov 22, 2002
    Posts:
    14,376
    Where could I donwload the file from? Are you positive that the file was scanned quickly before the recent update of the archive module? Does disabling runtime packers for newly created files make a difference?
     
  4. rpremuz

    rpremuz Registered Member

    Joined:
    Jan 18, 2005
    Posts:
    100
    Location:
    Croatia
    Marcos,

    the EXE is an accounting application made by a local company. You can get it from me :)

    Users use the application constantly during working time (i.e. they start it and close it many times during the day). The problem is always present and I don't think it is related to updating of virus signatures.

    On a machine I've just disabled the scanning of runtime packers for newly created files, but it hasn't made any difference. (The performance graphs look almost the same as before.)

    Cudni, I attached the NOD32 configuration so that you don't need to ask additional questions about the NOD32 settings. (Yes, scanning of network drives is enabled.)

    -- rpr.
     
  5. Marcos

    Marcos Eset Staff Account

    Joined:
    Nov 22, 2002
    Posts:
    14,376
    Please PM me the link from which I could download the file for perusal.


    Then the issue's not related to the recent update of the archive module. If the file is reasonably large or packed/protected it would explain why it takes time for advanced heuristics to emulate the code.
     
  6. rpremuz

    rpremuz Registered Member

    Joined:
    Jan 18, 2005
    Posts:
    100
    Location:
    Croatia
    Marcos,

    Thank you for your suggestions. I've solved the issue with some of the applications by converting the executables to an uncompressed form (they were packed with UPX).

    -- rpr.
     
Thread Status:
Not open for further replies.