The svchost.exe program is often blamed for situations that are not svchost.exe's fault. svchost.exe gets blamed by software, including other components of Microsoft Windows, and also by people who are inclined to trust that software. This gets mentioned a bit by CPU Usage: section summarizing svchost.exe, and more details are included lower on this page.

The svchost.exe program combines multiple services into a single process. On the plus side, this reduces overhead. Many services will frequently run without any problems. When things are working well, the benefits from reduced overhead make the whole process seem desirable.

There may be two fairly common causes why people start to become concerned with the svchost.exe program. One is if Task Manager is stating that svchost.exe is using a lot of CPU processing power. Another common case is if the svchost.exe program seems to be unstable, crashing.

In either of these cases, some people may be inclined to try to handle the program which seems to be misbehaving. For example, they might have a desire to try to just stop the svchost.exe program, and re-run it. They may find there is advice that recommends that people don't try to do such a method. This advice can get to be quite frustrating when attempts to quickly resolve the issue seem to fail, and when there seems to be no guide on how to resolve such a situation.

Warning

First, a big warning: killing (forcably closing a running copy/instance of) the svchost.exe may resuilt in stopping some critical software, such as a video device driver. Results may include causing additional system instability. Trying to simply end a running copy of svchost.exe is probably never recommended, especially if dealing with a system where uptime is highly preferable, or when using remote access that could easily be broken if additional problems get caused.

Additionally, simply re-running the svchost.exe executable won't likely restore the process. AndreaGeddon's “XP SVCHOST Reversed - Services? Processes? How many is too many!” (PDF file) states, “the command line parameters are fundamental to the functionality of the process, if we run svchost.exe without parameters the process will exit.”

The simple recommendation

The svchost.exe is basically a wrapper that combines multiple services into a single process. Therefore, a person should generally figure out which services are part of that process before doing something like ending the process. That's just a matter of identifying what will be impacted before making changes.

Quick summary: What is going on

svchost.exe is basically a service that combines other programs into a single process. On the plus side, this reduces overhead. When things work well, this is generally not a problem.

A service is a program, just like a “device driver” is a program. Like a device driver, services tend to be automated programs that people don't directly interact with very much. They typically don't have a user interface. Currently running software provides some discussion about interacting with a program.

On the downside, this really can complicate troubleshooting a bit. If any of the combined processes has a substantial issue, that issue can affect multiple pieces of software, including innocent pieces of software. If one of the components of the process causes the entire process to crash, then that affects all of the components that are sharing the same process. If one of the components of thie process is causing the process to use up a bunch of resources, then the svchost.exe process will look like it is at fault. The svchost.exe program may very well be guilty of complicating troubleshooting by reducing clarity. Instead of knowing which service is causing a problem, the only thing that is readily apparent is that the svchost.exe command was involved with the problem. This is unfortunate.

The best way to properly fix the problem of svchost.exe doing something bad is generally to figure out what software is causing the original problem, and then fix the original problem. In theory, a mirror can cause problems by being dirty or broken, but usually if a mirror displays something unpleasant than the solution is not to try to adjust the reflection. Instead, fix the original problem.

As a quick hint, based on actual experience on professional networks: high CPU usage has often been caused by disk activity. If CPU usage is high, check if the disk is being used.

If that quick hint doesn't solve the problem, then one solution may be to try to figure out which service is behind the problem that svchost.exe is getting blamed for. Then troubleshooting can be focused on that component, which will probably be better for troubleshooting. Also, for people who do have experience and understanding with svchost.exe, seeing a report about a particular service being problematic will probably sound better than seeing a report that blames a svchost.exe process. A report that svchost.exe is causing problems makes the author of the report sound a bit uninformed about what svchost.exe is and how svchost.exe operates. Such a report makes the author sound like the author did not really manage to successfully scratch any deeper than the surface of the problem.

