Endpoint Protection

Hi Folks,

Got this from one of my users - running XP and SEP 11.0.4010


---------
For no apparent reason it will thrash the disk and use 20-40% processor time, and when I check what it’s doing with Filemon it’s just reading its own files and directories as fast as the poor hard drive will let it. It managed 250,000 disk access requests in less than five minutes yesterday until I gave up and rebooted XP. It seems to do it at random times of the day, or every time I put the machine in to standby and wake it up again, thus making standby mode useless (as I have to restart to get it working again).
---------

Anyone any suggestions?

Ta
Nick

Whats the system cofiguration and what are the application u r using?????

I had this reported to me from one of my people yesterday.  Machine would just start thrashing the drive at random times of the day.   I have the defwatch scans turned off.   I am suspecting some kind of malware that symantec didnt detect.   The machine that it was happening to was just a base image so it was easier just to reimage the machine that to spend too much time on it.   If anyone else has seen this Id love to hear about it.  The only thing that I noticed was that run32dll  using a fair amount of the processor time.

I'd have suspected something dodgy and undetected myself if it wasn't just appearing to be SEP thrashing the HDD accessing it's own files (not completely excluding the possibility though)

TBH Ajitjha - was just asking to see if it rang any bells with people, or was one of many 'known' or suspected issues. But FWIW, appears to be happening irrespective of applications loaded, can be just the OS booted up with nothing else. Config is full SEP installed, no SNAC. Auto protect ON, using default settings.

thanks
Nick

More than likely this is what is referred to as an "Active Scan". The product by default is set up to scan quarantined files whenever new definitions arrive from the management console.


Title: 'Symantec Endpoint Protection Manager - Antivirus and Antispyware - Policies explained'
Document ID: 2008032010461048
> Web URL: http://service1.symantec.com/SUPPORT/ent-security.nsf/docid/2008032010461048?Open&seg=ent

I have active scan turned off but still was seeing this.

 

Hi Ted,

We also have Active Scan on new def arrival turned off too.

Thanks
Nick

Whic process is using 20-30% of time? 

it's our old friend SmcGui.exe taking the 20-30%, with Smc.exe backing it up with 5-10%


When I reference 'old friend', I refer you to -
https://www-secure.symantec.com/connect/forums/smcexe-and-smcguiexe-wall-pain

I just had a call from one of my field people with another one with similar symptoms  CPU had settled down before he called me but I did find that the stumbleon tool bar had been installed.   Did a few google searches on this and that might have been the cause on that machine.

I have 3 different hosts for my VMs. On all VMs SEP 11 MR4 MP1a is installed.

the oldest host has older Intel CPUs without any hardware-assisted virtualization. I use MS Virtual Server 2005 R2 SP1 on this host, the CPU load of smc on the VMs (Windows XP, Windows Server 2003) is not good but ok (10%).

The second host has AMD Opteron 2.6 GHz CPUs whitch have AMD-V activated in BIOS. I use also MS Virtual Server 2005 R2 SP1. On the Vista VMs, smc use 50% CPU (saw tooth) as long as no user has logged on. If a user has logged on, smc use "only" 30% CPU.
If I disable the use of any hardware-assisted virtualization in the configuration of a VM, smc use "only" 20% CPU if no user has logged on. If a user has logged on to a VM, the CPU load of smc falls to lower than 10%.

My newest host has Intel CPUs, with hardware-assisted virtualization turned on in BIOS. I use Hyper-V in W2K8 x64. On all VMs (Vista, W2K3, XP W2K8, all 32 Bit) the CPU load of smc is lower than 10%. I made no tests with 64Bit VMs.

As I can see with my Hardware, SEP seems to have trouble with the AMD-V (hardware-assited virtualization) but not with Intel.

Perhaps someone can confirm this?

try to understand what is the customer requirment there after installed the SEP

Hi,

it seems that nobody suggested to NickF to upgrade from 11.0.4010 to 11.0.4014 because the 11.0.4010 has a serious bug and it was already called in.

Regards,

Thanks for the suggestion Giuseppe, but the user is already on 4014... always was.
The reason I mistakenly quoted 4010 was because I'd got that info from the log on records we keep, which are derived from WMI data.

I hadn't realised at the time that in your haste to release MP1a, you didn't update the WMI version info SEP was registering.

Anyhow, 4014 was designed to fix one bug only - something to do with calling a network application from URI links IRRC, (which we were affected by, and I'm well aware of the symptoms of, and which were/are completely different to this issue).

Thanks
NIck