Endpoint Protection

I'm having a problem with SEP 11.0.4202.75 (I think that's MR4 MP2) running on 32-bit Windows 7 RC build 7100.  This is a managed client that I pushed using SEPM, and I have the "Antivirus and Antispyware Protection" and "Proactive Threat Protection" modules installed.

Everything is fine when I'm in the office and when I'm out of the office not VPNed in.  However, shortly after I VPN into the office SMC.exe spikes up to 50% ore more and makes my computer almost unusable.

I've seen a few other people in these newsgroups with a similar issue and one of the workarounds was to downgrade SEP to an earlier version.  Has Symantec corrected this issue or created a workaround that doesn't require downgrading?

So far my computer is the only one with this issue, but I only just started rolling SEP 11.0.4202.75 out to clients.  I didn't want to roll out many clients, fearing that this will happen to them as well.

I'm aware that Windows 7 isn't a released product, however Symantec says that 11.0.4 can be installed on Win7 beta.

Thanks.

What is the behavior after removing the PTP component? What VPN client are you using?


Full support for Microsoft Windows 7 should be within 30 days of the date on which Microsoft Windows 7 GA is released.

Cheers,
Thomas

I have not tried removing PTP, but I can try that when I'm in the office next.  I'm using the Cisco VPN Client version 5.0.00.0340.

-Alex

I tried removing PTP and I still have the same problem.

Are you running any encryption software on this system? Is this a physical or virtual OS image?

This is a Physical laptop, and no, I'm not running any encryption software on it.

Any other thoughts?  My machine is almost unusable while PVNed into the office because of this issue.

Are you still seeing the same cpu spikes when you use Windows 7 built in vpn client? I am following a case currently that hase this same issue with Windows Vista. It appears that the spikes (and somewhat stay at the 50-60% cpu usage) happen whenever the heatbeat occurs with the SEPM. Are you noticing this as well?

Thanks
Grant

How are we doing on this issue? What is the latest?

I am experiencing this same problem.  I first noticed it this week while I was out of town.  I'm not sure what updates may have occcurred since the last time I was out of town.

I am running Windows XP SP2.  SMC.exe shows version 11.0.4202.51.  Cisco VPN client shows version 4.8.02.0010.  This is on an HP nc8430 laptop.

Any additional information or help would be greatly appreciated.


edit:  Other thing to note is that the green check mark on the Symantic Endpoint Protection shield icon in the start menu tray near the clock does not come up.  In the past the green check mark would pop up after connecting to VPN after several minutes.  This no longer occurs. 


Thanks
Josh

I have not yet had an oportunity to try the Windows VPN Client because we don't have a Windows VPN server at the office.  I may try to set one up this weeknd and test it.

I'll also check to see if the green mark shows up on the System tray icon.

Thanks for sharing this. Previously I had only ever heard of this happening on Vista clients. Again are you guys noticing this when the client gets a heartbeat from the SEPM? That is what we have seen in the past. Currently this issue is being worked on by Symantec, but again your case seems to be somewhat unique in the fact that your seeing this on an XP client. For you I might suggest calling and and making a case since your issue seems to be slightly different. Maybe they can diagnose your issue? Who knows? Regardless I will be trying to keep you guys updated with the latest on this. Sorry I can't be of more help.

Grant-

PS
If either of you guys end up making a case with Symantec it would be great if you could post the case number. I can be sure to follow it then and keep updated : )

This thing needs to get escalated I think.
Here is my post:
https://www-secure.symantec.com/connect/forums/smc-service-consuming-50-cpu-all-time

Ok I escalated the actual thread itself to get greater visibility. I would like to ask anyone from support that is looking at this issue to PM me if they want more specifics on this case, as well as checking out Obie's post here as well https://www-secure.symantec.com/connect/forums/smc-service-consuming-50-cpu-all-time. These seem to be the same issue. Also I would like to point out that it has been determined that the VPN is NOT only using just 50% of the CPU. It is actually using 100% but since the machines in question have two processing cores it appears that it the VPN connection is completely maxing out one of them. So any issues relating to a VPN connection maxing out 100% of the processor or 25% of the processor is probably relevant. I will post more specifics soon about the variety of OS's affect as well as the VPN client used.