This guide does provide some details about how to identify which service is causing the problem. One option will be to separate that service from anything other service that is part of the same svchost.exe process. Unfortunately, this procedure may be a bit time consuming, but it is possible. It is a logical approach that can result in someone being a bit closer to understanding what the original problem is.

Quick summary: what to do

In Microsoft Windows, if svchost.exe seems to be unstable (crashing), or if this software is utilizing a high amount of CPU resources, know right away that svchost.exe is probably not originating the problem. Instead, the problem is being reported as if svchost.exe is the culprit. The best/correct solution to such a problem is to find out what is really causing the start of whatever issues are happening.

Understanding the common misblaming of svchost.exe

This is a bit of a lengthy (and perhaps redundant/circular) commentary about why svchost.exe is not actually the core cause, despite the fact that many people may be given some good reason to feel like svchost.exe is the cause of all of their current troubles.

The svchost.exe program comes with Microsoft Windows, and does not generally cause problems that are a direct result of svchost.exe originating the problem. Instead, the svchost.exe is used in combination with some other software. The other software is typically what is causing misbehavior on the system, and the best solution is typically to fix that other software.

This isn't to say that svchost.exe isn't involved with a problem. Indeed, if the computer says that svchost.exe is using up lots of CPU resources, then that is what is actually happening. However, like a mirror that shows an ugly image, the core cause of the unpleasantness is not the tool. The fact that problems exist do not tend to start with the code built into svchost.exe. So the best, right, and proper fix will be to identify what is actually causing the problem.

The primary reason for believing that svchost.exe is probably innocent is just experience, and knowing that svchost.exe is frequently an innocent victim of misblaming. The svchost.exe is going to be treated like a tool, which can be used for good purposes or bad purposes. Simply put, successful resolution of problems does not typically involve blaming svchost.exe as being the core/root cause/issue that initiated the existance of a problem. Experience shows that if svchost.exe is acting up, then there is also another cause. Addressing that other cause will typically cause svchost.exe to settle down.

So, this guide is based on the assumption that identifying and handling an issue with some other cause will change the behavior of svchost.exe, so that svchost.exe no longer seems to be misbehaving. Some other software is likely to be the culprit. This software might be a device driver; that is typically what occurs if a hardware issue is what is really causing the problem. Still, finding out what device driver is causing the issue may provide some useful clues, and be much more helpful that reports that svchost.exe is out of control.

Admittedly, sometimes it does seem like it might be nice if svchost.exe didn't cooperate with bad requests. The svchost.exe program might be nicer if it would not allow itself to get into the position of being so easily blamed for problems that are initiated by other causes. Perhaps it might be nice if svchost.exe defended its reputation, by refused to be involved in such bad things. This might cause other software to have problems, but if the other software has unrealistic expectations of svchost.exe, then it would be nice for that other software to be what experiences problems. Then that software would probably be prone to reporting problems, and that software would be getting blamed instead of svchost.exe looking like the troublemaker. That could simplify troubleshootiong.

Despite how nice this might or might not be, that possibly pleasant fiction just doesn't match the known-to-be-true reality of how svchost.exe actually behaves, at least with certain versions of Microsoft Windows where this problem has been noticed. In this less fictional world, if svchost.exe is using up lots of CPU, then svchost.exe does not tend to leave behind logs or other sorts of easy error messages that would help with such finger-pointing.

Quite a bit of experience, with successfully resolving problems, leads to the conclusion that svchost.exe typically behaves well when there isn't a cause for it to behave poorly. By identifying that reason that svchost.exe is behaving poorly, an actual fix to a real issue is more likely to be resolved.

No matter how much hatred a person may feel for svchost.exe while it is misbehaving, realize that its biggest crime may be that it helps to hide the actual culprits. Once the actual culprits stop committing improper actions, then svchost.exe is likely to also behave, just like a tool that stops being used for bad things as soon as a person drops (or, in some other way, stops using) that tool.

