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. [1] 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
.
The SCM executable, Services.exe
, runs as a Windows console program and is launched by the Wininit process early during the system startup. [2] Its main function, SvcCtrlMain()
, launches all the services configured for automatic startup. First an internal database of installed services is initialized by reading the following two registry keys:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\ServiceGroupOrder\List
, containing the names and order of service groups. Each service's registry key contains an optional Group
value which governs the order of initialization of a respective service or a device driver, with respect to other service groups.HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services
, which contains the actual database of services and device drivers and is read into SCM's internal database. [3] SCM reads every service's Group
value as well as load-order dependencies from their DependOnGroup
and DependOnService
registry keys. [4] In the next step, SCM's main function SvcCtrlMain()
calls the function ScGetBootAndSystemDriverState()
function which checks whether the device drivers that should be started during the boot or system startup were successfully loaded, and those that have failed to do so are stored in a list called ScFailedDrivers
. Then a named pipe \Pipe\Ntsvcs
is created as a remote procedure call interface between the SCM and the SCPs (Service Control Processes) that interact with specific services.
Next, it calls the ScAutoStartServices()
function which loops through all the services marked as auto-start, paying attention to the calculated load-order dependencies. In case of a circular dependency an error is noted and the service depending on a service that belongs to a group coming later in the load order is skipped. For delayed auto-start services, grouping has no effect, and those are loaded at a later stage of system startup. [5]
For each service it wants to start, the SCM calls the ScStartService()
function which checks the name of the file that runs the service's process, ensuring that the account specified for the service is same as the account that the service process runs in. Every service that does not run in the System
account is logged in by calling the LSASS function LogonUserEx()
, for which LSASS process looks up "secret" passwords stored in the HKLM\SECURITY\Policy\Secrets\
registry key, which were stored by the SCP using the LsaStorePrivateData()
API, when the service was originally configured. [6]
Next, the ScLogonAndStartImage()
function is called for every service whose service process has not been already launched. Service processes are created in a suspended state via the CreateProcessAsUser()
API. Before the service process' execution is resumed, a named pipe \Pipe\Net\NtControlPipeX
(where X is a number incremented for each service iteration) is created which serves as a communication channel between the SCM and the service process. Service process connects to the pipe by calling the StartServiceCtrlDispatcher()
function, after which the SCM sends the service a "start" command. [7]
Delayed auto-start services have been added in Windows Vista, in order to solve the problem of a prolonged system startup, as well as to speed-up the start of critical services that cannot be delayed. [8] Originally the auto-start method of service initialization was designed for essential system services upon which other applications and services depend. The SCM initializes the delayed services only after handling all the non-delayed auto-start services, by invoking the ScInitDelayStart()
function. This function queues a delayed (120 seconds by default) work item associated with a corresponding worker thread. Other than being initialized after a delay, there are no other differences between delayed and non-delayed services.
Services whose Type
registry value is SERVICE_KERNEL_DRIVER
or SERVICE_FILE_SYSTEM_DRIVER
are handled specially: these represent device drivers for which ScStartService()
calls the ScLoadDeviceDriver()
function which loads the appropriate driver (usually a file with an extension .sys
) which must be located in the %SystemRoot%\System32\Drivers\
directory. For that purpose, the NtLoadDriver
system call is invoked, and the SeLoadDriverPrivilege
is added to the SCM's process.
SCM provides an additional functionality completely unrelated to Windows services: it notifies GUI applications such as the Windows Explorer when a network drive-letter connection has been created or deleted, by broadcasting Windows messages WM_DEVICECHANGE
.
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. Programs access API functionality via dynamic-link library (DLL) technology.
NTLDR is the boot loader for all releases of Windows NT operating system from 1993 with the release of Windows NT 3.1 up until Windows XP and Windows Server 2003. From Windows Vista onwards it was replaced by the BOOTMGR bootloader. NTLDR is typically run from the primary storage device, but it can also run from portable storage devices such as a CD-ROM, USB flash drive, or floppy disk. NTLDR can also load a non NT-based operating system given the appropriate boot sector in a file.
AUTOEXEC.BAT
is a system file that was originally on DOS-type operating systems. It is a plain-text batch file in the root directory of the boot device. The name of the file is an abbreviation of "automatic execution", which describes its function in automatically executing commands on system startup; the filename was coined in response to the 8.3 filename limitations of the FAT file system family.
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.
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.
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. The roles and responsibilities of Winlogon have changed significantly in Windows Vista and later operating systems.
A dynamic-link library (DLL) is a shared library in the Microsoft Windows or OS/2 operating system.
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.
Svchost.exe is a system process that can host one or more Windows services in the Windows NT family of operating systems. 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. 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.
In computing, SUBST
is a command on the DOS, IBM OS/2, Microsoft Windows and ReactOS operating systems used for substituting paths on physical and logical drives as virtual drives.
As the next version of Windows NT after Windows 2000, as well as the successor to Windows Me, Windows XP introduced many new features but it also removed some others.
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 layers, it contains the cache manager, security reference monitor, memory manager, scheduler (Dispatcher), and blue screen of death.
In Windows NT operating systems, a Windows service is a computer program that operates in the background. It is similar in concept to a Unix daemon. A Windows service must conform to the interface rules and protocols of the Service Control Manager, the component responsible for managing Windows services. It is the Services and Controller app, services.exe, that launches all the services and manages their actions, such as start, end, etc.
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.
The Windows Boot Manager (BOOTMGR
) is the bootloader provided by Microsoft for Windows NT versions starting with Windows Vista and Windows Server 2008. 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.
The booting process of Microsoft Windows varies between different releases.
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.
The Windows 9x series of operating systems refers to a series of Microsoft Windows operating systems produced from 1995 to 2000. They are based on the Windows 95 kernel which is a monolithic kernel. The basic code is similar in function to MS-DOS. They are 16-/32-bit hybrids and require support from MS-DOS to operate.