Grant-

note: I will be editing this post as I gain more information on the issue.

Problem: When connecting using a VPN connection SMC.exe causes CPU usage to spike dramatically. Probably using one full core of the processor.

Jinseng Specifics:

OS: Windows 7 RC build 7100
VPN client: Cisco VPN Client version 5.0.00.0340 & Windows VPN Client
SEP Version: 11.0.4202.75
Server OS: Windows Server 2003 SP2
Green Dot In System Tray: No
Other: Disabling PTP does not seem to fix the issue.

Legacy777 Specifics:

OS: Windows XP SP2
VPN Client: Cisco VPN version 4.8.02.0010
SEP Version: 11.0.4202.51
Server OS: ??
Green Dot in System Tray: No
Other:

ObieOne Specifics:

OS: Vista Business 32-bit.
VPN Client: Windows VPN Client
SEP Version: SEP MR4 MP1 and MP2 are affected. Not seen in MR3
Server OS: 2008 Small Business Server - 64 bit and Server Standard for SEPP Manager 32-bit.
Green Dot In System Tray: Appears for a split second before disappearing
Other: Issue is not firewall related. Fully disabling/using the Windows Firewall does not solve issue.
Also disabling tamper protection has no affect.

Chenh Specifics: (he has seen 99-100% cpu usage, I assume he is running a single core processor. Please let me know if I am wrong)

OS: 32bit WIndows XP SP3
VPN Client: Windows VPN Client
SEP Version: 11.0.4202.75
Server OS: 2003 Standard 64-bit SP 2
Green Dot In System Tray: "I have tested to put the machine into either managed or unmanged group, there is no change between the two."
Other: "I withdraw firewall policy, but I do have network threat protection turned on plus antivius and proactive protection turn on. one of the hardware is Dell GX270"

Ok guys these are the relavent specifics as I see them. If anyone would like me to add anything or can get more information to me I will edit this post as I go. It would be helpful if you could PM the additions you would like to see so we don't flood this thread with duplicate information.

Cheers
Grant

Hi Grant,

Here are some similar discussions where we can collect other customers with the same problem:
https://www-secure.symantec.com/connect/forums/smcexe-using-99-cpu
https://www-secure.symantec.com/connect/forums/smc-service-consuming-50-cpu-all-time
https://www-secure.symantec.com/connect/forums/issue-mr4-mp2
https://www-secure.symantec.com/connect/forums/sep-version-110420275

Actually I know these two internal KB's:
2009061609232548 - The SMC process uses 50% - 60% of the CPU when connected via Windows Vista VPN client
2009061712031848 - migrating to mr4mp2 causes 100% cpu usage with smc.exe

@customers:
If some customers will open a support case, I think is a good idea to refer to the above KB's in order to speed up the initial support and increase the visibility of this issue.

Best regards,

Yes I have looked through those and one of them was created by the guys already in this thread : )

Giuseppe is right though anyone that hasn't already done so should make a case of this. It seems that the memory dumps from the machines are critical in solving this issue. So the more information we have the faster we can get this solved. I am still going to keep this thread going with the same format we have so far, but please if you do open a case PM me with the case number. Myself and Giuseppe will both be working hard to try to bring together all relavent information to solve this. Also it seems that there are some possible workarounds that might work for some of you in the meantime.

1. Downgrade to a previous release.
2. Change the IP adress of the affected client
3. Restart the Network Interface Card
4. Upgrade the VPN Client

Again these are short term possible workarounds. I am not suggesting these as the solution. If anyone needs help on how to execute any one of these workarounds don't hesitate to post or PM. Also if anyone sees any other forums that we may have missed that contain relavent information let us know so we can contact those users to obtain more information.

Thanks
Grant

*edit* : I edited the post and removed a possible workaround. I saw conflicting information regarding whether it works or not, so I want to confirm it before any of you try it. Will post back soon if it does work. : ) . Also it would be nice if you do try these workarounds to let the rest of us know which ones worked for you and which ones did not. These will save time for anyone else attempting them.

