{
	"id": "1434bfe4-384c-4f65-86e6-e532377f448b",
	"created_at": "2026-04-06T00:11:32.961611Z",
	"updated_at": "2026-04-10T03:30:33.895628Z",
	"deleted_at": null,
	"sha1_hash": "e94412e61b7af50b4c4673deea1072f23be9d1cc",
	"title": "Windows System Services Fundamentals",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 118150,
	"plain_text": "Windows System Services Fundamentals\r\nBy Archiveddocs\r\nArchived: 2026-04-05 21:16:31 UTC\r\nWindows system services are applications that start when the computer is booted and run in the background.\r\n Services handle \r\nlow-level tasks that require no user interaction. There are over 200+ operating system features which implement a\r\nsystem service(s), to support features and functionality such as:\r\nAuthentication, Certificate, Encryption services\r\nNetworking features such as DNS, DHCP, Network Location Awareness, 802.11 Wireless and\r\nWired Services.\r\nHardware related services such as Plug and Play services, display driver enhancements,  audio and\r\neffects,  print services, Bluetooth\r\nRemote access. Terminal Services allow users to log on to a computer from a remote location.\r\nIn addition to core services that are part of Windows, third-party applications can implement device or file system\r\ndrivers. Common examples of third-party services include video, sound, printing,  firewall and antivirus services.\r\nThe main components of the core service architecture are the Service Control Manager (SCM), service control\r\nprograms, and service applications.  The service control programs do not communicate with services directly; all\r\ncommunication goes through the SCM.  This architecture is precisely what makes remote administration\r\ntransparent to the service control program and service applications.\r\n** **\r\nService Control Manager\r\nThe SCM is a special system process that runs the image systemroot\\System32\\Services.exe, which is responsible\r\nfor starting, stopping, and interacting with services. Services are Win32 applications that call special Win32\r\nfunctions to interact with the SCM to perform such actions as registering the service’s successful startup,\r\nresponding to status requests, and pausing or shutting down the service.\r\nService Control Programs\r\nService control programs are standard Win32 applications that use the SCM APIs CreateService, OpenService,\r\nStartService, ControlService, QueryServiceStatus, and DeleteService to communicate with or control services. To\r\nuse the SCM functions, a service control program must first open a communications channel to the SCM. At the\r\ntime of the open call, the service control program must specify what types of actions it wants to perform. For\r\nexample, if a service control program simply wants to enumerate and display the services present in the SCM\r\ndatabase, it requests Enumerate Service access. During its initialization, the SCM creates an internal object that\r\nrepresents the SCM database and uses Windows security functions to protect the object with a security descriptor\r\nthat specifies which accounts can open the object by using which access permissions.\r\nhttps://social.technet.microsoft.com/wiki/contents/articles/12229.windows-system-services-fundamentals.aspx\r\nPage 1 of 16\n\nThe SCM stores the security descriptor in the service’s registry subkey as the Security value, and it reads the value\r\nof Security when it scans the registry’s Services key during initialization so in the same way that a service control\r\nprogram must specify what types of access it wants to the SCM database, a service control program must also tell\r\nthe SCM what access it wants to a service. Examples of accesses that a service control program can request\r\ninclude the ability to query a service’s status and to configure, stop, and start a service.  For example, the security\r\ndescriptor indicates that the Authenticated Users group can open the SCM object with enumerate-service access.\r\nHowever, only administrators can open the object with the access required to create or delete a service.\r\nA service application contains the infrastructure necessary for communicating with the SCM, which sends\r\ncommands to the service telling it to stop, pause, continue, or shut down. A service also calls special functions that\r\ncommunicate its status back to the SCM.   Service applications, such as Web servers, consist of at least one\r\napplication that runs as a service. A user who wants to start, stop, or configure a service uses a service control\r\nprogram. Although Windows provides built-in service control programs that provide general start, stop, pause, and\r\ncontinue functionality, some service applications include their own service control program that allows\r\nadministrators to specify configuration settings particular to the service they manage.\r\nBecause most services do not (and absolutely should not) have a user interface, they are built as console programs.\r\nWhen you install an application that includes a service, the application’s setup program must register the service\r\nwith the SCM. To register the service, the setup program calls the Win32 CreateService function, a services-related function whose client side is implemented in Advapi32.dll (located in the systemroot\\System32 folder).\r\nAdvapi32.dll, the “Advanced API” DLL, implements all the client-side SCM APIs.\r\nThe primary difference between services and normal applications is that services are managed by the Service\r\nControl Manager (SCM). Services are implemented with the services API, which handles the interaction between\r\nthe SCM and services. The SCM maintains a database of installed services and provides a unified way to control\r\nthem, including:\r\nStarting services.\r\nStopping services.\r\nManaging running services.\r\nMaintaining service-related state information.\r\nServices have one of three states: started, stopped, or paused.\r\nStarted:  service has successfully started.\r\nStopped:  a stopped service has been completely shut down and must go through a normal startup\r\nprocedure to enter the started state again.\r\nPaused:  a paused service suspends normal processing, but remains in memory and continues to\r\nrespond to control requests. Paused services can, therefore, return to the started state without going\r\nthrough the startup procedure.\r\nA key characteristic of a service is how it is started. The SCM has a database that includes information on how\r\neach service should be started. The following are the service startup types:\r\nhttps://social.technet.microsoft.com/wiki/contents/articles/12229.windows-system-services-fundamentals.aspx\r\nPage 2 of 16\n\nAutomatic: The SCM automatically starts these services during the system's boot process. They are often called\r\nauto-start services.\r\nManual:  These services must be started manually with the sc.exe command-line tool, or programmatically with\r\nthe StartService function.\r\nThey are often called demand-start services.\r\nDisabled:  These services cannot be started. To start a disabled service, the user must first change the startup type\r\nto automatic or manual and click apply. After a service has started, the SCM uses control requests to manage the\r\nservice's state. For example, the SCM sends control requests to notify a service that it is pausing, is resuming\r\noperation, or should be preparing to shut down. The SCM's database also contains the security settings for each\r\nservice. These settings control how much access a service has to system resources and enable system\r\nadministrators to control access to each service.\r\nRunning every service in its own process, instead of having services share a process whenever possible, wastes\r\nsystem resources. However, sharing processes means that if any of the services in the process encounters a\r\nproblem that causes the process to exit, all the services in that process stop.\r\nSome Windows Server 2003 built-in services run in their own process; however, most services share a process\r\nwith other services. For example, the SCM process, Services.exe, hosts the Event Log and the Plug and Play\r\nservices.\r\nThe security-related services, such as the Security Accounts Manager service, the Net Logon service, and the\r\nIPSEC Services service, share the Lsass.exe process.\r\nThere is also a “generic” process named Service Host (Svchost, or the Svchost.exe application), which contains\r\nmultiple services, located in the systemroot\\Windows\\System32 folder.\r\nA “generic” process named Svchost contains multiple services, and multiple instances of Svchost can run under\r\ndifferent security contexts. Services that run in Svchost processes include Telephony, Remote Procedure Call\r\n(RPC), and Remote Access Connection Manager.\r\nWindows Server 2003 implements services that run in Svchost as DLLs and specifies the location of the DLL of a\r\nservice in the value of the registry entry ImagePath (which has the form “systemroot\\System32\\svchost.exe -k\r\nsvchost instance name”) in the corresponding service subkey. Every service’s registry subkey must also have a\r\nregistry entry named ServiceDll under its Parameters subkey that points to the service’s DLL file. All services that\r\nshare a common Svchost process specify the same parameter (“-k svchost instance name”).\r\nTypically, each Svchost instance running on a Windows Server 2003-based computer corresponds to a distinct\r\naccount. For example, the “netsvcs” instance runs as LocalSystem, the “LocalService” instance runs as NT\r\nAUTHORITY\\LocalService, and the “NetworkService” instance runs as NT AUTHORITY\\NetworkService.\r\nThere are one or two exceptions – for example, the Remote Procedure Call (RPC) service runs in its own\r\nLocalSystem instance for security reasons.\r\nWhen the SCM encounters the first service that has an image path of “svchost.exe -k svchost instance name”\r\nduring service startup, it creates a new image database record for the Svchost instance name and starts the process\r\nas configured.\r\nhttps://social.technet.microsoft.com/wiki/contents/articles/12229.windows-system-services-fundamentals.aspx\r\nPage 3 of 16\n\nThe new Svchost process takes the parameter and looks for a registry subkey having the same name as the\r\nparameter in HKLM\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\SvcHost. Svchost reads the contents of\r\nthe SvcHost subkey, interpreting its contents as a list of service names, and notifies the SCM that it is hosting\r\nthose services when Svchost registers with the SCM.\r\nWhen the SCM encounters a Svchost process during service startup for which the value of its ImagePath matches\r\nthat of an entry that SCM already has in the image database, SCM does not start the second process but instead\r\njust sends a start command for the service to the Svchost process it already started for that ImagePath value. The\r\nexisting Svchost process reads the value of ServiceDll in the service’s subkey and loads the DLL into its process\r\nto start the service.\r\nIn general, the reason services share processes is to diminish memory footprint and thread usage, both of which\r\nincrease dramatically as you add additional processes to the system. For example, every process typically ends up\r\nwith its own thread pool, such as RPC server threads. The different Svchost instances on your computer are, for\r\nthe most part, all running in different accounts, and each one hosts the services that run in that particular account.\r\nBy running the Tasklist.exe tool with the /svc switch, you can see the account name listed for each Svchost\r\ninstance.\r\nMany services will not work properly unless other components of the system are already running. When a\r\ncomputer is started, it follows an algorithm that dictates the order in which services are started. In Windows,\r\nsystem services are divided into a set of predefined groups. Assigning a service to a group has no effect other than\r\nto fine-tune its startup with respect to other services that belong to different groups.\r\nThe SCM builds the internal service database and reads and stores the contents of the List entry in the\r\nHKLM\\SYSTEM\\CurrentControlSet\\Control\\ServiceGroupOrder subkey, a string value that lists the names and\r\norder of the defined service groups. A service’s registry subkey contains an optional Group entry to be used if that\r\nservice or device driver needs to control its startup ordering with respect to services from other groups.\r\nThe SCM reads the value of a service’s Group entry to determine whether it is a member of a group and associates\r\nthis value with the group’s entry in the ServiceGroupOrder subkey mentioned earlier. The SCM also reads and\r\nrecords in the database the service’s group and service dependencies by querying its DependOnGroup and\r\nDependOnService registry entries.\r\nFor example, the Windows Server 2003 networking stack is built from the bottom up, so networking services must\r\nspecify Group entries that place them later in the startup sequence than networking device drivers. The SCM\r\ninternally creates a group list that preserves the ordering of the groups it reads from the registry. Groups include\r\n(but are not limited to) NDIS, TDI, Primary Disk, Keyboard Port, and Keyboard Class. Add-on and third-party\r\napplications can even define their own groups and add them to the list.\r\nSince the introduction of Plug and Play in Microsoft® Windows® 2000, the service group order mechanism has\r\nbecome less significant. In Windows Server 2003, Plug and Play is responsible for loading kernel drivers and\r\nservices. Plug and Play manages the loading of kernel-mode drivers based on the presence of their associated\r\ndevices.\r\nhttps://social.technet.microsoft.com/wiki/contents/articles/12229.windows-system-services-fundamentals.aspx\r\nPage 4 of 16\n\nThe SCM is almost never involved in the loading of a driver. The most interesting remaining use of the service\r\ngroup order mechanism in kernel mode is for file system filter drivers.\r\nThe auto-start option for kernel-mode drivers is being phased out. Even if a driver is marked as AUTO_START, as\r\nsoon as it starts the first time, it will receive a root-enumerated devnode registered on its behalf, and on all\r\nsubsequent boots that root-enumerated devnode will cause the driver to be loaded by Plug and Play during the\r\nsystem start phase before the SCM is started.\r\nThe demand-start option is recommended for almost all Plug and Play drivers. Demand-start no longer means\r\n“when SCM is requested to start the driver” (for example, in response to a net start command) as it did in prior\r\nversions of Windows. It now means when Plug and Play “demands” it because of the discovery of devices\r\nassociated with that driver.\r\nIn addition to notifying the SCM that a service is part of a particular load order group, you can tell the SCM that\r\nthis service requires other services to be running before this service can run. For example, many Internet services\r\n— including the FTP Publishing Service, the World Wide Web Publishing Service, and the Simple Mail Transfer\r\nProtocol (SMTP) Service — are dependent on the IIS Admin Service. If the IIS Admin Service is not available,\r\nthen none of these dependent services can run.\r\nConversely, you cannot stop the IIS Admin Service without first stopping the dependent services. If you could\r\nstop the IIS Admin Service first, all its dependent services would fail because those services cannot run unless IIS\r\nAdmin Service is also running. The IIS Admin Service is therefore antecedent to its dependent services.\r\nThere are two types of service dependencies:\r\nThe current service depends on other services to start. If Service X is antecedent to Service Y, Service X\r\nmust be running before you can run Service Y.\r\nOther services depend on the current service to start. If Service X is dependent on Service Y, Service Y\r\nmust be running before you can run Service X.\r\nFor example, if you run the Sc.exe tool, you will see that three services depend on the Telephony service. If an\r\nadministrator attempts to stop the Telephony service and any dependent services are running, the call fails and the\r\nSCM returns the following error:\r\nERROR_DEPENDENT_SERVICES_RUNNING\r\nFor another example, if you stop the Workstation service by using the following Net.exe command, you will\r\nreceive a list of dependent services that need to be stopped as well.\r\nnet stop workstation\r\nThis command displays the following information:\r\nThe following services are dependent on the Workstation service.\r\nStopping the Workstation service will also stop these services.\r\nhttps://social.technet.microsoft.com/wiki/contents/articles/12229.windows-system-services-fundamentals.aspx\r\nPage 5 of 16\n\nNet Logon\r\n   Distributed File System\r\n   Computer Browser\r\nDo you want to continue this operation? (Y/N) [N]: y\r\nThe Net Logon service is stopping.\r\nThe Net Logon service was stopped successfully.\r\nThe Distributed File System service is stopping.\r\nThe Distributed File System service was stopped successfully.\r\nThe Computer Browser service is stopping.\r\nThe Computer Browser service was stopped successfully.\r\nThe Workstation service is stopping.\r\nThe Workstation service was stopped successfully.\r\nIf you restart the Workstation service by using the following command, the dependent services are not started\r\nautomatically; you need to manually restart the services.\r\nnet start workstation\r\nThis command displays the following information:\r\nThe Workstation service is starting.\r\nThe Workstation service was started successfully.\r\nThe reason is that the services being stopped are all the currently running services that depend on the Workstation\r\nservice. They cannot run unless the Workstation service has already started. Since the Workstation service does\r\nnot depend on any of those services, there is no requirement for the Workstation service to start the other services\r\nHowever, if you were to start a dependent service while the Workstation service was stopped, the Workstation\r\nservice would be started first.\r\nThe SCM runs within Services.exe. The SCM automatically starts when the operating system is loaded, and stops\r\nwhen the operating system is shut down. The SCM runs with system privileges, and provides a unified and secure\r\nmeans of controlling service applications. The SCM is responsible for communicating with the various services\r\nand instructing them to start, stop, pause, and continue.\r\nThe SCM maintains a database of installed services and device drivers in the registry. The database is used by the\r\nSCM and programs that add, modify, or configure services. The registry subkey for this database is\r\nHKLM\\SYSTEM\\CurrentControlSet\\Services.\r\nhttps://social.technet.microsoft.com/wiki/contents/articles/12229.windows-system-services-fundamentals.aspx\r\nPage 6 of 16\n\nThis subkey contains a subkey for each installed service and driver. The name of the subkey is the name the\r\nservice or driver had when the SCM installed it.\r\nAn initial copy of the SCM database is created during Windows Server 2003 setup. The database includes all the\r\nservice-related parameters defined for a service, in addition to fields that track the service’s status. Additionally,\r\nthe database contains records for the device drivers required during system restart. The Type entries are found in\r\nthe registry in the service subkeys under the HKLM\\SYSTEM\\CurrentControlSet\\Services subkey.\r\nThere are four values that apply to device drivers:\r\n1 (SERVICE_KERNEL_DRIVER)\r\n2 (SERVICE_FILE_SYSTEM_DRIVER)\r\n4 (SERVICE_ADAPTER)\r\n8 (SERVICE_RECOGNIZER_DRIVER)\r\nThe value of the Start entry determines if and when the service or driver is loaded during system startup.\r\nWhen the SCM starts a service process, the following occurs:\r\nThe process immediately invokes a service function, StartServiceCtrlDispatcher, which accepts a list of entry\r\npoints into services, with one entry point for each service in the process. Each entry point is identified by the name\r\nof the service the entry point corresponds to.\r\nStartServiceCtrlDispatcher creates a named pipe communications connection to the SCM and then sits in a loop\r\nwaiting for commands to come through the pipe.\r\nThe SCM sends a service-start command each time it starts a service the process owns. For each start command it\r\nreceives, the function creates a thread, called a service thread, to invoke the starting service’s entry point.\r\nThe StartServiceCtrlDispatcher service function waits indefinitely for commands from the SCM and returns\r\ncontrol to the process’s main function only when all the process’s service threads have terminated, allowing the\r\nservice process to clean up resources before exiting.\r\nThe first action of a service’s entry point (ServiceMain routine) is to call the RegisterServiceCtrlHandler(Ex) API,\r\nwhich takes a pointer to the service’s Handler(Ex) function. The Handler(Ex) function is designed to receive and\r\nhandle control messages sent to the service, which are passed along from the SCM.\r\nThe StartServiceCtrlDispatcher service function stores the table in local process memory, and the\r\nRegisterServiceCtrlHandler finishes populating it with the service’s HandlerEx pointer and\r\nSERVICE_STATUS_HANDLE. The service entry point continues initializing the service, which can include\r\nallocating memory, creating communications end points, and reading private configuration data from the registry.\r\nA convention most services follow is to store their service-specific parameters under a Parameters subkey in their\r\nservice registry subkey.\r\nWhile the entry point is initializing the service, it might periodically send status messages to the SCM to indicate\r\nhow the service’s startup is progressing. After the entry point finishes initialization, a service thread usually sits in\r\na loop waiting for requests from client applications. For example, a Web server would initialize a Transmission\r\nhttps://social.technet.microsoft.com/wiki/contents/articles/12229.windows-system-services-fundamentals.aspx\r\nPage 7 of 16\n\nControl Protocol (TCP) listen socket and wait for inbound Hypertext Transmission Protocol (HTTP) connection\r\nrequests.\r\nA service process’s main thread, which invokes and runs inside of StartServiceCtrlDispatcher, receives SCM\r\ncommands directed at services in the process and uses the table of the services’ handler functions to locate and\r\ninvoke the service function responsible for responding to a command. SCM commands include stop, pause,\r\nresume, interrogate, shut down, and application-defined commands.\r\nFor more information about the StartServiceCtrlDispatcher and RegisterServiceCtrlDispatcher APIs, see the\r\nSoftware Development Kit (SDK) information in the MSDN Library link on the Web Resources page\r\n(http://go.microsoft.com/fwlink/?linkid=291) at http://www.microsoft.com/windows/reskits/webresources.\r\nDuring service initialization, the SCM starts all services that have Start registry entries with a value of\r\n2 (SERVICE_AUTO_START) and the services on which they depend. For example, if services that are\r\nautomatically started depend on a manually started service, the demand-start service is also started automatically.\r\nThe load order is determined by the following:\r\n1. The order of service groups in the load-ordering group list subkey,\r\nHKLM\\SYSTEM\\CurrentControlSet\\Control\\ServiceGroupOrder.\r\nThe order of drivers within a group specified in the HKLM\\SYSTEM\\CurrentControlSet\\Control\\GroupOrderList\r\nsubkey.\r\nThe dependencies listed for each service.\r\nWhen the startup process is complete, the system executes the boot verification program specified in the\r\nHKLM\\SYSTEM\\CurrentControlSet\\Control\\BootVerificationProgram subkey.\r\nBy default, this value is not set. The system reports that the startup process was successful after the auto-start\r\nsequence completes.\r\nAfter the computer has started successfully, the operating system saves a clone of the database in the Last Known\r\nGood configuration. The system can restore this copy of the database if changes made to the active database cause\r\nrestarting the computer to fail.\r\nFor more information about the Last Known Good configuration, see “Accepting the Boot and Last Known Good\r\nConfiguration” later in this chapter.\r\nThe following sequence describes how services are automatically started:\r\n1. The SCM starts all services that have a Start registry entry with a value of 2 (SERVICE_AUTO_START).\r\nThe SCM also starts auto-start device drivers.\r\nThe algorithm for starting services in the correct order proceeds in various stages, whereby a stage corresponds to\r\na group, and stages proceed in the sequence defined by the group order stored in the List registry entry in the\r\nHKLM\\SYSTEM\\CurrentControlSet\\Control\\ServiceGroupOrder subkey. The value of the List entry includes the\r\nnames of groups in the order that the SCM starts them.\r\nhttps://social.technet.microsoft.com/wiki/contents/articles/12229.windows-system-services-fundamentals.aspx\r\nPage 8 of 16\n\nFor more information about the ServiceGroupOrder subkey, see “Service Groups” earlier in this chapter.\r\nThe SCM marks all the service entries that belong to the stage’s group for startup.\r\nThe SCM loops through the marked services, verifying whether it can start each service. The verification consists\r\nof determining whether the service has a dependency on another group, as specified by the existence of the\r\nDependOnGroup entry in the subkey for a service.\r\nIf a dependency exists, the group on which the service is dependent must have already been initialized, and\r\nat least one service in that group must have successfully started.\r\nIf the service depends on a group that starts later than the service’s group in the group startup sequence, the\r\nSCM logs a circular dependency error for the service.\r\nThe SCM checks to see whether the service depends on one or more services, and whether those services have\r\nalready started. Service dependencies are indicated by the value of the DependOnService entry in the subkey for a\r\nservice.\r\nIf a service depends on other services that belong to groups that come later in the List entry in the\r\nHKLM\\SYSTEM\\CurrentControlSet\\Control\\ServiceGroupOrder subkey, the SCM also returns a circular\r\ndependency error such as “Detected circular dependencies demand to start,” and does not start the service.\r\nIf the service depends on any services from the same group that have not yet started, the service is skipped.\r\nWhen the dependencies of a service have been satisfied, the SCM makes a final check to see whether the service\r\nis part of the current boot configuration before starting the service.\r\nWhen the SCM starts a service, it first determines the name of the file that runs the service’s process by reading\r\nthe value of the ImagePath entry in the service’s registry subkey.\r\nIt then examines the value of the Type entry in the service’s subkey, and if that value is 32 (that is, the service\r\nshares a process), the SCM ensures that the process the service runs in — if already started — is logged on by\r\nusing the same account as specified for the service being started. A service’s ObjectName registry entry stores the\r\nuser account where the service runs. The SCM will fail to start a service with a missing ObjectName, and will\r\nreturn the error ERROR_INVALID_SERVICE_ACCOUNT.\r\nThe SCM verifies that the service’s process has not already been started in a different account by checking to see\r\nwhether the value of the service’s ImagePath entry has a record in an internal SCM database identified as the\r\nimage database.\r\n If the image database does not have a record for the ImagePath entry, the SCM creates one. When the\r\nSCM creates a new record, it stores the logon account name used for the service and the data from the\r\nvalue of the service’s ImagePath entry. The SCM requires services to have an ImagePath entry.\r\nIf a service does not have an ImagePath entry, the SCM returns an error stating that it could not find the\r\nservice’s path and is not able to start the service.\r\nIf the SCM locates an existing image database record with matching data from the value of the ImagePath\r\nentry, the SCM ensures that the user account information for the service it is starting is the same as the\r\ninformation stored in the database record. A process can be logged on as only one account, so the SCM\r\nhttps://social.technet.microsoft.com/wiki/contents/articles/12229.windows-system-services-fundamentals.aspx\r\nPage 9 of 16\n\nreturns an error (ERROR_DIFFERENT_SERVICE_ACCOUNT) when a service specifies a different\r\naccount name than another service that has already started in the same process.\r\nThe SCM logs on a service if the service’s configuration specifies the service’s process should be started. The\r\nSCM logs on services that do not run in the system account by calling the LogonUserEx API, implemented by the\r\nLocal Security Authority (Lsass.exe). Lsass.exe normally requires a password, but the SCM indicates to Lsass.exe\r\nthat the password is stored as a Local Security Authority (LSA) secret in the registry subkey\r\nHKLM\\SECURITY\\Policy\\Secrets.\r\nWhen the SCM calls LogonUserEx, it specifies a service logon as the logon type. Lsass.exe looks up the password\r\nin the Secrets subkey in HKLM\\SECURITY\\Secrets that has a name in the form _SC_\u003cservice name\u003e. The SCM\r\ndirects Lsass.exe to store a logon password as a secret when a service control program configures a service’s\r\nlogon information by using the CreateService or ChangeServiceConfig APIs.\r\nWhen a logon is successful, LogonUserEx returns a handle to an access token to the caller. Windows Server 2003\r\nuses access tokens to represent your security context, and the SCM later associates the access token with the\r\nprocess that implements the service.\r\nAfter a successful logon, the SCM loads the account’s profile information, if it is not already loaded, by calling\r\nLoadUserProfile, which is implemented in Userenv.dll from systemroot\\System32. The ProfileImagePath registry\r\nentry in the HKLM\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\ProfileList\\user profile key\u003e subkey\r\ncontains the location on disk of a registry hive that loads into the registry, making the information in the hive the\r\nHKEY_CURRENT_USER key for the service.\r\nThe SCM proceeds to start the service’s process if the process has not already been started (for a previous service,\r\nfor example). The SCM starts the process in a suspended state and creates a named pipe through which it\r\ncommunicates with the service process, and it assigns the pipe the name \\Pipe\\Net\\NetControlPipeX, where X is a\r\nnumber that is incremented each time the SCM creates a pipe.\r\nThe SCM resumes the service process and waits for the service to connect to its SCM pipe.\r\nIf the pipe exists, the value of the ServicesPipeTimeout registry entry in the\r\nHKLM\\SYSTEM\\CurrentControlSet\\Control subkey determines the length of time that the SCM waits for\r\na service to connect before it gives up and terminates the process.\r\nIf the ServicesPipeTimeout entry does not exist, the SCM uses a default time-out of 30 seconds. The SCM\r\nuses the same time-out value for all its service communications.\r\nWhen a service connects to the SCM through the pipe, the SCM sends the service a start command. If the service\r\nfails to respond positively to the start command within the time-out period, the SCM gives up and moves on to\r\nstart the next service.\r\nWhen a service does not respond to a start request, the SCM will stop the process if the process does not contain\r\nother running services. The SCM will stop the process if an OWN_PROCESS service fails or if the first\r\nSHARED_PROCESS service to be started in a process fails. In the latter case, the SCM will return\r\nERROR_SERVICE_REQUEST_TIMEOUT (for demand-start requests) and log\r\nEVENT_CONNECTION_TIMEOUT.\r\nhttps://social.technet.microsoft.com/wiki/contents/articles/12229.windows-system-services-fundamentals.aspx\r\nPage 10 of 16\n\nA hung auto-start service — for example, a service stuck in SERVICE_START_PENDING forever — is not\r\nstopped by the SCM, but will generate an event log message (EVENT_SERVICE_START_HUNG) and possibly a\r\nmessage box popup.\r\nThus, the SCM continues looping through the services belonging to a group until all the services have either\r\nstarted or returned errors (the services could fail to start for other reasons). Looping is way the SCM automatically\r\norders services within a group according to the value of their DependOnService entries. Looping helps the SCM\r\nsend start parameters to a dependent service while the arguments are held in the stack until the dependent service\r\nis started. The SCM will start the services that other services depend on in earlier loops, skipping the dependent\r\nservices until subsequent loops.\r\nAfter the SCM completely checks for all the groups in the List entry in the\r\nHKLM\\SYSTEM\\CurrentControlSet\\Control\\ServiceGroupOrder subkey, it performs a check for all the\r\nremaining (that is, ungrouped) services.\r\nWhen the dependencies of a service have been satisfied, the SCM makes a final check to see whether the service\r\nis part of the Last Known Good configuration before starting the service.\r\nThe SCM adds entries to the SCM database for device drivers in addition to services. The SCM starts drivers\r\nconfigured as auto-start and detects startup failures for drivers configured as boot-start and system-start. The I/O\r\nManager loads drivers configured as boot-start and system-start before any user-mode processes start, and\r\ntherefore any drivers having these start types are loaded before the SCM starts itself.\r\nIf a service the SCM starts has a value of 1 (SERVICE_KERNEL_DRIVER) or\r\n2 (SERVICE_FILE_SYSTEM_DRIVER) for its Type registry entry, the service is a device driver, and the SCM\r\nloads the driver.\r\nThe SCM enables the load driver security privilege for the SCM process and then invokes the kernel API\r\nNtLoadDriver, passing in the value of the ImagePath entry in the driver’s registry subkey.\r\nWhen the operating system is started in Safe Mode, the SCM ensures that each service and driver is either\r\nidentified by name or by group in the appropriate subkey in the SafeBoot registry subkey. There are two safe boot\r\nregistry subkeys, Minimal and Network, located in the HKLM\\SYSTEM\\CurrentControlSet\\Control\\SafeBoot\r\nsubkey. The one that the SCM checks depends on which mode the user selected during a restart of the computer.\r\nIf you select Safe Mode or Safe Mode with Command Prompt at the special boot menu (which you can\r\naccess by pressing F8 when prompted in the boot process), the SCM references the\r\nHKLM\\SYSTEM\\CurrentControlSet\\SafeBoot\\Minimal subkey.\r\nIf you select Safe Mode with Networking, the SCM references the\r\nHKLM\\SYSTEM\\CurrentControlSet\\SafeBoot\\Network subkey. The existence of an Option entry of data\r\ntype string in the SafeBoot subkey indicates not only that the system booted in Safe Mode but also the\r\nmode the user selected.\r\nThe minimum services and drivers started under Safe Mode or Safe Mode with Command Prompt are the\r\nfollowing:\r\nhttps://social.technet.microsoft.com/wiki/contents/articles/12229.windows-system-services-fundamentals.aspx\r\nPage 11 of 16\n\nCryptographic Services\r\nEvent Log\r\nHelp and Support\r\nLogical Disk Manager Administrative Service\r\nNet Logon\r\nPlug and Play\r\nRemote Procedure Call (RPC)\r\nWindows Management Instrumentation\r\nThe minimum services and drivers started under Safe Mode with Networking are the following:\r\nAFD Networking Support Environment\r\nComputer Browser\r\nDHCP Client\r\nDNS Client\r\nEvent Log\r\nHelp and Support\r\nLogical Disk Manager\r\nNetBIOS Interface\r\nNetBIOS over TCPIP\r\nNet Logon\r\nNetwork Connections\r\nPlug and Play\r\nRemote Procedure Call (RPC)\r\nServer\r\nTCP/IP NetBIOS Helper\r\nTCP/IP Protocol Driver\r\nTerminal Services\r\nWindows Management Instrumentation\r\nWorkstation\r\nBesides starting services, the system charges the SCM with determining when the system’s registry configuration,\r\nHKLM\\SYSTEM\\CurrentControlSet, needs to be saved as the Last Known Good configuration control set. The\r\nCurrentControlSet registry subkey contains the Services subkey. Therefore, CurrentControlSet includes the\r\nregistry representation of the SCM database. It also contains the Control subkey, which stores many kernel-mode\r\nand user-mode subsystem configuration settings.\r\nBy default, a successful startup consists of a successful startup of auto-start services and a successful user logon. A\r\nstartup process fails if the operating system halts because a device driver fails and stops the operating system\r\nduring startup, or if an auto-start service that has an ErrorControl registry entry with a value of 2\r\n(SERVICE_ERROR_SEVERE) or 3 (SERVICE_ERROR_CRITICAL) returns a startup error. For more\r\ninformation about ErrorControl registry entries, see the Software Development Kit (SDK) information in the\r\nMSDN Library link on the Web Resources page (http://go.microsoft.com/fwlink/?linkid=291) at\r\nhttp://www.microsoft.com/windows/reskits/webresources.\r\nhttps://social.technet.microsoft.com/wiki/contents/articles/12229.windows-system-services-fundamentals.aspx\r\nPage 12 of 16\n\nThe SCM knows when it has completed a successful startup of the auto-start services; however, the Winlogon\r\napplication, located in systemroot\\System32*,* must notify the SCM when there is a successful logon, indicating\r\nthat the system has successfully proceeded so that the current control set can be saved and selected as the new Last\r\nKnown Good configuration control set. When you log on, Winlogon sends a message to the SCM. Following a\r\nsuccessful start of the auto-start services, the SCM saves the current registry startup configuration.\r\nThird-party vendors can supersede the Winlogon definition of a successful logon with their own definition. For\r\nexample, a system running SQL Server might not consider the startup process successful until after SQL Server is\r\nable to accept and process transactions.\r\nWhen your computer is shut down, the following occurs:\r\n1. The Winlogon process sends a message to the Client Server Runtime Subsystem (Csrss.exe), the Win32\r\nsubsystem process, to invoke the Csrss.exe shutdown routine.\r\nCsrss.exe loops through the active processes and notifies them that the system is shutting down. For every system\r\nprocess except Services.exe, Csrss.exe waits up to the number of seconds specified by the value of the registry\r\nentry WaitToKillAppTimeout in the HKEY_USERS\\DEFAULT\\Control Panel\\Desktop subkey for the process to\r\nexit before moving on to the next process. The default value of the WaitToKillAppTimeout entry is 20 seconds.\r\nWhen Csrss.exe encounters the Services.exe process, it also notifies it that the operating system is shutting down,\r\nbut a time-out specific to the SCM.\r\nCsrss.exe recognizes the SCM by using the process identifier (PID) Csrss.exe saved when the SCM registered\r\nwith Csrss.exe during system initialization.\r\nThe SCM time-out differs from that of other processes because the Csrss.exe process waits while the SCM\r\ncommunicates with services that need to perform cleanup when they shut down; therefore, an administrator might\r\nneed to adjust only the SCM time-out. The SCM time-out value resides in the registry entry\r\nWaitToKillServiceTimeout in the HKLM\\SYSTEM\\CurrentControlSet\\Control subkey. Its default value is\r\n20 seconds.\r\nThe SCM shutdown handler is responsible for sending shutdown notifications asynchronously to only those\r\nservices that requested shutdown notification when they initialized with the SCM. The shutdown control code is\r\nSERVICE_CONTROL_SHUTDOWN.\r\nThe SCM loops through the SCM database, searching for services that need shutdown notification, and sends each\r\none a shutdown command.\r\nFor each service that is about to be shut down, the SCM sends a shutdown command and it records the value of\r\nthe service’s wait hint — a value that the service also specifies when it registers with the SCM.\r\nA service’s wait hint is the amount of time the SCM sits in a loop waiting for a service to start or shut down. The\r\nwait hint must indicate how many milliseconds the program that is sending the control code should wait before\r\npolling the service’s status again. The SCM keeps track of the largest wait hint it receives.\r\nhttps://social.technet.microsoft.com/wiki/contents/articles/12229.windows-system-services-fundamentals.aspx\r\nPage 13 of 16\n\nAfter sending the shutdown messages, the SCM waits until all of the services it notified of the shutdown have\r\nexited, until the time specified by the largest wait hint passes, or until the value of the WaitToKillServiceTimeout\r\nentry is exceeded. Services.exe itself is stopped by Csrss.exe.\r\nIf the wait hint expires without a service exiting, the SCM determines whether one or more of the services\r\nit was waiting on to exit have sent a message to the SCM telling the SCM that the service is progressing in\r\nits shutdown process.\r\nIf at least one service made progress, the SCM waits again for the duration of the wait hint. The SCM\r\ncontinues executing this wait loop until either all the services have exited or none of the services upon\r\nwhich it is waiting has notified it of progress within the wait hint time-out period.\r\nWhile the SCM is busy telling services to shut down and waiting for them to exit, Csrss.exe waits for the SCM to\r\nexit.\r\nIf all services end in the SERVICE_STOPPED state, the SCM exits on its own.\r\nIf the services do not all end up in the SERVICE_STOPPED state, the SCM loops for 30 seconds. The\r\nservices that did not end up in the SERVICE_STOPPED state are eventually stopped, along with\r\nServices.exe itself, by Csrss.exe as the system shuts down.\r\nIf the wait by Csrss.exe ends without the SCM having exited (that is, the WaitToKillServiceTimeout time\r\nexpires), Csrss.exe just continues the shutdown process and eventually stops Services.exe as a result.\r\nThe SCM supports handle types or entry points to allow access to the following objects:\r\nThe database of installed services\r\nA service\r\nThe database lock\r\nThe database of installed services is represented by an internal container object that holds service objects. This\r\nhandle or entry point is used when installing, deleting, opening, and enumerating services and when locking the\r\nservices database.\r\nAn installed service is represented by a service object. The requested access is granted or denied depending on the\r\naccess token of the calling process and the security descriptor associated with the internal or service object. This\r\nlevel of access is then associated with all subsequent calls that use this handle. If a subsequent call requires a level\r\nof access that was not originally requested for that handle, the call will fail, regardless of whether the current user\r\ncould have requested a handle that allowed that level of access. A best practice for clients of the SCM APIs is to\r\nrequest only the level of access that will be required.\r\nThe database lock is represented by a lock object that is created during SCM initialization to serialize access to the\r\ndatabase of installed services. The SCM acquires the lock before starting a service or driver. Thus if an installer\r\nprogram has acquired a database lock, a demand-start cannot progress until the lock is released. It is important for\r\ninstaller programs to release this lock as soon as they can. Any installer program that subsequently tries to acquire\r\nthis lock will receive the ERROR_SERVICE_DATABASE_LOCKED error, and retry after a short wait.\r\nTraditionally, services in Windows operating systems earlier than Microsoft® Windows® XP and Windows 2000\r\nhave had the choice of running under either the LocalSystem security context or under an arbitrary user account.\r\nhttps://social.technet.microsoft.com/wiki/contents/articles/12229.windows-system-services-fundamentals.aspx\r\nPage 14 of 16\n\nCreating user accounts for each service is cumbersome, especially because of password management for those\r\naccounts. Because of this, nearly all local services were configured to run as LocalSystem. The problem with this\r\nis that the LocalSystem account is highly privileged, and breaking into the service is often an easy way to achieve\r\na privilege elevation attack.\r\nMany services do not need an elevated privilege level; hence the need for a lower privilege level security context\r\navailable on all computers.\r\nIn Windows services can run under the following security contexts:\r\nLocalSystem account\r\nNetworkService account (NT AUTHORITY\\NetworkService)\r\nLocalService account (NT AUTHORITY\\LocalService)\r\nDomain user account\r\nLocal user account\r\nThe security context under which the service runs affects the access rights that the service has on the computer\r\nand on the network. The security context of a service is an important consideration for service developers and\r\nsystem administrators because it dictates what resources the process can access. Unless a service installation\r\nprogram or administrator specifies otherwise, services run in the security context of the LocalSystem account\r\n(displayed sometimes as SYSTEM and other times as LocalSystem), which has some special characteristics.\r\nLocalSystem is a special, predefined local account available only to system processes. This account does not have\r\na password.\r\nOn computers running any version of Microsoft® Windows NT®, a service that runs in the context of the\r\nLocalSystem account inherits the security context of the SCM. The service is not associated with any logged-on\r\nuser account and does not have credentials (domain name, user name, and password) to be used for verification.\r\nThe service has limited access to network resources, such as shared folders and named pipes, because it has no\r\ncredentials and must connect by using a null session.\r\nOn computers running Windows 2000 or Windows Server 2003, a service that runs in the context of the\r\nLocalSystem account uses the credentials of the computer when accessing resources over the network and has full\r\naccess to local resources. For services that access the Active Directory® directory service, the LocalSystem\r\ncontext is constraining. When a service runs under the LocalSystem account on a computer that is a domain\r\nmember, such as a Windows Server 2003–based computer running as a member server or Microsoft Windows XP\r\nProfessional, the service runs under the context of the computer account when it accesses domain resources.\r\nComputer accounts typically have very few privileges and do not belong to groups. Adding computer accounts to\r\ngroups is not recommended because the accounts are subject to deletion and re-creation if the computer leaves and\r\nthen rejoins the domain.\r\nOn the other hand, a service that runs in the context of LocalSystem on a domain controller has full access to the\r\ndirectory, because the domain controller hosts a directory replica and LocalSystem has complete access to local\r\nresources. The Net Logon service is an example of a service that runs under the LocalSystem account.\r\nhttps://social.technet.microsoft.com/wiki/contents/articles/12229.windows-system-services-fundamentals.aspx\r\nPage 15 of 16\n\nThe LocalSystem account is the same account in which all the Windows Server 2003 user-mode operating system\r\ncomponents run, including Session Manager (Smss.exe), Csrss.exe, Lsass.exe, the Winlogon process\r\n(Winlogon.exe), some services located in the systemroot\\System32 folder, and the SCM (Services.exe).\r\nFrom a security perspective, the LocalSystem account is extremely powerful — more powerful than any local or\r\ndomain account when it comes to security on a local computer. This account has the following characteristics:\r\nIt is a member of the local Administrators group.\r\nIt has the right to enable virtually every privilege, even privileges not normally granted to the local\r\nadministrator account, such as creating security tokens.\r\nMost files and registry keys grant full access to the LocalSystem account. Even if they do not grant full\r\naccess, a process that runs under the LocalSystem account can exercise the Take Ownership privilege to\r\ngain access.\r\nProcesses running under the LocalSystem account run with the default user profile\r\n(HKEY_USERS\\DEFAULT). They can access configuration information stored in the user profiles of\r\nother accounts through the registry key HKEY_USERS\\SID\u003e.\r\nWhen a computer is a member of a Windows Server 2003–based domain, the LocalSystem account\r\nincludes the computer security identifier (SID) for the computer on which a service process is running.\r\nTherefore, a process running in the LocalSystem account will be automatically authenticated on other\r\ncomputers in the same forest by using the computer account of the computer running the service process.\r\n(A forest is a grouping of domains.)\r\nUnless the computer account is specifically granted access to resources (such as shared folders, named\r\npipes, and so on), a process can access network resources that allow null sessions — that is, connections\r\nthat require no credentials. You can specify the shared folders and named pipes on a particular computer\r\nthat permits null sessions in the NullSessionPipes and NullSessionShares registry entries in the\r\nHKLM\\SYSTEM\\CurrentControlSet\\Services\\lanmanserver\\parameters subkey.\r\nIT Professionals\r\nDeveloping Efficient Background Processes for Windows\r\nImpact of Session 0 Isolation on Services and Drivers in Windows\r\n** **\r\nWindows Services documentation\r\nInternet Connection Sharing and Internet Connection Firewall\r\nNotifyServiceStatusChange Function\r\nService Control Handler Function \r\nService Trigger Events\r\nConfiguring a Service Using SC\r\nSource: https://social.technet.microsoft.com/wiki/contents/articles/12229.windows-system-services-fundamentals.aspx\r\nhttps://social.technet.microsoft.com/wiki/contents/articles/12229.windows-system-services-fundamentals.aspx\r\nPage 16 of 16",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://social.technet.microsoft.com/wiki/contents/articles/12229.windows-system-services-fundamentals.aspx"
	],
	"report_names": [
		"12229.windows-system-services-fundamentals.aspx"
	],
	"threat_actors": [
		{
			"id": "75108fc1-7f6a-450e-b024-10284f3f62bb",
			"created_at": "2024-11-01T02:00:52.756877Z",
			"updated_at": "2026-04-10T02:00:05.273746Z",
			"deleted_at": null,
			"main_name": "Play",
			"aliases": null,
			"source_name": "MITRE:Play",
			"tools": [
				"Nltest",
				"AdFind",
				"PsExec",
				"Wevtutil",
				"Cobalt Strike",
				"Playcrypt",
				"Mimikatz"
			],
			"source_id": "MITRE",
			"reports": null
		}
	],
	"ts_created_at": 1775434292,
	"ts_updated_at": 1775791833,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/e94412e61b7af50b4c4673deea1072f23be9d1cc.pdf",
		"text": "https://archive.orkl.eu/e94412e61b7af50b4c4673deea1072f23be9d1cc.txt",
		"img": "https://archive.orkl.eu/e94412e61b7af50b4c4673deea1072f23be9d1cc.jpg"
	}
}