Service Host
If you ever look in Task Manager under WinXP you have probably noticed at least one instance of this process. It's not unusual to have four or more simultaneous instances running with various memory footprints.

SVCHOST's function is to start various OS and network services. The reason not all instances of SVCHOST are created equal is because each particular instance is hosting different numbers and types of services.
If you'd like to see what services are running under which instances of SVCHOST and you have WinXP Pro go to the command prompt. You can get to this through Start>Programs|Command Prompt or through Start|Run and typing CMD. When you have the command prompt type tasklist /svc.
You should see something like the following:

C:\>tasklist /svc

Image Name                   PID Services
========================= ====== ===========================
System Idle Process            0 N/A
System                         4 N/A
SMSS.EXE                     308 N/A
CSRSS.EXE                    400 N/A
WINLOGON.EXE                 424 N/A
SERVICES.EXE                 468 Eventlog, PlugPlay
LSASS.EXE                    480 PolicyAgent,
                                 ProtectedStorage, SamSs
SVCHOST.EXE                  644 RpcSs
SVCHOST.EXE                  696 AudioSrv, CryptSvc, Dhcp,                   
                                 dmserver, ERSvc,                
                                 EventSystem, helpsvc,                  
                                 Messenger, Netman, Nla, 
                                 RasAuto, RasMan, Schedule, 
                                 seclogon, SENS, 
                                 ShellHWDetection, srservice, 
                                 TapiSrv, TermService, 
                                 Themes, TrkWks, uploadmgr, 
                                 W32Time, winmgmt, WmdmPmSp, 
                                 wuauserv, WZCSVC
SVCHOST.EXE                  768 Dnscache
SVCHOST.EXE                  784 LmHosts, RemoteRegistry, 
                                 SSDPSRV, WebClient
SPOOLSV.EXE                  944 Spooler
EXPLORER.EXE                1256 N/A
PackethSvc.exe              1656 PackethSvc
alg.exe                     1676 ALG
cisvc.exe                   1692 cisvc
wanmpsvc.exe                1784 WANMiniportService
cidaemon.exe                1748 N/A
wmiprvse.exe                1200 N/A

The process IDs, services, and image names will possibly be different for your system.

SVCHOST has an annoying tendency to periodically grab up all your available CPU cycles for no apparent reason and then not let go for several minutes. This is due to one of the services hosted by the offending instance suddenly deciding it needs to do whatever it is it does. If each service was listed as a separate process it would be easy to spot which service was misbehaving and kill just that particular service. Unfortunately, SVCHOST lumps several services together, so if you kill the process you kill all the services being hosted under that instance. It also makes it difficult to identify which service is the CPU cycle coopting culprit.

The first step to stopping SVCHOST from periodically hijacking your computer is, ironically, to figure out how to get it to do just that. If you know what triggers it, you might want to check the bottom of the node to see if it's listed in "Known Issues."
Once you know how to trigger the effect, get your computer back to normal and open Task Manager and the Command Prompt. Get a services tasklist for the nominal state by typing tasklist /svc at the command prompt and have the Task Manager on the Processes tab with the list sorted by CPU use. Type tasklist /svc at the command prompt again but do not press enter yet. Ready?
Do whatever it is that triggers the annoying behaviour in SVCHOST. Look at Task Manager to verify SVCHOST is trying to eat your computer, check the PID of the offending instance. Go to the command prompt and press enter to generate another services tasklist. See what services are listed for that process ID

If you're lucky there will only be one service listed and you'll know exactly what the culprit is. If you're less lucky there will be a couple services listed, but it's possible you'll be able to figure out which is at fault based on what triggers it. If you're very unlucky it will be like Process 696 listed above and have 30 or more services. If there are several services listed compare the nominal and fault tasklists. Look for new services in the fault list, if there are any, they're possibly involved.
Once you have a list of suspects and are on an Administrator account go to the command prompt and type services.msc, a new window will pop up with a probably rather large list of all the services WinXP can offer. Conveniently, there will be a nice little name and a short description of what each service does. Inconveniently, you won't find the names listed in the services tasklist. Read through the list of services with the status as "Started" and try to match up the suspects from your list.

Once you've identified all your suspects, go down the list. Right click, select Properties, change the Status type: to Disabled (note the original setting), click okay. Right click again, select Stop. Try to provoke SVCHOST again. If it still attacks, turn the service back on and move to the next item on your list. If SVCHOST doesn't misbehave play with your system for a while and make sure it doesn't have any new problems due to the lack of the service.

Known issues: The rest of this node will be devoted to known triggers of SVCHOST attacks and which services are responsible. While you're free to disable the services implicated, it would be best to verify beforehand that it is indeed a suspect for your case. Feel free to /msg me with any info you may have or to add a write-up.

  • Trigger: Immediately after (re)establishing an internet connection SVCHOST attacks. In addition, the internet connection remains unusable until the attack ends or the SVCHOST process is killed.
    Solution:Disabling Dnscache service (Name: DNS Client) stops this attack.
    Cause: When you log on Dnscache verifies that the recorded Domain/IP pairs match. Unfortunately, if you've visited a lot of sites the list can take quite a while to process.
    Effect: Every time you visit a site you will have to check with a DNS server to get the IP address. This does not result in a significant slow down in most systems and can be worked around with the HOSTS file.

Can you guess what I've been doing?