New thread I wanted you guys to check out if you have the time. It very well might be related to our issue, and it also suggest that the issue is NOT caused be the actual VPN client itself. To quote eddy_fazer who started this other thread:

"The computers where smc.exe use 50% of cpu doesn't have VPn software.... But i see the ip adress gateway is not in the same vlan's of ip adress. when i change gateway adress to the same vlan of ip adress. smc client can synchronize directly on Sepm and not use 50% of cpu time. "

This thread is located here if you want more specifics on this:
https://www-secure.symantec.com/connect/forums/issue-mr4-mp2#comment-2663941

Thanks
Grant

Grant,

I checked out what Eddy posted about the gateway IP address.  My VPN configuration does not have a gateway IP address for the VPN adapter.  All I have is IP address, subnet mask, DNS, and WINS's addresses.  I believe this is by design and how our VPN was setup, however I will double check.  If that is the case, and the VPN is configured properly, I guess I'm still wondering at least for me, why this happened all of a sudden....and what changed.  We're going to look into this some more tomorrow, and I'll post any updates we may have.

Thanks
Josh

Hi All,

I have been of last week, but this very morning I got a rosponse from Symantec with a small workaround for you as well.
Here is the response. Now, this does not solve the issue, but at least we can get around for now.

"I certainly understand the need to reduce CPU usage, especially on laptops which are more sensitive to heat build-up. As a workaround until a permanent solution is found, you can set the SEP clients on these laptops to the "unmanaged" state. This prevents the clients from attempting to authenticate with the server, which is the process that triggers the high CPU usage. While in the "unmanaged" state, the clients will default to having the option to use LiveUpdate to maintain their definitions. This should allow your clients to maintain their protection as well as connect to the VPN without overworking their CPUs or overheating their laptops. Of course, this is not an ideal situation and we are working hard to remedy it as quickly as possible."

I hope this will help a litle for you guys as well.

Hi all,

did someone test a sylink.xml replacement in a machine to exclude a corruption of this file?
I know It is not a solution, it is a significant troubleshooting step and maybe a workaround.

How to replace the sylink.xml:
- in affected client, disable the SMC service (start > run > smc -stop)
- replace the sylink.xml file in the affected client with the one in a good client (default path C:\program files\symantec\symantec endpoint protection\)
- restart the SMC service (start > run > smc -start)
- green dot?

Regards,

I had allready completly removed and reinstalled SEPP client with the help document (manually).
Actualy that is what I start with if I have any trouble with SEPP.
Therefore I do not think the issue will be in a corruptef xml file.

The issue has nothing to do corrupted xml file. in my case, just use sylinkdropper to move the client from managed to unmanaged is not good enough, I had to use clean wipe utility to remove installed managed version of SEP 11.0.4202.75 and install an unmanaged client on the machine, and I could see smc.exe CPU level back to 0.
I am still waiting for Symantec to have a fix for this issue, I cannot leave my client managed.  

On PCs (Dell PCs) the upgrade works just fine, but on some of my laptops (IBM laptops), shortly after upgrading them to MR4 MP2 SMC.exe will hang the CPU.
Rebooting does not fix the problem. I had to uninstall Symantec all together from the laptop so they can work.

Need a fix for this ASAP before I deploy this to anymore laptops.

Thanks,

Hi all,

thank you for your previous answers.
I have another question:
I have a case where the same issue is reported but in some machines that do not use VPN.
What about you? All of your affected machines are in VPN? Exceptions? Do you guess any relation between this issue and the VPN?

Regards,

Easy.
Here is how I reproduce the issue, 100%.

Start up the laptop.
Start taskmgr and observe the smc service running at 0-3%
Connect the VPN and wait for a couple of seconds or right click the tray icon and click update policy to speed it up.
As soon as the client starts 'talking' to the management server (via VPN) the smc service walks up to 50%.
Close the vpn and the smc will drop again in 2 or 3 seconds.

