Svchost.exe


svchost.exe is a system process that can host from one to many Windows services in the Windows NT family of operating systems. 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 as involving svchost.
The svchost process was introduced in Windows 2000, although the underlying support for shared service processes has existed since Windows NT 3.1.

Implementation

Its executable image, or runs in multiple instances, each hosting one or more services.
Services running in SvcHost are implemented as dynamically-linked libraries. Each service's registry key must have a value named under the subkey, pointing to the respective service's DLL file. Their definition is of the form. 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 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.
According to a 2003 MS presentation, the minimum working set of a shared service is approximately 150 KB instead of 800 KB for a standalone process.

Changes to Service Host grouping in Windows 10

Starting with Windows 10 version 1703, Microsoft changed the way services are grouped into host processes. On client computer systems with more than 3.5 GB of memory, services are no longer grouped into shared host processes. Instead, each service is running in its own process. This results in a better isolation of services, making the computer system more resilient to service failures and vulnerabilities and easier to debug. However, it add some memory overhead.

Service tags

Starting with Windows Vista, the internal identification of services inside shared processes is achieved by so-called service tags. The service tag for each thread is stored in the SubProcessTag of its thread environment block. 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.

Svchost.exe (netsvcs)

Netsvcs is a sub process used by svchost.exe. If and when there is a memory leak the svchost.exe consumes and hogs the CPU. This issue occurs because a handle leak occurs in the Winmgmt service after installing Windows Management Framework 3.0 on the computer. The Winmgmt service is the Windows Management Instrumentation service within the svchost.exe process that is running under the LocalSystem account.

Identification and management of hosted services

In Windows XP and later editions, the command shows a list of the services being run by each listed process, with each separate instance of the svchost process identified by a unique Process ID number.
In Windows Vista and Windows 7, the "Services" tab in Windows Task Manager includes a list of services, showing their groups and Process IDs ; right-clicking on an svchost instance in the Task Manager's "Processes" tab and selecting "Go to Service" switches to that list of services and selects the service 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.
The Sysinternals Process Explorer provides additional information about services running under processes, when the user hovers the mouse over an svchost instance in Process Explorer.
None of the above methods allows the user to identify which of the multiple services running inside an svchost instance accesses a particular resource, i.e. processor, disk, network or memory; the Windows Resource Monitor only accounts for those resources at process level. It does however show processor usage at service level, on the "CPU" tab. A service-aware list of TCP connections and UDP ports opened can be obtained using the command.
In order to troubleshoot other kinds of problems with a service running inside an svchost instance, the service suspected to be causing the problem must be reconfigured so that each runs inside its own svchost instance. For example, will reconfigure the service named "foo" to run in its own svchost instance. Changing the back to is done by an analogous command. The service must be restarted for such a configuration change to take effect. This debugging process is not foolproof however; in some cases, a heisenbug may occur, which causes the problem to go away when the service is running separately.
A more complex method of troubleshooting is to create an isolated service group.
In Windows 10, starting with release 1703, svchost was redesigned by Microsoft to host only one service per process, depending on available system memory. The default setting causes services to be hosted independently if the system has at least 3.5GB of RAM.