Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


zombunny2 last won the day on September 10 2019

zombunny2 had the most liked content!

Community Reputation

2 Neutral

About zombunny2

  • Rank

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Hi all, apologies for resurrecting an older thread, but I simply haven't had the chance to reply. In the interests of courtesy and helping others with similar issues in the future, I thought I'd reply. I had already tried uninstalling (and thought I'd clicked "no" to the "remember stuff?" dialog) - however I did it again, just to be sure. I then ran the Windows built-in disk cleaner, Revo Uninstaller's "search for junk files", Bleachbit, and CCleaner, to ensure I'd removed all temporary files, orphaned registry entries, etc. I also manually searched for any immunet traces by using "dir /s/a/b/p *immunet*" from the command line, from the root directory of drive C. You can use a similar technique to search for anything cisco, sourcefire or clamav related, but in my case it didn't reveal anything Immunet-related, and risks identifying other software. It's then just a case of using "del" and "rd" as appropriate to remove any traces of Immunet (there were virtually none). (There might be a GUI-based way of doing this, but MS generally try to hide directory-structures and system files in their GUI dialogs, so it probably won't work. It was very easy in WfW/Win9x/NT/2000, but I think something changed from XP onwards. If you want to just get something done, cmd is your friend)! Finally, a reboot and clean reinstall of Immunet and it was working fine again. I'm not sure which of these actions cleared the relevant temporary files or database-files that were causing the problem, but this sequence of steps fixed it.
  2. I have just noticed another thing: The settings are forgotten if you run a scan. Steps to reproduce: 1. Change and apply settings. 2. Run a flash scan. 3. Return to settings dialog. Expected behaviour: my settings persist Actual behaviour: my settings forgotton; settings returned to default. Just to confirm everything is online (I can scan etc) and no error messages are appearing.
  3. I've tried a fresh install of Immunet twice now, with the same behaviour. The version I currently have installed is Machine is Windows 10 Pro x64. If I open the settings dialog, change the settings from default (for instance, ask on detection / blocking mode / scan inside archives / scan packed), and hit apply, the settings are not remembered after reboot (or after quitting and restarting the immunet tray icon, or restarting the immunet service). Expected behaviour: My settings persist until I change them Actual behaviour: Default settings return after restarting PC or Immunet tray client or Immunet service. Steps to reproduce: 1. Change and apply settings in the settings dialog. 2. Restart either IPtray, Immunet service(s), or PC. 3. Return to settings dialog and check settings.
  4. Immunet is intended to be a companion AV, much like MalwareBytes is intended to be a companion antimalware. However, there is a slight problem that prevents this happening if you use Windows Defender as your main AV in Windows 10. That problem is Immunet's security-centre integration. In versions of Windows prior to 10, the security centre detected installed antimalware software, but did not automatically disable Microsoft Security Essentials/Defender when present. This caused problems with multiple installed AV programs running simultaneously. A user who installed a 3rd party AV had to manually disable/uninstall Microsoft's AV. As a result, Windows 10 now automatically disables Windows Defender if it detects a third party antimalware solution is installed. For the vast majority of cases, this is desirable to preserve system stability. For companion AV software such as Immunet, this is an annoyance. When you install Immunet, it integrates itself automatically in the Windows 10 security centre. This disables Windows Defender. This is undesirable, as Immunet is a companion AV, and if run alone, it has a lower detection rate, so the net result is a level of protection that is lower than the level provided by Windows Defender! In previous versions of Windows, it was possible to achieve great protection by running Windows Defender in parallel with Immunet. In Windows 10, one would need to install another 3rd party antivirus solution in order to run Immunet as a companion AV. In this case, Windows security centre warns the user that they should not be running two antivirus solutions in parallel! The way MalwareBytes solves this problem is to have an option for "security centre integration" in their settings dialog. That way, if the user wants to use MalwareBytes as the sole protection on the computer, they can enable the option. If they want to run it as a companion program, they can disable the option. So my suggestion is to add "security centre integration" to the list of toggle switches in Immunet's settings dialog.
  5. @Deathinition as I scrolled down this thread I knew you were using either Chromium or a Chromium-based browser. Are you, by any chance, also using either UBlock Origin or Nano Adblocker in it? I repeatedly get this detection from my Immunet install. The filename of the detection is always "f_" followed by a hexadecimal number, and it is always in my Vivaldi (another chromium-based browser) cache folder. In my case, it is a false-positive on one of the blocklists used by UBlock origin. Some of ClamAV and Immunet's signatures trigger on certain malicious web links in text files. UBlock's blocklists are text files filled with, amongst other things, fragments of malicious links (after all, UBlock needs to know what to block). Immunet, unfortunately can't distinguish between "my evil malware site dot com" as a place to go, contained within an evil script, and "my evil malware site dot com" as a place *not* to go, contained within a blocklist! It just sees the link and has to take the cautious approach. I get this same detection if I do a manual scan of my /home directory with ClamAV on GNU/Linux (the OS where I spend >99% of my time). In Vivaldi, there's also a built-in feature that blocks certain really aggressive malvertising features. Most browsers also use the Google safe-browsing database as well. Both of these features of course contain lists of web sites for the browser to avoid - and as a result, both of these features have also triggered this detection in my copy of Immunet before now. But most of the time (almost every time I get this detection), it's UBlock origin updating its filter lists. I can even repeatedly trigger the exact same detection by manuallly forcing UBo to update its blocklists.
  6. I had a quick look at task manager on my Windows PC a bit earlier. Immunet was using about 40-80MB - but it gradually rose to about 350MB while I was observing it. The PC was seemingly idle. However I looked at the "Windows update" dialogue, and it was performing an update in the background, so I think the memory spike was due to Immunet's realtime guard scanning lots of files. The above was measured with blocking mode on and all scanning engines enabled. I suspect that if you disable ClamAV and rely solely on the cloud engines (Ethos and Spero), your memory and CPU usage will decrease significantly - probably down to the tens of megabytes range. I rely on the ClamAV engine as I have an extensive set of custom signatures, so I leave it enabled. If you are always online, then the cloud engines alone will probably provide you adequate protection.
  7. I remember in earlier versions of Immunet, possibly circa 2.0 or 3.0, there was a bug that caused excessive hard disk usage. If I remember right, I think it was related to Immunet's internal logging (scan-result cache). If something caused the realtime guard to scan lots of files, or if the user initiated a system scan, Immunet would thrash the hard disk mercilessly and bring the whole computer to a crawl. Of course, people with SSDs didn't really notice (unless their SSD wore out). Perhaps some sort of regression has been introduced in version 7.0 that affects certain systems? I can confirm it's not happening on a Windows 10 pro machine with a Core i7 8700k. Is Immunet the sole AV, or a companion-AV? Perhaps the workstation's main AV and Immunet are both fighting for access to something, or scanning each other's temporary files, and detecting each other's file-accesses (causing some sort of scanning loop)? This is the only situation where I've noticed this happen in recent years.
  8. If you enable the ClamAV engine, your memory consumption will rise dramatically. I'm not currently logged in to a Windows machine, so I can't doublecheck my RAM consumption, but mine is never that high at idle - and I have the ClamAV engine enabled with numerous custom databases added manually to improve detection rates. The only time it rises that high (and higher) is when actually scanning lots of things (e.g. performing a scan, or installing a new program).
  9. Hello @nirmeshptl please see my post that is immediately above the one I quote here. It answers all of your questions. Thank you for your interest, but I no longer have the issue with 7.0.0.
  10. Are you using Immunet as your sole AV, or is it a companion to another AV? It may be that Immunet is quarantining that other AV's signature updates or temporary files. Does the location in your Temp folder always change? If it doesn't, you could simply create an exclusion for that file (as long as we can all be confident it's not a true detection of course). If your other AV monitors the Windows temp folder, you could, as a last resort, exclude the entire temp folder from Immunet's scanning - but that would cause a decrease in protection.
  11. Hi all! This is just a quick note to say that I completely removed Immunet, purged all its configuration files and quarantine, manually checked the hard disk for leftovers etc. - and then restarted the computer. I then did a completely fresh install of Immunet 7. I now no longer have the "Error 503" problem. I'd recommend those still having problems to try this, as long as it's not too much trouble for them to do it. Before you do so, make sure nothing valuable is sitting in your quarantine, and make a little note of all the scan-exclusions you added in the settings! I do wonder if the last Immunet in the 6.x series might have corrupted a configuration file somewhere. It might be that this bug has disappeared in version 7.0, and that users just need to refresh their installation.
  12. @Rob.Turner I can confirm that I can either see text or get a download prompt for every one of those links supplied. @ritchie58 Don't worry, I of course still allow Windows updates on my internet-connected machine. I have Pro so am fortunately able to defer any non-security updates for up to a year, which I recommend everyone should do before their PC gets bricked. It gives Microsoft a good chance at fixing the worst of their problems before their "improvements" reach your machine - unless the next broken update they release without testing just happens to be a security one... As a side note, When your Windows 7 reaches end-of-life, one option would be to just have a dual-boot scenario: Switch to GNU/Linux for anything that requires the internet, and keep your unsupported Win7 installation as-is, unpatched, for any obscure software you might still need to run occasionally, but can't get on GNU/Linux. You'd just need to keep the Windows 7 installation offline, for instance by disabling your network interfaces in the device-manager, or unplugging your network cables. I'm aware there's a learning-curve, it's a matter of personal taste, and It's not possible for everyone, but I'm about 90% of the way there. I used to dual-boot and value both OSs for their respective qualities, but I'm rapidly getting to the point where I just need to get the work done and Windows now gets in the way of that for me.
  13. I am already in discussion with Rob as he had spotted this thread Nothing odd was found in my log files, which leads me to conclude a recent Windows update has broken something yet again. It's getting that ridiculous, I've actually ditched all my Windows installations apart from one, which I need for a single piece of technical software. I also even use GNU/Linux at work nowadays unless I have to reboot to use a specific proprietary tool. The AV is managed at work, but I've noticed that out of all the machines, it only ever tends to break on the Win10 ones, and even then it's only after an update. Coincidence? I think not!
  14. I have sent a support dump on this issue. I initially thought it might be caused by my custom hosts file, but I have ruled this out (I restored the stock Windows hosts file, rebooted, and the problem persists). Another unusual feature of my installation is that I regularly stop the Immunet services, copy assorted custom databases into the ClamAV folder, then restart Immunet. I doubt this would cause issue (it hasn't in the past), but may make it difficult to interpet the logfiles!
  15. Hello Ritchie, yes still having the same issue. I get the exact same error message, but the ClamAV databases still update as if there's no problem. I also still get cloud detections when I scan my malware archive. I think this issue is simply related to Immunet checking for a new Immunet version. Cloud detection and database updates seem to be unaffected.
  • Create New...