Svchost.exe

Last updated

Svchost.exe (Service Host, or SvcHost) is a system process that can host one or more Windows services in the Windows NT family of operating systems. [1] Svchost is essential in the implementation of 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. [2] 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, [3] [4] get reported by users (and headlined by the press) as involving svchost.

Contents

The svchost process was introduced in Windows 2000, [5] although the underlying support for shared service processes has existed since Windows NT 3.1. [2]

Implementation

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). Each 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 does not 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 Microsoft presentation, the minimum working set of a shared service is approximately 150 KB instead of 800 KB for a standalone process. [6]

Changes to Service Host grouping in Windows 10

Starting with Windows 10 version 1903, 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 run in its own process. This results in better isolation of services, making the computer system more resilient to service failures and vulnerabilities and easier to debug. However, it adds some memory overhead. [7]

Service tags

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. [8]

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. [8]

Identification and management of hosted services

In Windows XP and later editions, the command tasklist /svc shows a list of the services being run by each listed process (i.e. by each running instance of svchost.exe), with each separate instance of the svchost process identified by a unique Process ID number (PID).

In Windows Vista and Windows 7, the "Services" tab in Windows Task Manager includes a list of services, showing their groups and Process IDs (PIDs); right-clicking on an svchost instance in the Task Manager's "Processes" tab and selecting "Go to Service(s)" 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 (available as a free download from Microsoft) provides additional information about services running under svchost.exe 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 (most of) those resources at process level. It does however show processor usage at service level, on the "CPU" tab. [9] A service-aware list of TCP connections and UDP ports opened can be obtained using the command netstat -b. [10]

In order to troubleshoot other kinds of problems with a service running inside an svchost instance, the service(s) suspected to be causing the problem must (all) be 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 in its own svchost instance. Changing the type back to shared 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. [11]

A more complex method of troubleshooting is to create an isolated service group. [12]

In Windows 10, starting with release 1703, svchost was redesigned by Microsoft to host only one service per process, depending on available system memory. [13] The default setting causes services to be hosted independently if the system has at least 3.5 GB of RAM.

See also

Related Research Articles

<span class="mw-page-title-main">Windows API</span> Microsofts core set of application programming interfaces on Windows

The Windows API, informally WinAPI, is the foundational application programming interface (API) that allows a computer program to access the features of the Microsoft Windows operating system in which the program is running.

<span class="mw-page-title-main">Windows Console</span> Infrastructure for console applications in Microsoft Windows

Windows Console is the infrastructure for console applications in Microsoft Windows. An instance of a Windows Console has a screen buffer and an input buffer. It allows console apps to run inside a window or in hardware text mode. The user can switch between the two using the Alt+↵ Enter key combination. The text mode is unavailable in Windows Vista and later. Starting with Windows 10, however, a native full-screen mode is available.

netstat Command line network statistics tool

In computing, netstat is a command-line network utility that displays network connections for Transmission Control Protocol, routing tables, and a number of network interface and network protocol statistics. It is available on Unix, Plan 9, Inferno, and Unix-like operating systems including macOS, Linux, Solaris and BSD. It is also available on IBM OS/2 and on Microsoft Windows NT-based operating systems including Windows XP, Windows Vista, Windows 7, Windows 8 and Windows 10.

<span class="mw-page-title-main">Windows Registry</span> Database for Microsoft Windows

The Windows Registry is a hierarchical database that stores low-level settings for the Microsoft Windows operating system and for applications that opt to use the registry. The kernel, device drivers, services, Security Accounts Manager, and user interfaces can all use the registry. The registry also allows access to counters for profiling system performance.

<span class="mw-page-title-main">System Idle Process</span> Kernel process in Windows NT operating systems

In Windows NT operating systems, the System Idle Process contains one or more kernel threads which run when no other runnable thread can be scheduled on a CPU. In a multiprocessor system, there is one idle thread associated with each CPU core. For a system with hyperthreading enabled, there is an idle thread for each logical processor.

<span class="mw-page-title-main">Architecture of Windows NT</span> Overview of the architecture of the Microsoft Windows NT line of operating systems

The architecture of Windows NT, a line of operating systems produced and sold by Microsoft, is a layered design that consists of two main components, user mode and kernel mode. It is a preemptive, reentrant multitasking operating system, which has been designed to work with uniprocessor and symmetrical multiprocessor (SMP)-based computers. To process input/output (I/O) requests, it uses packet-driven I/O, which utilizes I/O request packets (IRPs) and asynchronous I/O. Starting with Windows XP, Microsoft began making 64-bit versions of Windows available; before this, there were only 32-bit versions of these operating systems.

<span class="mw-page-title-main">Winlogon</span> Component of Microsoft Windows operating systems

Winlogon is the component of Microsoft Windows operating systems that is responsible for handling the secure attention sequence, loading the user profile on logon, creates the desktops for the window station, and optionally locking the computer when a screensaver is running. In Windows Vista and later operating systems, the roles and responsibilities of Winlogon have changed significantly.

The Local Inter-Process Communication is an internal, undocumented inter-process communication facility provided by the Microsoft Windows NT kernel for lightweight IPC between processes on the same computer. As of Windows Vista, LPC has been rewritten as Asynchronous Local Inter-Process Communication in order to provide a high-speed scalable communication mechanism required to efficiently implement User-Mode Driver Framework (UMDF), whose user-mode parts require an efficient communication channel with UMDF's components in the executive.

