ataraxy Posted April 16, 2011 Report Share Posted April 16, 2011 I've had big problems with Immunet over the last 2 days with agent.exe constantly writing to the disk. This started around the time that a scheduled full scan started and went on for at least 18 hours before I figured out what was going on and uninstalled Immunet. I'm running Windows 7 Home Premium SP1 64 bit (English language) and the cloud only version of Immunet. I'm also running Microsoft Security Essentials 2.0.657.0 and Spybot 1.6.2.46 and have Malwarebytes 1.50.1.1100 installed. I've sent the support snapshots etc. mentioned below using the product support form. This has been allocated Case #3486. What Happened 1. I updated Immunet to v3.0.1.6056 on 14 April. Everything seemed to be okay. 2. At 9 pm on 15 April my weekly scheduled scan (Full Scan) started. I noticed that there was a lot of disk activity, but I've noticed this before with Immunet scans and so I wasn't too worried. 3. The scan took much longer than normal and so I left it running overnight. It finished just before 6 am on 16 April, i.e. nearly 9 hours. This seems to be much too long. 4. I checked my PC around 1 pm on 16 April and saw that there was still constant disk activity. I took a support snapshot at this time (already sent) thinking that it might be an Immunet problem, however, since the Immunet UI said that the scan had finished it appeared that there was some other problem. 5. I restarted my PC and the disk activity continued. Checking with the Resource Monitor I found that it was agent.exe that was constantly writing to the disk. Unfortunately I forgot to take a screen shot so don't have proof of this. I took another support snapshot (also sent). 6. I restarted my PC in Safe Mode to uninstall Immunet. The uninstall stalled when it couldn't stop agent.exe (should this even have been running in Safe Mode?) so I had to end agent.exe from Task Manager. The uninstaller then completed. I captured the uninstaller messages in some screenshots which I attached when using the support form. Also, I selected "No" when asked if I was going to install Immunet again, but it wasn't possible to capture (or review) these messages so hopefully all went okay. 7. Now that Immunet has been uninstalled everything is running properly again. Further Comments - I first ran the System Diagnostic Tool from my user account. As this doesn't ask where to store the results and just stores them on the administrator account desktop it wasn't obvious that anything had happened, nor was it possible for me to easily access these files from my user account. I suggest that you ask users where they want to save the file. - it was annoying not to be able to copy the messages in the uninstaller window, or review the messages after indicating that I wasn't going to reinstall Immunet (this is because of the PC Restart message holding the focus). Could you please make these messages selectable/copyable/reviewable. - the Immunet uninstaller didn't delete the task that Immunet had created in Task Scheduler for my scheduled scan. This should be done. Link to comment Share on other sites More sharing options...
sbs Posted April 16, 2011 Report Share Posted April 16, 2011 Experienced the same problem on win7 pro SP1 Link to comment Share on other sites More sharing options...
Guest Orlando Posted April 17, 2011 Report Share Posted April 17, 2011 I'll reported it to Rob, he will respond in a few days. Orlando Link to comment Share on other sites More sharing options...
millard@immunet.com Posted April 18, 2011 Report Share Posted April 18, 2011 Basically in order to fix the handle issues related to iTunes, Netflix, and a slew of other applications a change had to be made to "Blocking Mode". If you go to Settings and find "Blocking Mode", it's off by default and this causes us to duplicate file handles on disk. If you turn it "On", we'll do this is memory instead. --Millard Link to comment Share on other sites More sharing options...
ataraxy Posted April 19, 2011 Author Report Share Posted April 19, 2011 If you go to Settings and find "Blocking Mode", it's off by default and this causes us to duplicate file handles on disk. If you turn it "On", we'll do this is memory instead. Are you saying that this will fix the problem? Why won't the duplicate file handles in memory also cause problems? Link to comment Share on other sites More sharing options...
Rob.T Posted April 19, 2011 Report Share Posted April 19, 2011 Yes - turning blocking mode on will fix the problem, and no - duplicate file handles in memory won't cause problems. Link to comment Share on other sites More sharing options...
sbs Posted May 1, 2011 Report Share Posted May 1, 2011 Yes - turning blocking mode on will fix the problem, and no - duplicate file handles in memory won't cause problems. I have set blocking mode on, and have zillions of agent.exe disks tasks in my resource monitor steadily trashing my disk. I have started a full scan yesterday afternoon. lasted 6h. Still trashing this morning. For your infor agent read and write about 2MB/s from hystorydb and hystorydb-ex files. Link to comment Share on other sites More sharing options...
ataraxy Posted May 1, 2011 Author Report Share Posted May 1, 2011 I have set blocking mode on, and have zillions of agent.exe disks tasks in my resource monitor steadily trashing my disk. I have started a full scan yesterday afternoon. lasted 6h. Still trashing this morning. Just for the record, I haven't reinstalled Immunet yet so can't confirm that setting the blocking mode to "on" solves this problem. Looks like I should hold off reinstalling Immunet for a while yet. Thanks for posting sbs! Link to comment Share on other sites More sharing options...
Carlos_Ed Posted May 23, 2011 Report Share Posted May 23, 2011 Greetings everyone, After days of messing around with Immunet 3.0 configuration options, uninstalling, manually removing all Immunet related leftover files, reinstalling from scratch, etc... and after almost considering a full clean OS reinstall; I finally found a solution I believe I should share with everyone having the same kind of hard disk thrashing problem related to "agent.exe". In my case it is very easy to reproduce the problem, setting blocking mode on/off seems irrelevant to my specific situation: - Assume no hardware related faults/defects. Assume the machine hardware in question meets or exceeds all software requirements for everything loaded, installed and running. - Operating System: Windows 7 (does not seem to matter which version) - x64 version. Step 1: Install Immunet 3.0, using the default installer settings and destination folder. Step 2: After everything is set and installed, call a scan. Does not matter which type, scheduled or not. - Once Step 2 is completed, "agent.exe" becomes locked trying to write data to either one of two files: history.db and history.db-journal(?). I believe this is the same symptom that is being experienced by most users in similar situations. Upon investigation, here's the solution I came up with: - After noticing that a lot of the writing attempts made by "agent.exe" were failing with a "NAME NOT FOUND" error (this is visible using "ProcessMonitor" application to monitor process IO activity (or file system, or whatever you may fancy calling it...). Incidentally, I recall reading this specific post and decided to give it a go. It was the last thing I never considered touching because it didn't make much sense... I was wrong! The second I got rid of all default exclusions in Immunet 3.0 settings, "agent.exe" stopped the incessant history writing activity. It seems that at least on Windows 7 x64, some of those folders do not exist and the current version of Immunet is doing something else besides just ignoring them. At least, this is what happens on my system. I hope this helps other users in the same situation. Moreover, I hope that it manages to send a heads-up across to developers, so they remember to include the needed glitch fixes on the next release of this wonderful piece of software. Edit: Another one of my machines, running Windows XP SP3 x86 (32 bit), seems to suffer from the same problem. Which, in my opinion, kills the whole "only happens on x64" theory. I tried the same "workaround"... it didn't work. Or rather it did. Until the next scan was called which returned "agent.exe" to it's obnoxious state. So it seems to only spare you the first reboot after your first scan(?). This was verified on both systems. In light of the new development, the current releases of Immunet 3.0 for me are only usable without calling or scheduling scans. Anytime a scan is called, I need to restart the computer in question, after the completed scan, in order to tame "agent.exe" again. I will try to find the common ground between both systems, hopefully that should shed some light on this matter. If that turns out empty, Immunet 3.0 will not be usable for me under such terms. Considering the first post of this topic was published in mid April, and considering we are reaching the end of May presently; anymore delays on a proper fix will just keep biting Immunet's reputation... Link to comment Share on other sites More sharing options...
sweidre Posted May 23, 2011 Report Share Posted May 23, 2011 - it was annoying not to be able to copy the messages in the uninstaller window, or review the messages after indicating that I wasn't going to reinstall Immunet (this is because of the PC Restart message holding the focus). Could you please make these messages selectable/copyable/reviewable. Hi ataraxy, I am not able to reply to your core problem with "agent.exe", but I will here emphasize on a secondary issue, that you mentioned above (see quotation). Many windows in Immunet cannot be copied to clipboard The disability in Immunet to have windows highlighted/marked and copied to clipboard makes it impossible to copy/paste contents into a file, email or to a post in this forum. The only way to show a problem is to make a printscreen of it and attach an upload to a forum post or attach it to an email. But the 2MB limit per user allows only 3-4 screenshots to be uploaded in total to the forum (depending on the format chosen, of course!). This copy/paste problem is well described in this thread by WacoJohn: "Allow Copy/paste" http://forum.immunet..._5855#entry5855 Cheers, sweidre PS. I am sorry, that I cannot contribute to the real problem of yours, sbs or ced: "agent.exe"! DS Link to comment Share on other sites More sharing options...
Carlos_Ed Posted May 23, 2011 Report Share Posted May 23, 2011 It's OK. I just wish I could spare more resources into pinpointing the cause of this faster. It's the final barrier preventing me from fully adopting this extra security layer on my systems, and giving a very positive report to my boss for the company I work on. Since I want this to work, real badly, please excuse any obsessive tendencies I may have about this problem. I guess it's safe to say that the software seems to be so good, it is worth it all...! Working with the software on a private workstation of personal laptop, isn't really a concern. But for those that may have home servers, or other kind of permanent running systems, this is a very serious problem (reboots = downtime, frequently unacceptable for servers). It shouldn't be hard to guess that I am included in the later cases... PS: The only common ground between both computers is a few API libraries, SDKs, system monitoring tools and Avira AntiVir Personal (free anti-virus). The only program that seems to load components/background running code is Avira, that's where I will be aiming next. But not today... Link to comment Share on other sites More sharing options...
sbs Posted May 24, 2011 Report Share Posted May 24, 2011 Hello, Seeing Ced's post, I reinstalled immunet to give it a shot. I removed all non existent folders from the exclusion list. Started a Flash Scan. At the end of the flash scan, my HD led stayed steady On. A glance at the disk monitor shows the usual 2M+ agent.exe tasks writing to historyex.db. After a flash scan, it lasts for about 20'.After that, agent.exe still writes about 300kB/s to this file, which interestingly enough does not grow by 300kB/s. Link to comment Share on other sites More sharing options...
Carlos_Ed Posted May 24, 2011 Report Share Posted May 24, 2011 As far as I could tell, I don't think Avira is responsible for this behavior. If sbs confirms that Avira is not present in his case, it would also confirm my suspicions that Avira is just an innocent bystander in this. If one would be interested in finding the positive aspect in this situation, is the fact that it doesn't seem to eat your hard drive space like a program memory leak bug. But it is nonetheless a problem, as such IO tends to take too much machine resources. Also I would be very interested in knowing if restarting the system after scanning, in sbs's case, would tame "agent.exe" again like it does to me. I believe there may be more users affected by this problem than it would appear at first glance. Because: a ) I have been able to verify this situation on a few other machines, all of them are different from one another. b ) The excessive hard drive activity may not be apparent on systems with specific caching configurations. c ) When using SSDs/RAM drives or multiple hard disks (RAID arrays included), it may not be enough for less attentive users to notice it is there. d ) There are systems where a hard drive activity led indicator is not present, at all. El-Cheapo netbooks anyone...? Link to comment Share on other sites More sharing options...
sbs Posted May 25, 2011 Report Share Posted May 25, 2011 Hi, I do not use avira Link to comment Share on other sites More sharing options...
Carlos_Ed Posted May 25, 2011 Report Share Posted May 25, 2011 Well, then there we go. I ran out of variables in my equation. The only thing left to do is setup a few clean OS installations and test Immunet on them... If that fails as well, I am afraid we will have to wait for the developers to address this problem. Link to comment Share on other sites More sharing options...
sweidre Posted May 25, 2011 Report Share Posted May 25, 2011 I believe there may be more users affected by this problem than it would appear at first glance. Because: a ) I have been able to verify this situation on a few other machines, all of them are different from one another. b ) The excessive hard drive activity may not be apparent on systems with specific caching configurations. c ) When using SSDs/RAM drives or multiple hard disks (RAID arrays included), it may not be enough for less attentive users to notice it is there. d ) There are systems where a hard drive activity led indicator is not present, at all. El-Cheapo netbooks anyone...? Hi ced, You believe, that there may be more users affected! Therefore I hereby refer to a thread by WacoJohn in this forum: "Scan Specific File Does Not Finish " by WacoJohn http://forum.immunet..._5895#entry5895 His long Window Explores' context right-click scan time of a single 3-4 MB file only, we regarded as a "temporary" hicup only, maybe due to limited RAM memory for many simultaneously running processes in the background! I really hope, that more forum members will here on this thread, post their experience of emormously long scanning times, because they may contribute to the solution of this real problem: "agent.exe constantly writing to disk". Cheers, sweidre Link to comment Share on other sites More sharing options...
sweidre Posted May 28, 2011 Report Share Posted May 28, 2011 Hi, Just now malhunt has added a thread (topic) in this forum: "Bug: High Hard Disk Activity Caused By Agent.exe" http://forum.immunet..._5955#entry5955 Can this post of malhunt contribute to a solution of the "agent.exe" problem? Cheers, sweidre Link to comment Share on other sites More sharing options...
Carlos_Ed Posted May 28, 2011 Report Share Posted May 28, 2011 Although I do not have access to everything needed to specifically reproduce the same conditions on both posts, the behavior/symptoms are similar to what I can re-create on my setups. Which, incidentally, reveal that the problem can also happen on clean OS installs. Some take more than one scan to manifest. But generally, it seems somewhat random, having as a requirement calling a scan. As for the user of the D-Link Wireless adapter, it is possible that the problem was only noticed after it had already manifested. That, coupled with possible file inspection of D-Link logging files as wireless events happen, would definitely cause IO delays as described. If the D-Link user only noticed the problem after calling a scan, then it would almost prove my speculation. Chasing down the causes for this always end up on that "Agent.exe" process trying to write god knows what to those *.db files, with most of the write attempts failing with a "NAME NOT FOUND" error, as I've said. I wonder if this could be some sort of overlook in the way different system locale differences are handled...? I have seen similar behavior on other software products of misc. developers, where folder names/registry entries were name differently on different language OS versions, than the original setup where the software was developed. Link to comment Share on other sites More sharing options...
ritchie58 Posted May 28, 2011 Report Share Posted May 28, 2011 I've been following this thread with some interest as well but on the other spectrum. I do not see this excessive behavior by agent.exe on my or my roommate's PC. It is strange that some users are encountering this while others are not. I would venture to guess that there is some common element that has yet to be recognized that is causing this. Link to comment Share on other sites More sharing options...
sweidre Posted May 29, 2011 Report Share Posted May 29, 2011 I've been following this thread with some interest as well but on the other spectrum. I do not see this excessive behavior by agent.exe on my or my roommate's PC. It is strange that some users are encountering this while others are not. I would venture to guess that there is some common element that has yet to be recognized that is causing this. Hi, I have not encountered such a problem with "agent.exe" neither. (Sometimes an Immunet scan takes a bit longer than normal in my computer, but temporarily only!) I think, that the first real "agent.exe" problem was encountered by ataraxy 16 April 2011 on this thread!? Before then no such problem has been reported. One way, is to load a computer with an old version of Immunet, let's say from the autumn 2010 to see if the "agent.exe" problem will then appear. (A bug might have been entered when upgrading from v.2 to v.3? Of course, there must have been a lot of reprogramming work when ClamAV was entered into the product sortiment of Immunet.) Orlando told me once (months ago), that Immunet was looking for a programmer who knows C++, but I expect that such a programmer already has been employed! Cheers, sweidre Link to comment Share on other sites More sharing options...
Carlos_Ed Posted May 29, 2011 Report Share Posted May 29, 2011 I've been following this thread with some interest as well but on the other spectrum. I do not see this excessive behavior by agent.exe on my or my roommate's PC.[...] If your roommate system is similar to the system described in your signature, which I will assume is yours, neither you nor him will probably notice the problem is there if you do not use the proper monitoring tools. The same way I also "do not see the problem" when setting up Immunet 3.0 for testing on one of the monster quad-cpu (4x4 cores) rack mounted blade servers at my workplace, which by the way uses SATA 6GB/s SSDs. Like I have said before: the way this problem manifests itself, makes it so that just being on the lookout for sluggish performance or keeping an eye on HDD activity LEDs isn't enough to determine it's occurrence. But I guess you already knew that... More: Immunet also seems to hinder HDD I/O performance on quite a lot of systems that are begin used as workstations on a collaborative work project. This could be related to the problem, but will require more investigation before being able to confirm this to be true or false. The conditions where this happens, have very little to do with HDD fragmentation. But to put it simple, it's rather like this: few large files = normal performance // many small files (think around half a million files) = all HDD operations delayed, especially if accessing batches of said small files. PS: Immunet seems to be a wonderful concept, but the more I dig, the more it seems to show itself as being unsuitable to be used where I want to use it, and under the conditions I need it to work in. I hope this changes. Honest. Link to comment Share on other sites More sharing options...
sweidre Posted May 30, 2011 Report Share Posted May 30, 2011 But to put it simple, it's rather like this: few large files = normal performance // many small files (think around half a million files) = all HDD operations delayed, especially if accessing batches of said small files. Hi ced, I selected my E -drive ( = Library ) that contains 74 857 only small files (mostly small .gif - animations, plus a few dll- or exe-files) totalling 2.2GB and let Immunet scan the whole drive. The scan ran fast & consumed only 1 minute & 55 seconds! (Settings were: Blocking Mode = OFF, Scan Archive/Packed Files = ON!) Win 7 Pro SP1 64-bit, & cloud-based Immunet Free with disabled ClamAV (alt.1) v. 3.0.1.6112. Cheers, sweidre PS. Millions of very tiny files I do not have to test! DS Link to comment Share on other sites More sharing options...
sweidre Posted May 30, 2011 Report Share Posted May 30, 2011 But to put it simple, it's rather like this: few large files = normal performance // many small files (think around half a million files) = all HDD operations delayed, especially if accessing batches of said small files. Hi ced again, You are talking about 1/2 million small files of yours! Just a hyphotesis: Is it so that your files are unknown to others? Then, of course, they are not known by the Immunet community ( = the cloud ), and the SPERO engine will not be involved in these at all! But ETHOS ( = the heuristic engine )will! What happens, if ETHOS cannot classify a file as a clear file or a malware? ETHOS will then stay there trying to examine this particular file for ever! ( = constantly working at disk ) In my mind, ETHOS should after a few attempts skip classifying & leaving the file, if it cannot decide the file to be malicious after a few milliseconds, and then go further to the next file for scanning.) Have you scanned your 1/2 million small files using heuristic modules of other AVs? Maybe the heuristic modules work differently? Cheers, sweidre Link to comment Share on other sites More sharing options...
Carlos_Ed Posted June 3, 2011 Report Share Posted June 3, 2011 Yes I am actually referring to drives and partitions that can contain on average half a million files, but some of the workstations being used in other projects with higher workloads can easily reach over eight hundred thousand (800.000) files. Considering that these are not your average user's files (because they belong to projects under development and have not been released yet) I can guarantee that nobody outside the work group would "know" about these files. These files can be opened in notepad, many are scripts and plain text data, and other heuristic AV engines go through them with relative ease, but do take their time (with hundreds of thousands of files, it is expected). I obviously tried them all forced to scan all files, where possible (some AV products skip certain file extensions altogether). In Immunet's case, it's not acceptable to have to wait for a week to do a scan. Like I have said, I regret that Immunet 3.0 is not usable for me currently under these conditions. But, I will keep a very close eye on how Immunet evolves from now on, and will be very happy to use it once it can handle working like I need it to. Link to comment Share on other sites More sharing options...
sweidre Posted June 3, 2011 Report Share Posted June 3, 2011 Like I have said, I regret that Immunet 3.0 is not usable for me currently under these conditions. But, I will keep a very close eye on how Immunet evolves from now on, and will be very happy to use it once it can handle working like I need it to. Hi ced, Have you tested the new version of Immunet just issued? "Immunet 3.0.2 Beta Available Download here": http://forum.immunet..._6024#entry6024 It is v.3.0.2.6548 Public Beta 1 (English)! I suggest, that you'll give it a try! Good Luck! sweidre Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.