Huge temp files on computer monitoring IP camera

Discussion in 'NOD32 version 2 Forum' started by sd_mark, Mar 20, 2008.

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

    sd_mark Registered Member

    Joined:
    Feb 14, 2008
    Posts:
    27
    Location:
    San Diego, CA
    Hi,

    I have a Windows XP SP2 laptop running a Panasonic Network Camera Recorder program to record and monitor an IP-based camera. There is obviously a lot of IP traffic to this machine, and lots of file writing. The machine stays permanently logged on to the domain and always displays the current video feed.

    Since installing NOD32 2.70.39, I am seeing this machine's disk fill up completely about once a day. (NOD32 kindly sends me an email every hour that it cannot save its update because the disk is full.) I've narrowed this down to the following folder:

    C:\Documents and Settings\cameraaccount\Local Settings\Temp

    If I browse that folder over the network, I currently see four IH####.tmp files. One is 2mb, one is 20mb, one is 4.6GB, and one is 5GB. It's those multi-gig files that are filling up this drive. If I log on to the machine via Remote Desktop, the temp are gone and I suddenly have 9GB of free space.

    I found some archived posts regarding these IH####.tmp files but I wasn't clear on the resolution. Why do the files grow so big? Why do they disappear as soon as I connect to the machine? Should I just disable IMON on this machine since it isn't used for browsing or email?

    Thanks,

    Mark
     
  2. Webby

    Webby Registered Member

    Joined:
    Jan 1, 2006
    Posts:
    93
  3. sd_mark

    sd_mark Registered Member

    Joined:
    Feb 14, 2008
    Posts:
    27
    Location:
    San Diego, CA
    Hi Webby,

    Thanks for your note. Yes, that thread you started back in '06 is the one I had found. It looks like there was never a definitive answer...Marcos says NOD32 only creates temp files beginning with "NOD", but you only saw the "IH" temp files when AMON was scanning your MJ-12 files.

    On Thursday, I disabled IMON completely, but I did not exclude the folder where the camera saves its images. Today (Saturday), I see an 8.2GB file out there called IH832F.tmp. So IMON is not the culprit.

    I don't see how it could be AMON either. I have AMON set up to only scan specific extensions. The camera files have the extension ".body", which is not on the AMON list. The temp file has the "tmp" extension, also not on the list.

    Using NTFilMon from www.sysinternals.com, I was able to determine that the program ncrcore.exe is the one writing to the .tmp file. That is the Network Camera Recorder core. Sure enough, when I exit the camera software, the temp file is deleted. I guess it is a coincidence that MJ-12 uses a similar temp file naming scheme.

    This was working fine for a couple years with a different AV software installed. Is NOD somehow blocking the program from deleting its own temp files?

    What was your ultimate solution for MJ-12?

    Regards,

    Mark
     
  4. Webby

    Webby Registered Member

    Joined:
    Jan 1, 2006
    Posts:
    93
    sd_mark,

    As I said in the orginal post "After so long with MJ-12 excluded from the IMON scan I fired it up once again. Within an hour I had 140MB Temp files and PF Usage in the Task Manager rising by 1MB per second. MJ-12 is on my D Drive only and the temp files are showing up on C/ as in the other posts I made above. The files are only created when NOD32 has access to MJ-12"

    Nothing has changed, I still have the MJ-12 Node excluded form the IMON scan and have not seen the Temp files since! I took the answer as it was and did not want to push the enquiry after that.

    Shame really :'( as I was able to help the Distributed Project MJ-12 and also submit virus samples to Eset after crawling milions of URL's a day.

    Cheers Webby
     
  5. Webby

    Webby Registered Member

    Joined:
    Jan 1, 2006
    Posts:
    93
  6. sd_mark

    sd_mark Registered Member

    Joined:
    Feb 14, 2008
    Posts:
    27
    Location:
    San Diego, CA
    Webby,

    Thanks for the follow-up. If I come across any striking revelations, I'll try to remember to post them here.

    Mark
     
  7. Webby

    Webby Registered Member

    Joined:
    Jan 1, 2006
    Posts:
    93
    Ok Mark,

    I expect the next test I shall make will be after a change to NOD32 v3. I'll let everybody know how that goes.

    Cheers
     
  8. sd_mark

    sd_mark Registered Member

    Joined:
    Feb 14, 2008
    Posts:
    27
    Location:
    San Diego, CA
    Well I tried excluding both the data files and the IP camera program files. I still got huge temp files.

    Then I tried turning off AMON, DMON, EMON, and IMON, effectively completely disabling NOD32. Still huge temp files.

    Finally I uninstalled NOD32 2.70.39. No more huge temp files!
     
  9. Webby

    Webby Registered Member

    Joined:
    Jan 1, 2006
    Posts:
    93
    Last edited: Apr 1, 2008
  10. sd_mark

    sd_mark Registered Member

    Joined:
    Feb 14, 2008
    Posts:
    27
    Location:
    San Diego, CA
    Webby,

    We are on the same wavelength :).

    Yes, I loaded version 3 on the client and even with NO special folder exclusions (although only scanning specific extensions), I do NOT get the huge temp files.

    Not thrilled with the idea of having to maintain multiple versions of AV software on the network.

    Mark
     
  11. Webby

    Webby Registered Member

    Joined:
    Jan 1, 2006
    Posts:
    93
    Well fancy that! Better news Mark except for this bit:

    "Not thrilled with the idea of having to maintain multiple versions of AV software on the network"

    Were getting there. I'll load up v3 on a quite weekend and post my results. I'd love to help out again with the virus hunting, helps the whole community.

    Anybody with some extra bandwidth is welcome to join me and the chaps on the Majestic-12 Distributed Crawling Project at this link.

    http://www.majestic12.co.uk/

    Cheers Webby
     
Thread Status:
Not open for further replies.