In the Windows NT family of operating systems, svchost.exe (Service Host, or SvcHost) is a system process that hosts multiple Windows services. Svchost is essential in the implementation of so-called shared service processes, where a number of services can share a process in order to reduce resource consumption. Grouping multiple services into a single process 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. However, if one of the services causes an unhandled exception, the entire process may crash. In addition, identifying component services can be more difficult for end users. Problems with various hosted services, particularly with Windows Update, get reported by users (and headlined by the press) as involving svchost.
Its executable image, %SystemRoot%\System32\Svchost.exe or %SystemRoot%\SysWOW64\Svchost.exe (for 32-bit services running on 64-bit systems) runs in multiple instances, each hosting one or more services.
Services running in SvcHost are implemented as dynamically-linked libraries (DLLs). Such service's registry key must have a value named ServiceDll under the Parameters subkey, pointing to the respective service's DLL file. Their ImagePath definition is of the form %SystemRoot%\System32\svchost.exe -k (service group; i.e. netsvcs). Services sharing the same SvcHost process specify the same parameter, having a single entry in the SCM's database. The first time that a SvcHost process is launched with a specific parameter, it looks for a value of the same name under the HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Svchost key, which it interprets as a list of service names. Then, it notifies the SCM of all the services that it hosts. SCM doesn't launch a second SvcHost process for any of those received services: instead, it simply sends a "start" command to the respective SvcHost process containing the name of the service that should be launched within its context, and whose respective DLL SvcHost loads.
Starting with Windows Vista, the internal identification of services inside shared processes (svchost included) is achieved by so-called service tags. The service tag for each thread is stored in the SubProcessTag of its thread environment block (TEB). The tag is propagated across all threads that a main service thread subsequently starts, except for threads created indirectly by Windows thread-pool APIs.
The set of service tag management routines is currently an undocumented API, although it is used by some Windows utilities like netstat to display the TCP connections associated with each service. Some third party tools like ScTagQuery also make use of this API.
Identification and management of hosted services
In Windows XP and later editions, the tasklist command with the /svc switch includes a list of component services in each process.
In Windows Vista and Windows 7, a "Services" tab in Windows Task Manager includes a list of services and their groups and Process IDs (PIDs); right-clicking on a svchost instance in the Task Manager and selecting "Go to Services(s)" also switches to the list of services and additionally selects the services running under the corresponding svchost instance.
In Windows 8, the Task Manager interface was streamlined so that each svchost entry can be expanded by a single click to a sub-list of services running inside it.
None of the above methods allows the user to identify which of the multiple services running inside a svchost instance taxes a particular resource, e.g. processor, disk, network or memory; the Windows Resource Monitor only does accounting for most of those resources at process granularity. It does however account for processor usage at service granularity by going to the "CPU" tab. A service-aware list of TCP connections and UDP ports opened can be obtained using netstat -b.
In order to troubleshoot other kinds of problems with a service running inside a svchost instance, the service (or services suspected to be causing the problem) must be (all) reconfigured so that each runs inside its own svchost instance. For example sc config foo type= own will reconfigure the service named "foo" to run its own svchost instance. Changing the type back to shared is done by an analogous command. The service must be restarted for this kind of configuration change to take effect. This debugging process is not foolproof however; in some cases, a heisenbug may happen, which causes the problem to go away when the service is running separately.
A more complex method of troubleshooting is creating an isolated service group.
Because svchost.exe is used as a common system process, some malware often uses a process name of "svchost.exe" to disguise itself. The original system file svchost.exe is located in C:\Windows\System32 folder. Any file named "svchost.exe" located in any other folder can be considered as malware. Determining the image path of a process, and its invoking command line, can help identify software masquerading in this way, and help locate the actual program file which is running under the assumed process name of "svchost.exe" (Windows allows multiple processes to all display the same name). Some malware inject a .dll file into the authentic svchost process, for example Win32/Conficker worm.
- Russinovich, Solomon & Ionescu (2009:302)
- Shared Services
- David B. Probert, Windows Service Processes
- Russinovich, Solomon & Ionescu (2012:335)
- Microsoft (2009-08-05). "Virus alert about the Win32/Conficker worm". Microsoft.
- Russinovich, Mark; Solomon, David; Ionescu, Alex (2009), Windows® Internals (5th ed.), Microsoft Press, ISBN 0-7356-2530-1
- Russinovich, Mark; Solomon, David; Ionescu, Alex (2012), Windows Internals. Part 1 (6th ed.), Microsoft Press, ISBN 978-0-7356-4873-9
- How to find processes behind svchost.exe
- Memory leak in the svchost process which hosts the Task Scheduler service