Sometimes a person may wonder why is this svchost.exe software even being used? Well, according to Larry Osterman's “Shared Services” blog posting, “unlike *nix, on Windows, a process is a relatively expensive entity. It takes a non trivial amount of time to launch a process, and each process consumes a fair amount of system resources [...] Each process running drains the system of resources that could be used for your application, so it's important to reduce the number of system processes running.” Wikipedia's article on svchost.exe indicates that using svchost.exe “conserves computing resources, and this consideration was of particular concern to NT designers because creating Windows processes takes more time and consumes more memory than in other operating systems, e.g. in the Unix family.” So a lot of this is related to some of the design of Microsoft Windows.

Expectations for this guide

This guide is designed to help identify what software is causing svchost.exe to misbehave. (If the problem is actually caused by hardware, this guide will act like the problem is caused by the driver that reports the status of the hardware.) So this guide might not trace the problem all the way back to the initial cause, but it will serve to get the problem traced at least one step back, so that the cause will look like some software other than svchost.exe. Knowing what other software gets blamed by this process may be a pointer that helps to identify the actual issue, at least with more accuracy than blaming svchost.exe

This guide doesn't actually provide a lot of details about why that guilty software is doing the bad thing, but that can be resolved by focusing trouleshooting efforts on that other software.

If the problem is that svchost.exe seems to have crashed, then check the event log to see if svchost.exe nicely placed the blame on another executable file. That may be a quicker process than what the rest of this guide suggests.

This guide may be more useful at handling cases of high CPU usage, namely because then a PID is regularly obtainable. Some of this might also be helpful if dealing with apparent instability of the svchost.exe program.

Alternatives: why and how

Often, checking some other things will be very useful. fully isolating an svchost.exe process will be fairly time-consuming, including requiring a system reboot, which may cause undesirable downtime, and the amount of knowledge gained is often minimal.

First, this quick note: Experience seems to suggest that problems with high CPU usage from svchost.exe is related to programs that start handling a fairly large amount of data from a disk. Checking for disk activity might be another approach that provides some useful results. (If it is verified that the disk is being actively used, then checking which files are in use may be a solution.) This text is not providing a clear reason for this, beyond stating that this is written based on some amount of experience.

Also, checking other key status indicators of a system, like the amount of available (“free”) memory, may also point to a cause of some problems. Especially if svchost.exe is crashing, it may be worthwhile to check whether all of the normally Started services are in a state of being Started.

Determining which service

First, a quick mention to the relatively fast and efficient way that will be useful if someone wants to try to identify which service is using up a bunch of CPU time. Unfortunately for users of Windows XP and Server 2003, this may require using a newer version of Microsoft Windows. (This worked in Win7; probably in Vista?). The method is to go to the Resource Monitor's “CPU” tab. If a person can get to that tab while the CPU usage is still high (and sort by CPU usage), then the service will be identified (as “svchost.exe (serviceName)”).

One basic troubleshooting step may be to find out just what pieces of software possibly use svchost.exe. That probably won't help much, because we can't quickly narrow things down further than that, but if anyone wishes to see that list, here is a way to do so:

REG QUERY "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Svchost" /t REG_MULTI_SZ