If I am in the office (using LAN) I do not see this issue.
If I connect the VPN in the office, I do not see the issue, since LAN is then the prefered connection.
If I am in the office I get the green dot on the shield as expected.

This morning I have send in some additional logs to my case number.
I hope you guys can fix this as soon as possible.
My own laptop is starting to show overheating problems and I do not think we can claim a new laptop at Symantec.

We did some more testing yesterday, and reproduced the problem on another laptop.  Additionally, and in contrast to ObieOne, if I connect VPN in the office I still continue to have the issue of SMC.exe using 50% of the CPU.

Hi all,

I have another question for all of you. Did you test only the AV components of SEP?
In an affected client, try to remove all SEP components except the AV protection.
Control Panel > add/remove programs > SEP > change > modify... remove all components and leave only the AV protection.
Restart the machine.
Any difference?
After that you can restore your SEP components in the same way as above (CD or packages are not required).

Thanks,

Hi,

then, do you have this issue when the client is not connected via VPN?

thanks

"In an affected client, try to remove all SEP components except the AV protection"

Tried that, when I had tech support on the phone.
No joy.

No, we do not have any problems when the client is not connected via VPN.

Same here.  I uninstalled everything except for AV and still have the issue.

Just confirming what everyone else said, the other two people I have been talking to with this issue have stated that the issue still persist when only the AV portion of SEP was installed.

Grant-

Hi,

I quickly reviewed the status of all cases already linked to the mentioned KB's, they are in the advanced troubleshooting phase. I will update this discussion when I have something useful for you.

Regards,

Issue similar to ours:

Problem: Upgrading SEP client to 11.0.4202 on a virtual machine causes SMC.exe to use 99% of the VM's processor.

Cause: Looping routing table entry is causing connectivity issues in SMC.exe when it tries to contact the SEPM

Solution:

1. Display the routing table with "route print" command. This table shows the local subnet with the gateway set to an ip other than the local machine.
2. Disable the network adapter or release the IP and re-check the routing table for persistent entries.
3. Remove the bad routing table entry with "route delete"
4. Re-enable the network adapter or renew your ip address
5. Request a policy update from the SEP client and you will see a green dot now on the shield icon.


If you need more help or need more clarification on any of the steps listed above please post or call in and make a case and a technician can walk you through it.

Hopefully this all helps.

Grant-

Hi Grant,

your post is very interesting, I hope this solution will be confirmed by other customers to lead us in the right troubleshooting path. Of course I will continue to search the answers to the three questions stiil open:

1) why this issue was triggered by the migration to MR4 MP2?
2) how to fix it in several PC's?
3) how to prevent it?

Regards,

I have two members servers running in Hyper-V server, but I have not seen any issue's.
I can also hardly imagine, this would have something to do with a routing table, since SEPP works normal when inside (LAN), but fails when connected by VPN (WAN).
All other network related stuff is working normally, if there would be anything wrong with a routing table, we would not be able to do other stuff as well.
Or am I wrong here?

Again this solution was passed on to me from another tech that troubleshooted the issue with a customer. However the one looping routing table entry would not neccessarily mean that you couldn't do other network related things. It just depends on where the looping routing entry happens, and according to the tech (and backed up from what I have heard in the forums) the routing table loops exactly when a policy update occurs. So you would probably notice that the SMC.EXE hits the 99% only after a heartbeat or when manually requesting a policy update. That is also why there is no green dot in the clients GUI, and it is also why changing the client to unmannaged takes care of the problem. I am very curious to see if this solution to the problem works for you guys. It makes sense to me, and it seems to fit with the symptoms of this problem. Also the routing table is different when the users connects via VPN vs. LAN so that is why it works normal when inside (LAN) but fails when connected via VPN. I am not the best networking guy, and if someone can explain this better please do so, but it makes sense to me : )

Grant-

To whom it may concern.

Last week we had a very serious issue (again) with SEPP.
This time our main SBS2008 server would freeze completly.
It appeared the problems came from SEPP (again) screwing up the new console.

