ekrn.exe generating huge temp file

Discussion in 'ESET NOD32 Antivirus' started by andyhartley, Apr 20, 2009.

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

    andyhartley Registered Member

    Joined:
    Apr 20, 2009
    Posts:
    2
    Hi,

    NOD32 3.0.864.0 Widnows XP SP3

    ekrn.exe is creating a huge file in my \windows\temp directory. A dir shows

    Directory of c:\windows\temp

    19-04-2009 02:31 314 HTTEA.tmp
    20-04-2009 15:18 11,086,696,748 HTTEB.tmp
    2 File(s) 11,086,697,062 bytes

    This file is being written at a rate of about 5MB per minute. This has happened on three occasions in the last couple of months, and on one occasion used up all my available disk space. I have used sysinternals filemon and procmon. procmon shows both of these files open to ekrn.exe and filemon show continuous writes to this file by ekrn.exe. I have posted a case to ESET and they say that this has nothing to do with ekrn.exe, but procmon and filemon say different.

    The filenames created are always of the form HTT??.tmp.

    Has anyone else experienced this?

    Ta, Andy.
     
  2. Marcos

    Marcos Eset Staff Account

    Joined:
    Nov 22, 2002
    Posts:
    14,374
    It means than an application is downloading a large file through http and the http traffic initiated by that application is checked by the web scanner.
     
  3. andyhartley

    andyhartley Registered Member

    Joined:
    Apr 20, 2009
    Posts:
    2
    Marcos,

    Thanks for your help on that - a better response than from the case I raised where I was told ekrn.exe was not writing these files.

    I have slowly been able to track this down and it appears that the file is being generated when an internet camera is connected. ekrn establishes 3 connections to the camera's local IP Address. Whilst this occurs the file is being written to at 5MB / minute. Disconnecting the camera closes these connections and the files are deleted. Is there a way to prevent this from happening as I need the camera running 24/7? I am in no way an expert on NOD32 - indeed I do not believe I have changed any settings so far.

    Thanks, Andy.
     
  4. Kroduk

    Kroduk Registered Member

    Joined:
    Apr 24, 2009
    Posts:
    2
    Hi, I managed to get past this problem by excluding the offending webcam's IP address from HTTP scanning (I use the Linksys WVC200, streaming video 24/7). I can't remember exactly where it is but it can be found under NOD32's Advanced Setup, Web Access Protection, HTTP, HTTPS. In my case, NOD32 brought down my file server as it's temp file maxed out my hard drive when it grew to 32GB. You want to look for the entry that omits the web page / IP from being scanned.

    Kroduk
     
  5. Roti

    Roti Registered Member

    Joined:
    May 28, 2009
    Posts:
    1
    I've been reporting this problem in relation to IP cameras since early 2008, with no fix so far.

    Excluding the camera IP addresses does not prevent huge files forming on the windows\temp folder for me. I've seen this with D-Link & LevelOne cameras.
     
  6. Concerned Citizen

    Concerned Citizen Registered Member

    Joined:
    Jun 12, 2009
    Posts:
    2
    I'm having the same problem, but with web scanner turned off.
    While downloading a game demo (15MB) from this address http://www.lobstersoft.com/gemsweeper/download.php ekrn.exe created 2 files (about 800MB each) in C:\windows\tem (why here and not in regular temp?).
    When I turned off the ThreatSense setting for self-extracting archives this didn't ocuur and only a 20MB file was created.

    So I suppose ekrn tries to unpack the file and goes into some sort of loop.

    This is very unpleasant as it freezes the whole system for about a minute and I'm affraid such BIG reads (500MB now, 15 minutes after turning the computer on) /writes of ekrn.exe have a very deep impact on performance of the whole computer.
     
  7. Marcos

    Marcos Eset Staff Account

    Joined:
    Nov 22, 2002
    Posts:
    14,374
    No problems here. The archive comprises of 1316 files which are scanned in about 6 seconds with SFX archives enabled. No large files are created during the download and subsequent scanning. When scanning archives by the user, temp. files are created in the user temp. folder pointed to by the user temp variable defined in the OS.
     
  8. Concerned Citizen

    Concerned Citizen Registered Member

    Joined:
    Jun 12, 2009
    Posts:
    2
    Doing more research I found out, that this happens when Firefox pre-downloads the file to temp.
    The incomplete file is then being scanned and the big files are created in C:\Windows\Temp .

    A file as small as 52kB of data from the beginning of the final 15MB file does this.
    That's probably where the self-extracting module is placed and detected.

    Also scanning the complete file produces no problem, only working with the partial download does.
    This happens even when I have this partial file and copy it into another directory or open it for editing.

    Here's the 52kB file if you want to test it
    http://rapidshare.com/files/245483160/Partial-download.part.html
     
  9. edwin3333

    edwin3333 Registered Member

    Joined:
    Aug 29, 2007
    Posts:
    244
    We have about 100 Axis netcams. We had this problem with Nod32 2.7 and the Axis network cameras. Nod32 would fill up the hard drive of the PC this way.

    With 3.x and 4.x, Axis cameras no longer seem to have this issue.

    Since you are on Nod32 3.x, which doesn't support SSL scanning, perhaps you could do this over HTTPS and see if the problem stops? Just an idea.

    I've started using VLC to access my Network cameras, which avoids many of the browser issues;

    vlc.exe http://user:password@192.168.1.1/axis-cgi/mjpg/video.cgi?fps=30&nbrofframes=0

    or

    vlc.exe rtsp://user:password@192.168.1.2/mpeg4/media.amp

    Not sure what type of camera you're having the problems with.
     
  10. Marcos

    Marcos Eset Staff Account

    Joined:
    Nov 22, 2002
    Posts:
    14,374
    Thank you, that's what we needed. The file is currently being analysed and, if a problem is found, a fix will be distributed to all users via a standard module update.
     
Thread Status:
Not open for further replies.