Excessive Disk Activity

[Sidecar]

I have Immunet AntiVirus installed on three Windows 7 Professional workstations (2 i5s and 1 i3) - works great on one i5 and the i3 but causes excessive disk activity on the other i5. All installations are configured identically. Uninstalling the program on the problem machine eliminates the issue; also, disabling the monitoring of Program Install produces somewhat similar results. At this point, I have Program Install monitoring disabled and Blocking Mode enabled. Anyone have any ideas, thoughts or suggestions?

[ritchie58]

Hello Sidecar,

Is there anything different with the one rig that's experiencing this excessive disk I/O? Any software programs that are not installed on your other machines?

If so, what are they?

[zombunny2]

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.

[Sidecar]

OK here is the deal -- I have six Windows 7 Professional workstations (three x64 and three x86) - all are loaded with essentially the same software packages. I also have 3 Windows 2008 R2 servers (two Domain Controllers and one Web Server - all 3 also act as DNS servers for redundancy). This is what was an IT sandbox/web development network active from 2001 through 2010 - hardware and software has gone through many evolutions over the years but has retained a customized user interface reminiscent of the old Windows 3.11 for Workgroups (yes I am an ancient, old-school die-hard). The web server was initially a gift from Microsoft for product pre-release testing and has run continuously since. Other operating systems were migrated from the Windows 2000 professional platform to their current OS's during that time. For many years, I was a Norton (Symantec) network edition user/promoter, but moved to AVG's network security software during my last corporate IT gig (had found Symantec programs becoming increasingly intrusive and system resource heavy). Continued to use the AVG Network Security system on this personal network until last February when I felt I must seek alternatives for financial reasons (was forced into retirement in 2010 after surgery for a brain tumor and living on fixed income since). Although, I have a Cisco hardware firewall/router, I had become dependent upon the AVG software firewall/antivirus for layers of intrusion protection and malicious software scanning.

So . . . after giving up AVG, I activated Windows Defender and Windows Firewall on all machines plus began the search for a suitable antivirus replacement. Immunet was the optimal choice since it was FREE and was compatible with all servers and workstations plus seemed to function without conflicts with the internal Windows programs (I think my first download was version 6.2 something). Had been very happy with the results, however, I first noticed the 'excessive' disk activity thing on the web server after the second Immunet upgrade. I thought that it was a firewall issue and was driving myself nuts trying to diagnose it as that until the last upgrade to version 7.00 (this network now handles all of my personal business needs; provides graphics services to my photographic 'hobby' - was a high-end commercial photographer with a large studio of my own in Cincinnati, Ohio for the first 20 years of my adult life;  houses and extensive digital collection of all CD's and DVD's accumulated over the years by me, family and friends; contains over 48 TBs archival storage and backup; is my own personal cloud).

If you have read this book so far . . . the final chapter is this . . . the problem was definitely not a memory consumption problem.  The two x64 workstations referenced in the initial post are an i5-3570 (8.00 GB RAM / 12205 MB paging file) and an i5-2500k (16 GB RAM / 24600 MB paging file).

Paging file size is fixed; all workstations have Western Digital VelociRaptor WD5000HHTZ SATA drives that host only system, software and paging files - the one exception is the i5-2500k (16 GB RAM / 24600 MB paging file) which has two WD5000HHTZs in a stripped RAID configuration - this is my primary media workstation with 3 monitors and a HDMI TV 'single screen display' (MSI G31TM-P21 motherboard).

All other machines have 2 monitors in a 'single screen display' (no, I do not have 19 or 20 monitors - I have an IOGEAR 4 switch and 2 IOGEAR 2 switch hubs). The i5-3570 (8.00 GB RAM / 12205 MB paging file) workstation is the one that developed the 'excessive' disk activity problem after the last Immunet upgrade (Version 7.00). The program was completely uninstalled, a registry scan was done to search for any residual keys and it was then reinstalled but the issue persisted. I finally traced the problem to the sfc.exe file which exists only in the Immunet folder on my 'System' drive of this machine. At this point, I suspected that the Immunet software was scanning all installed software and creating a 'record' of 'safe' installations, so I ran a full scan (a very long process since this station has a total of 4 TB disk space and about 400 GB of files); the problem still persisted, so I then left the machine in an idle state for 48 hours with no change. That was when I changed the default installations to > Monitor Program Install 'Off'; Monitor Program Start 'On'; Blocking Mode 'On'; Monitor Network Connections 'On' - and the problem immediately disappeared!

As an aside, I have also notices that one of the 3 x86 stations has the problem of showing Computer 'Not Secure' since the software upgrade to version 7.0.0 even after doing both a full scan and a flash scan - there is no unusual disk activity on this machine.

Additionally, for what it is worth, I have found an sfc.exe file in Windows System32 and SysWOW64 on the primary workstation but on neither of the other 2 x64 machines (the one with the initial 'excessive' disk activity problem and the one with the "Not Secure" GUI notice perpetually). It also is found in these Windows folders on both domain controllers.

I shut down the web server two weeks ago due to fears that a hacker had managed to penetrate all intrusion protection and decided to upgrade the old Dual Core Pentium motherboard to an i5 - now that I know what the disk activity issue is, I will post an update after the modification is back on line.

For those who might be interested, I have used Acronis Universal Restore for many years to successfully install system drives on new hardware without rebuilding a disk and restoring a machine to a new drive without reinstallation or reconfiguration of anything.

In reviewing documentation for the treatise, I just discovered that the one domain controller where I had also seen 'excessive' disk activity at the same time I first noticed it on the web server and where I first came up with the Monitor Program Install 'Off'; Monitor Program Start 'On'; Blocking Mode 'On'; Monitor Network Connections 'On' workaround (but did not work on the web server) shows AppCrash_sfc.exe_* files in the C:\ProgramData\Microsoft\WER\ReportQueue folder and corresponding sfc.exe.*.dmp files in C:\Windows\System32\config\systemprofile\AppData\Local\CrashDumps -- and I thought that machines' random unplanned shutdowns were due to a very old UPS unit and or sporadic brown outs here in the back woods of Indiana (even though diagnostics hadn't found any problems). Now I need to dig through my system event logs to see if I can ferret out additional info . . .

In the meantime, if anyone actually read this far, I welcome thoughts of all kinds . . .