The booting process of Windows NT is the process run to start Windows NT. The process has been changed between releases, with the biggest changes being made with Windows Vista. In versions before Vista, the booting process begins when the BIOS loads the Windows NT bootloader, NTLDR. Starting with Vista, the booting process begins with either the BIOS or UEFI load the Windows Boot Manager, which replaces NTLDR as the bootloader. Next, the bootloader starts the kernel, which starts the session manager, which begins the login process. Once the user is logged in, File Explorer, the graphical user interface used by Windows NT, is started.

The Native API is a lightweight application programming interface (API) used by Windows NT and user mode applications. This API is used in the early stages of Windows NT startup process, when other components and APIs are still unavailable. Therefore, a few Windows components, such as the Client/Server Runtime Subsystem (CSRSS), are implemented using the Native API. The Native API is also used by subroutines such as those in kernel32.dll that implement the Windows API, the API based on which most of the Windows components are created.

ntoskrnl.exe, also known as the kernel image, contains the kernel and executive layers of the Microsoft Windows NT kernel, and is responsible for hardware abstraction, process handling, and memory management. In addition to the kernel and executive mentioned earlier, it contains the cache manager, security reference monitor, memory manager, scheduler (Dispatcher), and blue screen of death.

The Session Manager Subsystem, or smss.exe, is a component of the Microsoft Windows NT family of operating systems, starting in Windows NT 3.1. It is executed during the startup process of those operating systems.

The Microsoft Windows operating system supports a form of shared libraries known as "dynamic-link libraries", which are code libraries that can be used by multiple processes while only one copy is loaded into memory. This article provides an overview of the core libraries that are included with every modern Windows installation, on top of which most Windows applications are built.

<span class="mw-page-title-main">Windows Boot Manager</span> Boot process used in modern Windows NT-based products

The Windows Boot Manager (BOOTMGR) is the bootloader provided by Microsoft for Windows NT versions starting with Windows Vista. It is the first program launched by the BIOS or UEFI of the computer and is responsible for loading the rest of Windows. It replaced the NTLDR present in older versions of Windows.

The Client/Server Runtime Subsystem, or csrss.exe, is a component of the Windows NT family of operating systems that provides the user mode side of the Win32 subsystem. In modern versions of Windows, it is primarily involved with process and thread management, console window handling, side-by-side assembly loading and the shutdown process. Historically, it had also been responsible for window management and graphics rendering, however, these operations have been moved to kernel mode starting with Windows NT 4.0 to improve performance.

<span class="mw-page-title-main">Process Explorer</span> Freeware system monitor for Windows

Process Explorer is a freeware task manager and system monitor for Microsoft Windows created by SysInternals, which has been acquired by Microsoft and re-branded as Windows Sysinternals. It provides the functionality of Windows Task Manager along with a rich set of features for collecting information about processes running on the user's system. It can be used as the first step in debugging software or system problems.

<span class="mw-page-title-main">Microsoft POSIX subsystem</span> Subsystem shipped with the first versions of Windows NT

Microsoft POSIX subsystem is one of four subsystems shipped with the first versions of Windows NT, the other three being the Win32 subsystem which provided the primary API for Windows NT, plus the OS/2 and security subsystems.

In computing on Microsoft platforms, WoW64 is a subsystem of the Windows operating system capable of running 32-bit applications on 64-bit Windows. It is included in all 64-bit versions of Windows, except in Windows Server Server Core where it is an optional component, and Windows Nano Server where it is not included. WoW64 aims to take care of many of the differences between 32-bit Windows and 64-bit Windows, particularly involving structural changes to Windows itself.

Service Control Manager (SCM) is a special system process under the Windows NT family of operating systems, which starts, stops and interacts with Windows service processes. It is located in the %SystemRoot%\System32\services.exe executable. Service processes interact with SCM through a well-defined API, and the same API is used internally by the interactive Windows service management tools such as the MMC snap-in Services.msc and the command-line Service Control utility sc.exe. Terminating this file is used as a method of causing the Blue Screen of Death.

References

  1. Russinovich, Solomon & Ionescu (2009 :302)
  2. 1 2 "Shared Services" . Retrieved 1 October 2014.[ dead link ]
  3. Woody Leonhard (16 December 2013). "Microsoft promises to fix Windows XP SVCHOST redlining 'as soon as possible'". InfoWorld. Retrieved 1 October 2014.
  4. "Svchost.exe gets worse before it's fixed - Series - Windows Secrets" . Retrieved 1 October 2014.
  5. "How to troubleshoot Service Host (svchost.exe) related problems?" . Retrieved 1 October 2014.
  6. David B. Probert, "Windows Service Processes"
  7. "Changes to Service Host grouping in Windows 10". Microsoft. 2021-08-27. Retrieved 2021-01-10.
  8. 1 2 Russinovich, Solomon & Ionescu (2012 :335)
  9. "Figuring out why my SVCHOST.EXE is at 100% CPU without complicated tools in Windows 7 - Scott Hanselman" . Retrieved 1 October 2014.
  10. Whether this is useful is doubtful, it typically shows only the name of the service for the running web browser (e.g. it lists various items of information related to the internet connection and ports in use, but logs them all as simply "firefox.exe")
  11. "What is svchost.exe, and why do I have so many instances of it?" . Retrieved 1 October 2014.
  12. "Getting Started with SVCHOST.EXE Troubleshooting" . Retrieved 1 October 2014.
  13. "Changes to Service Host grouping in Windows 10". Microsoft. Retrieved 30 April 2018.

Further reading