If the version of Microsoft Windows being used does not have the REG command, check out the registry key that was shown. (Microsoft Windows Registry.) But since svchost.exe was introduced in Win2K (per Wikipedia article on svchost.exe, which was citing YongRhee's TechNet blog entry: “How to troubleshoot Service Host (svchost.exe) related problems?”, the Win2K family of operating systems is probably the only type of system that will have svchost.exe but won't have Reg.exe built-in. And that operating system will have Reg.exe available on the operating system's installation CD-ROM.

A quick blurb to share some credit where it is due: Some of this next step is based on using some of the information shared by both ][CyberPillar][: matching PID with services and also TechNet Blog: EPS Windows Server Performance Team blog: Getting Started with SVCHOST.EXE Troubleshooting. That Microsoft TechNet article shows an example output of TaskMgr command.

Alright, onward with moving towards the solution. Try running:

tasklist.exe /SVC /FI "IMAGENAME eq svchost.exe"

Here is some actual example output:

Image Name                     PID Services ========================= ======== ============================================ svchost.exe                    692 DcomLaunch, PlugPlay, Power svchost.exe                    812 RpcEptMapper, RpcSs svchost.exe                    108 AudioSrv, Dhcp, eventlog,                                    HomeGroupProvider, lmhosts, wscsvc svchost.exe                    320 AudioEndpointBuilder, hidserv, Netman,                                    PcaSvc, SysMain, TrkWks, UxSms, Wlansvc,                                    WPDBusEnum, wudfsvc svchost.exe                    460 EventSystem, fdPHost, FontCache, netprofm,                                    nsi, WdiServiceHost svchost.exe                    336 AeLookupSvc, Appinfo, BITS, Browser,                                    EapHost, gpsvc, IKEEXT, iphlpsvc,                                    LanmanServer, MMCSS, ProfSvc, Schedule,                                    SENS, ShellHWDetection, Themes, Winmgmt,                                    wuauserv svchost.exe                   1332 CryptSvc, Dnscache, LanmanWorkstation,                                    NlaSvc svchost.exe                   1644 BFE, DPS, MpsSvc svchost.exe                   1748 FDResPub, SSDPSRV, upnphost, wcncsvc svchost.exe                   1764 stisvc svchost.exe                   2992 PolicyAgent svchost.exe                   4260 p2pimsvc, p2psvc, PNRPsvc

First, consider a simple example: If the problem is caused by PID 1764, we can clearly see the related service is stisvc. Similarly, if the problem seems to be related to PID 2992, we can simply and clearly see that the related service is PolicyAgent. In those cases, we would now have another direction to be suspicious of.

For more information on any of these names of services, check out: Getting the service names. (Many of the services that are used with svchost.exe are also mentioned in a table near the end of YongRhee's TechNet blog entry: “How to troubleshoot Service Host (svchost.exe) related problems?”.)

Now, let's use an example of if a problem was actually being used by Windows Update: Automatic Update Services. That is shown on the last line of things related to PID 336. If we knew there was a problem with PID 336, which means things are only narrowed down to 17 possible pieces of software (based on the example ouitput shown above). That is still quite a bit to need to look through, but at least it is narrowed down a bit from the list of software that interacts with svchost.exe.

YongRhee's TechNet blog entry: “How to troubleshoot Service Host (svchost.exe) related problems?” points out another method: In Windows Task Manager, on the Processes tab, access the context menu of an svchost.exe instance (by right-clicking on the process), and choose “Go to Service(s)”. The different svchost.exe instances can be kept track of by using their PID, although the PID column may not be visible by default (so, change the visibility of the PID column). Task Manager will switch to the Services tab, and the services related to that svchost.exe instance will be highlighted. Nicely, that method also shows the PIDs of the related services.

To narrow things down further, it may be helpful to split things up a bit. Note that this process may not be reversable except for performing a system reboot. Also note that this guide was written based on info found elsewhere, and not based on heavy experience performing this task.

Get the name of a service to use

Pick a service

In this documentation, the Windows Update: Automatic Update service will be used as an example. (Hmm, this is unfortunately the same example that was chosen by TechNet Blog: EPS Windows Server Performance Team blog: Getting Started with SVCHOST.EXE Troubleshooting. The reason for this is probably because Windows Update: Automatic Update service has been known to lead to heavy disk usage and subsequent CPU spiking.)

There's no real magic way to know exactly which service to pick. Just choose one. Preferably, pick that that seems like it may be more probable to be causing issues.

getting the service name

Then, you'll need the short/abbreviated name of the service. See: Getting the service names.

Checking the current configuration

First, check the current config:

SC QUERY wuauserv

(This isn't part of the steps from Microsoft's guide, but checking old values before changing them to new values is generally recommended.)

e.g. results:

SERVICE_NAME: wuauserv         TYPE               : 20  WIN32_SHARE_PROCESS

You can also run:

REG QUERY "HKLM\SYSTEM\CurrentControlSet\Services\wuauserv\Type" /v Type /t REG_DWORD

This is also presumed to show a value of 0x20, which corresponds to WIN32_SHARE_PROCESS.

Note that if a value other than 0x20 is shown, that may mean that the service is operating in a way different than what this guide is designed to address. This advice might or might not have any useful or undesirable impacts.

Perhaps assuming that is 0x20   WIN32_SHARE_PROCESS, this method is likely to work okay.

Making the change

Know that undoing this will (or might? maybe only for the first approach?) require a reboot to reverse the change.

There might be other ways to do this; the ways described here are rather heavily using command line tools. If there are some nice GUI options to change, those might not currently be covered by this guide.

There are two ways to isolate a service so that it gets its own copy of svchost.exe. the service. These are based on TechNet Blog: EPS Windows Server Performance Team blog: Getting Started with SVCHOST.EXE Troubleshooting. That guide really didn't recommend one way over the other, but just provided both ways. The first method in that guide (which is also the first way in this guide), creating an isolated service, might be a bit simpler of a change? Based on that extremely unsubstantiated theory, that is mentioned first.

Changing the service

One method is to just change the service. Use:

sc config wuauserv type= own

Note: the space after “type=” is intentional and required. Altneratively, modifying the registry is believed to accomplish the same thing:

REG ADD "HKLM\SYSTEM\CurrentControlSet\Services\wuauserv\Type" /v Type /t REG_DWORD /d 0x10

Then, restarting the service is required:

sc stop wuauserv type= own sc start wuauserv type= own

Now, presumably the service is using its own PID. This should be verifiable by using “ Tasklist.exe/SVC ”.

If the problems still occur with the same service, the problems will occur with a PID that is now specific to this service. At that point, there should be more clarity that this is indeed the service that is causing problems. If, on the other hand, the problems still occur with a PID related to a different copy of svchost.exe, then the problem seems to be coming from a service related to the copy of svchost.exe used with that PID. In that case, figure out what services are used with that PID, and repeat this process.

Reversing the change

To undo this:

sc config wuauserv type= share

... and reboot!

shutdown /r /f /t 1 /c "Moving wuauserv back to shared instance" -d u:2:4

(The part in quotation marks is just a comment that gets logged, and so getting typing this with typoless precision is not strictly technically necessary to achieve the desired functionality of simply rebooting.)

Alternative approach

TechNet Blog: EPS Windows Server Performance Team blog: Getting Started with SVCHOST.EXE Troubleshooting also describes another method: rather than create an isolated process (instead of a shared process), this method is to create an isolated “service group”. Directions are provided by that guide (Method #2). Presumably the text “WindowsUpdates” (shown in steps #1 and #4) is example text that was selected to be appropriate to go along with the example of wuauserv.

First, before making any potential changes, see the current state of the system:

REG QUERY "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Svchost" /v WindowsUpdates

It might not pre-exist, and that's fine. Make a note about whether it existed (and, if so, what its current value is), just so you know how to reverse changes if desired. If that doesn't exist, then make it. Include the appropriate abbreviated name of the service, such as the following for Microsoft Update: Windows Update service.

REG ADD "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Svchost" /v WindowsUpdates /t REG_MULTI_SZ /d wuauserv

See the value of the following registry key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Svchost\Netsvcs

REG QUERY "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Svchost" /v Netsvcs

e.g.:

Netsvcs   ®_MULTI_SZ    AeLookupSvc\0CertPropSvc\0SCPolicySvc\0lanmanserv er\0gpsvc\0IKEEXT\0AudioSrv\0FastUserSwitchingCompatibility\0Ias\0Irmon\0Nla\0Nt mssvc\0NWCWorkstation\0Nwsapagent\0Rasauto\0Rasman\0Remoteaccess\0SENS\0Sharedac cess\0SRService\0Tapisrv\0Wmi\0WmdmPmSp\0TermService\0wuauserv\0BITS\0ShellHWDet ection\0LogonHours\0PCAudit\0helpsvc\0uploadmgr\0iphlpsvc\0seclogon\0AppInfo\0ms iscsi\0MMCSS\0winmgmt\0SessionEnv\0browser\0EapHost\0schedule\0hkmsvc\0wercplsup port\0ProfSvc\0Themes\0BDESVC

Those services are separated by \0

TechNet Blog: EPS Windows Server Performance Team blog: Getting Started with SVCHOST.EXE Troubleshooting step two (second half) says to remove the desired service from that key. (This might be something that people easier to do by using the GUI tool named RegEdit? Otherwise, a solution may involve using Reg.exe or using a *.reg file, as noted by MS KB 310516 and the Microsoft Windows Registry section. This guide doesn't have any recommendations of using one method of another.)

TechNet Blog: EPS Windows Server Performance Team blog: Getting Started with SVCHOST.EXE Troubleshooting step 3 has technicians working with another Registry key. Let's first see what it is currently set to:

REG QUERY "HKLM\SYSTEM\CurrentControlSet\Services\wuauserv" /v ImagePath

Note that the wuauserv in that registry key is related to which service is being modified.

It will probably have the following value:

ImagePath    REG_EXPAND_SZ    %systemroot%\system32\svchost.exe -k netsvcs

(Note: unlike many of the documentation examples that may reference %systemroot%, this is actually literal, unexpanded.)

Verify if that is the current value. Especially make note of any other value. This way, reversing the change can be done easily (based on the documentation that you make).

Then, set the new desired value. Simply replace the value after the /k to something customized. For instance, TechNet Blog: EPS Windows Server Performance Team blog: Getting Started with SVCHOST.EXE Troubleshooting used a value of “WindowsUpdate” when the service was wuauserv.

Note: It may be a challenge to put %systemroot% on a command line, unexpanded. (It is easier to do with JP Software's prompts.) Fortunately, that probably really doesn't matter: expanding it is not expected to cause a problem (even though that won't be precisely following TechNet Blog: EPS Windows Server Performance Team blog: Getting Started with SVCHOST.EXE Troubleshooting).

e.g. (allowing the %systemroot% variable to be exapnded):

REG ADD "HKLM\SYSTEM\CurrentControlSet\Services\wuauserv" /v ImagePath /t REG_EXPAND_SZ /d "%systemroot%\system32\svchost.exe -k WindowsUpdates" /f

TechNet Blog: EPS Windows Server Performance Team blog: Getting Started with SVCHOST.EXE Troubleshooting step 4 says to restart the desired service. So, once again, knowing the name of the service will be helpful. (Currently running software has information about restarting/stopping/starting a service.)

Now that the critical steps from TechNet Blog: EPS Windows Server Performance Team blog: Getting Started with SVCHOST.EXE Troubleshooting have been documented, there's one more tidbit from that page to mention, and which will be directly quoted here: “An additional refinement to this method would be to create copies of SVCHOST.EXE that are appropriately named for the isolated service - for example copy %systemroot%\system32\svchost.exe to a new file named %systemroot%>\system32\svchost_wuauserv.exe.  Remember that you will need to make the appropriate modifications to the ImagePath value in the registry that reflect the name of the executable file.” This might have no effect, but also could be useful when trying to use debugging software and wanting to isolate the executable file.

Additional resources

In addition to TechNet Blog: EPS Windows Server Performance Team blog: Getting Started with SVCHOST.EXE Troubleshooting, there is also YongRhee's TechNet blog entry: “How to troubleshoot Service Host (svchost.exe) related problems?”. Both of these were already mentioned earlier in the article, but the guides are both on TechNet, so this note is simply trying to point out that there are two separate guides on technet.