During the trouble shooting process, I had deployed new Install Packages to our server and my own laptop.
Now this very morning, while working out of the office, I noticed SMC DID NOT walk up to 50%.

So I researched a little further and noticed I had (accidentely) deployed 11.0.4014.26 to the vista client.
The SBS and the SEPP management server are both still running 11.0.4202.75.
Also I had disabled the following policies; Firewall, IPS, NTP and Apl&Dev control.

Lastly I created a new install package (4204.75) and deployed it to the vista client.
This made the SMC issue return again.

So for now I downgraded to 4014.26 again, until the issue will be resolved.
ps. MR4 MP1 and MP2 work happely side-by-side.

 

It seems that the Eddy_Fazer's solution is confirmed by another customer (not joined in this discussion).

Regards,

Several cases with the same symptoms were collected and our developers are working on it.

Regards,

Seeing how it's already been stated there will be no MP3 for MR4, and that MR5 will be the next release, and that MR5 is months away ("mid September"), what is the likelihood that this will be resolved in a timely manner?  Or, has the patch schedule been changed to accomodate this seemingly widespread bug?

Too early to say something.

For a temporarly workaround, one could downgrade to MR4 MP1a.
Not a final resolution, but at least it will not kill your processors.

When everyone is experiencing this issue, are you loading the network protection initially?

I have run into an issue similar, in that if the network protection is loaded at all (IPS or Firewall), the machine in question will lose network connection and 1 CPU's usage will be greatly increased.  This goes on for it seems forever.  If you reboot the machine, everything returns to normal for a while.  When this happens, no green dot.  Just maxed CPU on one (the first) CPU.  On single core boxes, this will be 100%.  On dual-core, 50%.  On Quad core, 25%.  On dual quad core, 12-13%.

Uninstalling the client (seemingly completely) will not fix the issue...there are still remnants of the NAC (teefer2 miniport) laying around, and they still get initialized upon reboot/restart.  I proved this because I did what I thought was a complete uninstall, rebooted, and in the registry and some other places, the damned teefer2 miniport was still being loaded.  My monitoring software (SolarWinds Orion) verified this as well, as the name of the interface being monitored on this server never changed...it should have gone back to its original name, which it didn't.  I backed this up by exporting a package with only the antivirus/antispyware option, nothing else.  Installed that and rebooted.  Let the server sit for a while, and a short time later came the 13% constant CPU usage on the server in question, which equalled 100% of one core.  Verified it in Task Manager.

Found the cleanwipe utility on the web, ran it, rebooted the 2 times, came back to find my network card hosed up.  Had to re-install the drivers, re-team my network cards.  Once I did that, I was golden.  I then installed the previous version (11.0.4000.2295) with only the anti-virus/anti-spyware options and am now testing...but I'm 99.99% sure it's going to work like it should...I have 11.0.4000.2295 deployed everywhere else without issue...been running for 6 months or more.

Summary:  I believe this issue is actually with the network protection component.  If you installed it once, it's there until you run Cleawipe, whether you like it or not...and I believe it's actually to blame here.  This corresponds to the routing table issue mentioned above as well.  Since the teefer2 basically intercepts all your network packets, anything going through it (all traffic) is going to be affected...likewise, a change in network status is going to affect it one way or the other.  I think the behavior with the VPN client is actually sort of lucky...at least you maintained network connectivity.  In our case, this problem took one of our domain controllers completely off line until someone could get on the console and remove the software and reboot 2-3 times.

Please get it together Symantec.  2 years after this product line is released, we're still having issues like this.  I'd hate to go to McAfee, but I shouldn't have to test YOUR product for you for months, before figuring out that it doesn't work.

<QUOTE>
Please get it together Symantec. 2 years after this product line is released, we're still having issues like this. I'd hate to go to McAfee, but I shouldn't have to test YOUR product for you for months, before figuring out that it doesn't work.</QUOTE>

Better make that almost 3 years.
We have been there since the initial release.
It has never been a trusty product and SEPP has costed tons of time and money for us.
Symantec will not pay us for beta testing this product.
We are seriously considering a switch to another vendor over here.
3 years of beta testing... what the h....

