TCPSVCS.EXE @ 100% utilization

Chuckenheimer, I don't know if the service is really necessary. I use a network printer so I assumed that I probably did need it based on the description. I will check into that.

Zac, your suggestion may be related - I will see if MS will let me have a crack at that pre-released fix. But the last time I requested a fix that had not been released yet, they just about made me beg..... It was a really big run around......

For now I am leaving it in the exclude list since that is working - until we can find an answer.

Thanks!

 

Ok, I called Microsoft...

After a little bit of being bounced around I was able to get the patch. I am currently in the middle of reinstalling Windows.... so, I will apply the patch shortly with the other windows updates and then everything else.

I will let you know if this works or not, hopefully by Sunday - providing what's left of Hurrican Ivan does not cut off my power. Its been off and on all night..... Thankfully I have a UPS system set up.

I will let you all know shortly.

 

hi, i've been looking around at other forums and sites, an it seems we are not alone with this problem [high cpu usage with TCPSVCS.EXE]
the only common software installed on these pc's is windows NT based,
some with SP1 some with SP2.

is it possible we are looking at a new unknown piece of malware as TCPSVCS.EXE opens ports 7,9,13,17,19.

only an idea, but i am having reoccuring problems when connecting to the net or after a restart, system freezing opening programs for aprox 5 mins, if i disconnect it willl resume faster and all programs/services that i tried to open will all open at once.

i do not believe that this is related to NOD32 as many other people out there are having the same problems that do not use NOD.

if anyone has any new info for this problem please let me know, thanks.

 

Sweetie, It is possible that there is some unkown piece of malware out there that is causing these problems.... But I am hoping it is a microsoft issue and the patch we mentioned in this thread will be the fix. I have not had a chance yet to apply the patch as I was reinstalling windows when what was left of hurricane Ivan took out the power. Which was just restored. So, hopefully, I will get a chance to try out the patch in the next few days.

In my case, I was having no problems at all until I installed Nod32 and if I disabled Nod32 or excluded tcpsvc.exe from Nod32 IMON scanner - the problem stopped. This was on a new install, so I really don't think I had picked up any bad items yet. My hope is that maybe Nod32, in its scanning tripped some problem in XP that this Microsoft patch will fix.

But who knows.... By the way, the patch is for Windows XP, SP1 and SP2. So you may want to take a look at it.

 

Sorry, it took so long to get back to you guys...... I did a total reinstall of everything and started with a clean install of SP2. I applied the Microsoft Patch and then installed NOD32. The patch DID NOT help this problem. After installing NOD32 the CPU went right back up to 100% usage.

To date I have heard nothing further from Eset on this issue.... So, I have put tcpsvcs.exe back into the IMON's exclude list.

If Eset ever gets back to me I will let you guys know.

 

I'll see what I can find out...

Cheers

 

Thanks!

 

Hello Turpster,

I work for Eset in Support and I've checked back and can't find any emails regarding this topic from you. I've had a few to and from Chuckenheimer about it. What email address were you sending the enquiries to? If you send it to support@nod32.com or support@eset.com or support@nod32.sk or support@eset.sk .......I or my colleagues will see it. If it was sent to the US Support team, then we wouldn't, unless they forwarded it to us.

Could you drop me a line on one of the above addresses and I'll get right back to you. Thanks.

Bandicoot.

 

Hi, while I don't know what causes this problem, i've seen the same thing with other pc's that have never used Nod32.

To the best of my knowledge it started just before Win XP SP2 came out, affecting machines running Win XP SP1 & SP2.

 

Hello,

I've been lurking for a few weeks now, knowing I didn't have the weight to play with you guys, but I'm ready to jump in and take a shot. Regarding the 100% CPU usage. Would it be an idea to do a "netstst -aon" to see exactly what was going on with TCP?
Also, after an extensive Google session, I've noticed this is by no means limited to NOD32 users. A few people were able to narrow it down to their network protocol, with SPv6 being the most prevalent.
Assuming that the IMON module and the Update module are just trying to do their job, could the conflict lie somwhere in the ports used by both NOD32 and the network? Would changing or eliminating one or more of the default ports in NOD32 change anything?
That's as far out on the limb as I'm willing to go right now. No answers ,just some questions.