Oh yeah,
For those of you interested, we just installed our first Symantec Protection Suite (SEPP V12) on a clients site. SBS 2003 with Vista clients, guess what, it grounds the network to a halt.
Really good progress guys, especially if you are market leader.

When you have serious problems like this Symantec should highlight it.
 
I think it would be good if this release was either taken away or that its release notes would be updated to explain the problems related to it.

I was just about to update our clients to this latest version but then I stumbled across this thread. Now I will wait for the next version.

The problem is when will the next version be tested enough to be trusted for production?

Hi,

Symantec is aware of this issue and the proper investigation is in progress.
http://service1.symantec.com/SUPPORT/ent-security.nsf/docid/2009061712031848

It is a serious issue but it is affecting only a small percentage of installations and several workarounds are available. I think that Symantec will not take away this release but I agree that this issue should be fixed in the next release.

Regards,

I was a bit concerned when I read this thread, as we extensively use VPN and have rolled out 4202.
We are not however seeing this issue, which was a relief.

A bit puzzled, I asked my network Guru to have quick look at these threads, and he said (in language I only partly claim to understand) - Oh yes, it looks like they are having problems with the way routes are being added for VPN connections - our is probably OK because we disable split tunnelling, so it does it the other way round....

It be worth the folk experiencing this to try disabling split tunneling to see if that is another viable workaround?

Nick
 

But I think this knowledge should be bundled together with the release notes or similar so that administrators that have not yet upgraded be aware of it.

Well I don't have a fix, but we did get a temporary work around.  A batch file was setup to delete the bad route and then update the Symantec Policy.  Once connected via VPN, I run the batch file.  I've tried it here at work with success, and will give it another test this evening at home when VPN'd in.

Here's the jist of it.

Route Delete x.x.x.x

cd "c:\Program Files\Symantec\Symantec EndPoint Protection"

smc -updateconfig

cd "c:\Program Files\Symantec AntiVirus"

smc -updateconfig

We've not experienced any issues with VPN.  I've got 4202 on my laptop (the only workstation/laptop deployment of 4202 in our organization), and I have no issues with any of the Cisco VPN clients.

Our problem right now is isolated to servers with Broadcom network cards that are teamed, running 4202 with or without network threat protection enabled.  However, the same symptoms occur...network cards in the machine are all fine, no access to the management server, upon reboot everything is fine, one CPU core completely maxed out.  Cleanwipe actually doesn't fix it.  Issue comes back after arbitrary amount of time after reboot.

Currently I'm going through this document:

http://service1.symantec.com/SUPPORT/ent-security.nsf/docid/2007073018014248

And trying to see if that makes a difference.