Thank you for a great forum everyone,
Suste

 

Hi, I agree with what you have said, it seems to have something to do with the network/IP protocols.

What seems strange to me is that this problem started in about june of this year affecting both SP1 and SP2 of Win XP, a search of the net and various fourms does not show any simularities, dial up, cable and broadband users all affected alike, with many variables in programs and IP protocols.

I heard a guy say that Microsoft released a beta patch speciffically to fix the TCPSVCS.exe problem, although i dont think it worked. [to get the patch u need to contact MS personally.]

I had the same problem, but it has now gone away, possiblly because of a format I did for new hardware.

A real mystery this one.

 

Ok, I've also been sitting on the sidelines on this one. It didn't really affect me so I skimmed through the topic and thought someone else would point out some of the basics. However, it seems that some of the the fundamental concepts behind "Simple TCP/IP Services" still hasn't been explained here, and this quote sort of prompted me into action:

Simple TCP/IP Services is an implementation of a few of the basic core functional testing protocols established by the Internet Engineering Task Force (IETF). These services really have very little practical use outside of a test environment and should not be enabled by most users. Here is a list of the rudementary services we are talking about:

• 7 (TCP/UDP) - Echo (RFC 862) "An echo service simply sends back to the originating source any data it receives."
  
  
• 9 (TCP/UDP) - Discard (RFC 863) "A discard service simply throws away any data it receives."
  
  
• 13 (TCP/UDP) - Daytime (RFC 867) "A daytime service simply sends a the current date and time as a character string without regard to the input."
  
  
• 17 (TCP/UDP) - Quote of the Day (RFC 865), or qotd, "A quote of the day service simply sends a short message without regard to the input."
  
  
• 19 (TCP/UDP) - Character Generator (RFC 864), or chargen, "A character generator service simply sends data without regard to the input."

As you can tell, these services really aren't all that useful unless you need to check some sort of low level network functionality between devices. If you are a programmer and you wanted to check simply that you had the correct code to open a session to another device and send/receive data, then you could use something like the echo service on another machine just to verify that everything worked. But you don't want to normally have them running because they can be problematic in a real world. The chargen protocol, in particular, can be used to implement a rudimentary DoS attack. If an attacker spoofs a session to chargen, then chargen will just start flooding out data to the spoofed address until it's told to stop.

All of the above is not to say that there isn't some real problem that some of you guys have found. There very well likely could be, but most of you should not need or want Simple TCP/IP Services enabled. Perhaps some NOD32 code, SP2 code, or whatever triggers chargen or echo into zooming into action and blasting out data onto the network and eating up CPU cycles in the process. Or, perhaps, someone maliciously is attacking your chargen port and causing it to go into action, eating up CPU cycles in the process. Or, perhaps, there is some other fundamental incompatibility at work. The point is, none of you probably need any of the above... so just disable or uninstall it.

 

Thanks Mr Coot, we look forward to hearing what the outcome is.

Cheers

 

OK, all, I have some apparently good news to report and that is with NOD32 2.12.3 no longer do I see the CPU Utilization jump on SP2. Something was modified such that the race condition no longer exists for me.

That being said, I have removed SP2 until further problem resolution work by MS, so yes it is no longer an issue.

As to the services explanation, thanks a treat for that!

Later,

 

Good to see Charles.

Cheers

 

Well just thought I should put in my .002$ too.

I have analysed the process somewhat, and it seems the race is connected to ADVAPI32.DLL thread in the TCPSVCS.EXE process.

The actual thread looks like this:
ADVAPI32.DLL!CryptVerifySignatureW+0x17

This thread goes bonkers with NOD32 ver. 2.12.2

I'm happy to hear that the problem is solved in 2.12.3, I'm going to try it out soon - I'm not really happy excluding anything that I haven't chosen for exclusion.
I'm perfectly happy to exclude my programming stuff, but not services in windoze...