FYI, after running cleanwipe, to get the results from the link above, do the following (this is the stuff that cleanwipe doesn't do):

Delete the following 4 registry keys:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ESENT\Process\ccSvcHst
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\RFC1156Agent
HKEY_LOCAL_MACHINE\SOFTWARE\Symantec\SyKnAppS
HKEY_LOCAL_MACHINE\SOFTWARE\Symantec\Symantec AntiVirus

Optional:

* Browse to the following key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\FltMgr
* Change the "AttachWhenLoaded" value to 0 (zero)

Browse to the following key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RasMan\PPP\EAP\13 and delete the following values in the right pane:

o ConfigUiPath
o IdentityPath
o InteractiveUIPath
o Path

# Now rename and remove the "Backup" portion from the following values so that the values match those deleted from the preceding step.

o ConfigUiPathBackup
o IdentityPathBackup
o InteractiveUIPathBackup
o PathBackup

Note: If the "Backup" entries do not exist, please re-create the appropriate values as follows (the values are of type Expandable String Value):
ConfigUiPath = %SystemRoot%\system32\rastls.dll
IdentityPath = %SystemRoot%\system32\rastls.dll
InteractiveUIPath = %SystemRoot%\system32\rastls.dl
Path = %SystemRoot%\system32\rastls.dll

# Browse to the following key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RasMan\PPP\EAP\25 and delete the following values in the right pane:

o ConfigUiPath
o IdentityPath
o InteractiveUIPath
o Path

# Now rename the following files by removing the "Backup" portion from the name so that the values match those deleted from the preceding step.

o ConfigUiPathBackup
o IdentityPathBackup
o InteractiveUIPathBackup
o PathBackup

Note: If the "Backup" entries do not exist, please re-create the appropriate values as follows (the values are of type Expandable String Value):
ConfigUiPath = %SystemRoot%\system32\rastls.dll
IdentityPath = %SystemRoot%\system32\rastls.dll
InteractiveUIPath = %SystemRoot%\system32\rastls.dll
Path = %SystemRoot%\system32\rastls.dll



Hope this helps.

I found this Article via cached Google page (no loger available at symantec) Im getting this on an ISA server with 2 nics, Internal and external, the internal interface has no gateway configured as all internal routes are determined by the static routing table. I therfore have no option but to downgrade.

Document ID:2009061712031848 Last Modified:07/15/2009

Migrating to MR4 MP2 (11.0.4202) causes smc.exe to use 100% of the CPU.

 

Situation:

After Migrating to MR4 MP2 smc.exe increases to 100% (or 50%) of the CPU usage and does not decrease.

Solution:

Short term workarounds: Install an unmanaged client. Downgrade to the previous release. (11.0.4014.26) Change the default gateway on the affected client to an address that exists on the client's subnet. Make sure clients aren't using an incorrect gateway or subnet mask. If using a VPN connection, enable the VPN to use a VPN supplied default gateway instead of using the local physical adapter's gateway.

Technical Information:

Conditions found that will cause this behavior: Using only physical interfaces, create a network configuration containing a default gateway that falls outside the subnet of the local workstation. Networking will work outside of SEP communication if the gateway is on the same broadcast domain as the workstation (it will be able to respond to ARP requests). Configure a VPN connection to use the physical NIC default gateway instead of using a gateway supplied by the VPN connection. Have the SEPM be otherwise accessible over the VPN connection. Add a static route: route add {local subnet} {IP of gateway} 1. This command will create a static route that will logically cause the local computer to require access to the gateway to access the gateway (loop logic). Windows itself appears able to recognize the loop logic and access the gateway despite this route while the SEP client appears unable. Keep in mind, SMC.EXE is not multiprocessor aware. On a single core processor, CPU usage will reach 99%. On a dual core processor, usage will hit 50% and so on.

References:

Discussions in the forum: http://www-secure.symantec.com/connect/forums/smcexe-using-99-cpu http://www-secure.symantec.com/connect/forums/smc-service-consuming-50-cpu-all-time http://www-secure.symantec.com/connect/forums/issue-mr4-mp2 http://www-secure.symantec.com/connect/forums/sep-version-110420275 http://www-secure.symantec.com/connect/forums/smcexe-using-50-or-more-processor-while-vpned-office

Product(s): Endpoint Protection 11
Operating Systems(s): Windows XP Professional Edition, Windows Vista, Windows XP Professional x64 Edition, Windows Server 2003 x64 Edition, Windows Vista x64 Edition, Windows Server 2008 Enterprise 32-bit, Windows Server 2008 Standard 64-bit, Windows Server 2008 Web Server 64-bit, Windows Server 2008 Web Server 32-bit
Date Created: 06/17/2009

Hi all,

SEP 11 RU5 was released a couple of days ago, did someone already test it regarding the issue of the smc.exe process?

Regards,

I was able to briefly test it last night on my WIndows 7 RTM machine and it seemed to work fine.  I'll test it for more time this weekend and report back.

-Alex

 I am also very interested to see if the problem in this thread will be solved by RU5. Keep us updated on the result. Thanks!

I would really love to get some feedback as well, before diving into the next Symantec upgrade and keeing my fingers crossed for the next issue.
Besides, for all my critical clients I am in the proces of upgrading them to SEP V12, which seems much more stable.
For testing version 12, I had to break down my test lab, if possible I'dd prefer not to roll back my lab to V11 again.

Regards, Arno

SEP 12 is a lighter product then SEP .It is a bit scalled down version of SEP 11 and also it is for small buisness

https://www-secure.symantec.com/connect/articles/symantec-endpoint-protection-small-business-edition-120-frequently-asked-questions

I am running RU5.  I can confirm that this problem still exists when using the network threat protection.  (and i should note (though I am sure others have) that the memory usage also skyrockets slowly but surely to upwards of 7-800 megabytes or more in short order.  if you disable NTP, the problem goes away.  (note, this is a connection using OpenVPN, if this makes a difference)

Bummer that you're still experiencing problems with this.  I don't know why Symantec can't get this right.  I don't have NTP running on any of my clients so I don't have any issues.  I've been running the most recent client on my Windows 7 machine for a few days now without issues.

bump.

are there any updates on this problem?

veritas72,

I'd suggest trying the latest release.  It worked fine on my Windows 7 machine.  I only removed it because my company decided to investigate other products, not because it was causing me any more grief.

Hi,

I have some expierence sharing with you guys.

First of all ,pls confirm if you've added several exclusion list for PTP?if not, remove SEP by add/remove program, check your registry.

HKLM\Software\Symantec\Symantec Endpoint Protection

Del the branch, check if any items can't be deleted? If yes, that's the  criminal which caused the 50% of cpu usage.

You may use proecessMon for monitoring.

How to fix it?
1.Starting system using winpe.
2.start regedit
3.select HKLM , then select  "file"-"load hive" at the upper left corner of regedit console.
4, open c:\windows\system32\config\software , the local software branch is stored in this file.
5, rename the branch which can't be deleted.
6. restart the system, then reinstall sep.

-Donnny

Can you please explain what you mean by this bit - I'm not sure if we've done this or not - exclusions? Where?
>>First of all ,pls confirm if you've added several exclusion list for PTP?<<

I'm really wondering if this is related to our having SERIOUS issues with SEP's NTP making GHOSTCAST choke.
I don't think it's targeting the ghost packets specifically, but choking ALL traffic and pegging the CPU, and causing ghost to choke in the process. I think it's a GENERAL choking of ALL network traffic on those computers.
And we do have general network slowdowns with SEP involved.
We're thinking SEP is causing ALL traffic to be throttled back, so bad that it causes ghost to not work well on some computers, and general network browsing to be impacted.
It's not choking down ALL traffic types - only certain traffic is being impacted.

My bet is that the problems being described in this thread are somehow related to the problems I'm trying without ANY luck to get resolved here involving GHOST and network performance that sucks.
Disable SEP, and things fly. Remove SEP, performance improves.
Go to SAFE MODE with networking and suddenly word documents open and save in 1/3 the time they normally do.
Disable SEP on a notebook acting as a ghost SERVER and suddenly instead of taking AN HOUR to image a pc, it takes 9 minutes...... SEP.

 Shadowspapa which version are you using of SEP Server/Client? Which features are you using?

A. The latest - RU5 on EVERYTHING
B. Pretty much everything on everything. (why use less? If you don't use the features, might as well stick with SAV or the consumer products)

We've got folks who literally pretty much can't work it's so bad, and others who say there's little impact.
For the issue of SEP choking GHOSTING down to a crawl - some of the computers we test ghostserver on work great, others choke and are nearly impossible to use as a ghost server.
I think it's interactions between SEP and other things - otherwise, would it not impact EVERYTHING?
I dunno - I've spent literally, no kidding, 11 full months on this and have no clues to this point. Been this way since December of 2008. The ghost thing we just discovered because we just started attempting to use "mobile ghost servers" a couple months ago. But SEP actually prevents it. We have to uninstall SEP or disable it in order to ghost from those machines.
Network performance here is literally so bad the whole of IT has been dealing with it and we can't find a full solution - other than completely using clean-wipe on all computers and going without protection. But SEP is only part of it - there's other issues too - just that SEP compounds those issues.  Even with SEP removed it takes several seconds to access and open a Word document. With with SEP, it takes several minutes.