This chapter covers Windows Services Management, a core topic for the CompTIA A+ 220-1102 exam under Domain 1.0 (Operating Systems), Objective 1.2: Given a scenario, manage and configure Windows services. Services are background processes that run without user interaction, critical for system functionality, security, and performance. Expect 5–8% of exam questions to touch on services, including start types, dependencies, recovery options, and service accounts. Mastering this material will help you troubleshoot boot issues, optimize system performance, and secure Windows environments.
Jump to a section
Think of Windows Services as a restaurant kitchen that operates 24/7, even when the dining room (user desktop) is closed. The kitchen has various stations (services) like the grill (Print Spooler), the pastry station (Windows Update), and the dishwasher (Background Intelligent Transfer Service). Each station has a specific recipe (service code) that dictates exactly how it works. The head chef (Service Control Manager or SCM) is responsible for starting each station at the right time, monitoring if a station is running, and restarting it if it burns something (crashes). The kitchen can start in different modes: automatic (starts when the restaurant opens, i.e., system boots), manual (started only when an order comes in, i.e., a dependent service or application requests it), or disabled (the station is boarded up and cannot be used). The head chef logs every action: which station started, when, and if it failed. If a station fails repeatedly, the chef might give up after a few attempts (failure actions like restart, run a program, or take no action). The kitchen also has a hierarchy: some stations depend on others – you cannot bake a cake (Windows Audio) if the oven (Plug and Play) is not on. The SCM ensures these dependencies are started in order. This is exactly how Windows Services work – they run under the SYSTEM or NETWORK SERVICE accounts, without a user logged in, managed by the SCM, with defined dependencies, start types, and recovery options.
What Are Windows Services and Why Do They Exist?
Windows Services are long-running executable applications that run in their own Windows sessions and can start automatically at boot, even if no user is logged on. They are designed to provide core operating system features and support for applications that need to run continuously or on demand. Unlike regular applications that run under a user account and stop when the user logs off, services run under special built-in accounts (LocalSystem, LocalService, NetworkService) or a specified domain account. This allows them to perform tasks like listening for network connections, managing hardware, and performing scheduled maintenance without user intervention.
The Service Control Manager (SCM) is the system component responsible for managing the service database and controlling service states. The SCM is implemented in services.exe and starts early in the boot process. It maintains a database of installed services in the registry under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services. Each service has a subkey containing its configuration, including the image path, start type, error control, and dependencies.
How Services Work Internally
When the system boots, the kernel starts smss.exe, which then starts csrss.exe and wininit.exe. wininit.exe starts the SCM (services.exe). The SCM reads the registry to determine which services should start automatically. It starts these services in order based on the Start value and the Group and DependOnService entries. The Start value can be:
0x00000000 (BOOT_START) – Used by device drivers started by the boot loader. Not applicable to services.
0x00000001 (SYSTEM_START) – Started by I/O Manager for drivers. Not applicable to services.
0x00000002 (AUTO_START) – Started automatically by the SCM during system startup.
0x00000003 (DEMAND_START) – Started manually by a user, application, or dependent service.
0x00000004 (DISABLED) – Cannot be started.
For automatic services, the SCM also considers the DelayedAutoStart flag. If set to 1, the service starts shortly after the initial boot to improve login performance.
Each service has a process entry point that calls StartServiceCtrlDispatcher(). This function connects the service's main thread to the SCM, allowing the SCM to send control requests (start, stop, pause, continue, shutdown) to the service. The service must respond to these control requests within a timeout (default 30 seconds) or the SCM marks it as hung.
Key Components, Values, Defaults, and Timers
- Service Status: The SCM tracks the state of each service using a status structure that includes:
- SERVICE_STOPPED (0x00000001)
- SERVICE_START_PENDING (0x00000002)
- SERVICE_STOP_PENDING (0x00000003)
- SERVICE_RUNNING (0x00000004)
- SERVICE_CONTINUE_PENDING (0x00000005)
- SERVICE_PAUSE_PENDING (0x00000006)
- SERVICE_PAUSED (0x00000007)
- Service Account: Services run under one of the following accounts:
- LocalSystem (NT AUTHORITY\SYSTEM) – Highest privileges, can access local resources without restrictions.
- LocalService (NT AUTHORITY\LOCAL SERVICE) – Reduced privileges, acts as a non-privileged user on the local computer.
- NetworkService (NT AUTHORITY\NETWORK SERVICE) – Similar to LocalService but can access network resources as the computer account.
- User-specified domain account – For services that need specific permissions.
- Recovery Options: When a service fails, the SCM can take one of the following actions (configurable via sc failure):
- Take No Action (default)
- Restart the Service
- Run a Program
- Restart the Computer
The actions can be set for first, second, and subsequent failures. A reset period (default 86400 seconds = 1 day) determines how long after a successful start the failure count resets.
Dependencies: A service can depend on one or more other services or load order groups. The SCM ensures that all dependencies are started before starting the dependent service. If a dependency fails to start, the dependent service will not start and an error is logged.
Service Start Order: The SCM uses the Group and Tag values in the registry to order service starts within a group. Services in the same group are started sequentially based on tag order. The DependOnGroup value allows a service to depend on an entire group being started.
Configuration and Verification Commands
The primary command-line tool for managing services is sc.exe (Service Control). The GUI tool is services.msc. Common sc commands:
List all services: sc query
Query a specific service: sc query <service_name>
Start a service: sc start <service_name>
Stop a service: sc stop <service_name>
Configure start type: sc config <service_name> start= <auto|demand|disabled>
Set recovery options: sc failure <service_name> reset= 86400 actions= restart/5000/restart/10000/reboot/60000
View dependencies: sc enumdepend <service_name>
Create a service: sc create <service_name> binPath= <path_to_exe>
Delete a service: sc delete <service_name>
PowerShell cmdlets like Get-Service, Start-Service, Stop-Service, Set-Service, and New-Service provide similar functionality.
Interaction with Related Technologies
Services interact with:
Event Viewer: Service start/stop events and failures are logged in the System log.
Task Manager: The Services tab shows service status and PID.
Resource Monitor: Shows service process resource usage.
Group Policy: Can configure service startup mode and security settings.
Windows Firewall: Services may need firewall exceptions to listen on ports.
Performance Monitor: Can monitor service-specific counters like % Processor Time for the service process.
Services are also critical for security: the principle of least privilege applies to service accounts. Services should run under the minimum necessary account. For example, a service that only needs local resources should use LocalService, not LocalSystem.
Install or Register a Service
To create a new service, you use the `sc create` command or install an application that registers its own service. When you run `sc create MyService binPath= "C:\Path\To\MyApp.exe"`, the SCM adds a new registry key under `HKLM\SYSTEM\CurrentControlSet\Services\MyService`. This key contains values such as `ImagePath` (the executable path), `Start` (default 3 = demand), `Type` (0x10 = own process, 0x20 = share process), `ErrorControl` (0 = ignore, 1 = normal, 2 = severe, 3 = critical), and `ObjectName` (account name). The service is now registered but not started.
Configure Service Startup Type
Using `sc config MyService start= auto` sets the service to start automatically at boot. The SCM will launch this service during system startup, after dependencies are met. If set to `demand`, the service starts only when explicitly requested by a user or another service. If set to `disabled`, the service cannot be started. The `delayed-auto` option (set via the GUI or `sc config` with `start= delayed-auto`) causes the service to start 2 minutes after the last automatic service starts, improving boot time. The SCM uses a thread pool to start delayed services after a timer.
Start the Service
When you run `sc start MyService`, the SCM looks up the service configuration, checks that the start type is not disabled, verifies that all dependencies are running, and then launches the executable specified in `ImagePath`. The SCM passes a command-line argument to the service entry point that includes the service name. The service must call `StartServiceCtrlDispatcher()` within 30 seconds, or the SCM considers it failed. Once connected, the service sets its status to `SERVICE_RUNNING`. The SCM updates its internal state and logs an event.
Manage Service Dependencies
If Service A depends on Service B, the SCM will not start A until B is running. This is configured via the `DependOnService` registry value (a multi-string list of service names). For example, `sc config MyService depend= MyDependency`. The SCM checks dependencies recursively. If a dependency fails to start, the dependent service fails with error 1058 (service cannot be started because it is disabled or has no enabled devices associated). The SCM logs an event detailing which dependency failed. You can view dependencies with `sc enumdepend MyDependency` to see which services depend on it.
Configure Recovery Options
When a service fails (exits with an error or crashes), the SCM can perform actions based on the `FailureActions` registry value. For example, `sc failure MyService reset= 86400 actions= restart/5000/restart/10000/reboot/60000` means: on first failure, wait 5 seconds then restart the service; on second failure, wait 10 seconds then restart; on subsequent failures, wait 60 seconds then reboot the computer. The reset period (86400 seconds = 1 day) means that if the service runs successfully for 24 hours, the failure count resets to zero. The SCM uses a timer to wait before executing the action. If the service fails again while the action is pending, the SCM escalates to the next action.
In a large enterprise with thousands of Windows servers, services management is critical for security and reliability. One common scenario is managing the Windows Update service (wuauserv). Many organizations disable this service on domain controllers to prevent automatic updates that could disrupt operations. Instead, they use a WSUS server and push updates via Group Policy. The service is set to disabled and the SCM prevents any attempt to start it. However, if a technician accidentally enables it, the SCM will start it at next boot, potentially causing unexpected reboots. To prevent this, Group Policy can enforce the service startup mode via the 'System Services' policy under Computer Configuration > Windows Settings > Security Settings > System Services.
Another scenario involves custom in-house applications that run as services. For example, a payroll processing service must run under a specific domain account with access to a SQL database. The service runs on a dedicated server. The administrator creates the service using sc create PayrollService binPath= "C:\Payroll\payroll.exe" obj= "DOMAIN\svc_payroll" password= "P@ssw0rd". The service is set to auto start and depends on the SQL Server service (MSSQLSERVER). If the SQL service fails, the PayrollService will not start, preventing data corruption. The administrator also configures recovery: if the service fails, restart it after 10 seconds, up to three times, then run a script to alert the team. Performance considerations: the service process may consume significant CPU during payroll runs. The administrator monitors it using Performance Monitor counters for the process and sets an alert if CPU exceeds 80% for more than 5 minutes.
A third scenario is managing the Print Spooler service (Spooler). In a print server environment, the Spooler service must be running to accept print jobs. If it crashes, users cannot print. The administrator sets recovery to restart the service immediately on first and second failures, and then run a script that sends an email to the help desk. The service runs under LocalSystem but the printer drivers may require additional permissions. Misconfiguration: if the service is set to disabled by a security policy (some organizations disable it to prevent print server vulnerabilities), users will get 'Printer not available' errors. Troubleshooting involves checking the service status with sc query Spooler and reviewing the System event log for error messages like 'The Print Spooler service terminated unexpectedly.'
The CompTIA A+ 220-1102 exam tests Windows Services Management under Objective 1.2: 'Given a scenario, manage and configure Windows services.' Specific sub-objectives include: start types (automatic, automatic delayed, manual, disabled), service status (running, stopped, paused), dependencies, recovery options (restart service, run a program, restart computer), and service accounts (LocalSystem, LocalService, NetworkService).
Common wrong answers and why candidates choose them:
Confusing 'Automatic' with 'Automatic (Delayed Start)': Candidates often think delayed start starts the service immediately after boot. In reality, delayed start waits 2 minutes after the last automatic service starts. The exam may ask which start type to use to improve boot time – the correct answer is 'Automatic (Delayed Start)'.
Assuming all services run under LocalSystem: Many candidates assume services run as the logged-on user. The exam tests that services run under special accounts. A question might ask: 'Which account should a service use if it needs network access but minimal local privileges?' The answer is NetworkService, not LocalService (which has no network access) or LocalSystem (too privileged).
Misunderstanding recovery actions: Candidates may think 'Restart the Service' is the default for all failures. Actually, the default is 'Take No Action'. The exam may present a scenario where a service crashes repeatedly and ask what to configure to automatically restart it. The correct answer is to set failure actions, not to change the start type.
Overlooking dependencies: A question might describe a service that fails to start with error 1058. Many candidates think it's disabled, but the error also occurs if a dependency is not running. The exam expects you to check dependencies using sc enumdepend or the Services console.
Specific numbers and terms that appear verbatim: the 30-second timeout for a service to respond to a start command, the 2-minute delay for delayed start, the 86400-second (1-day) reset period for failure count, and the sc command syntax (note the space after = in start= auto).
Edge cases: The exam may test that a service can be paused (SERVICE_PAUSED) but not all services support pause. Also, services can be shared or own process. A service failure that causes a reboot will affect all services.
How to eliminate wrong answers: Use the underlying mechanism. If a service fails to start, check if it is disabled (start type), if dependencies are running, and if the service account has proper permissions. For recovery, remember the sequence: first, second, subsequent failures each have a configurable action. The reset period is key to determining when the failure count resets.
Windows Services run in the background without user interaction, managed by the Service Control Manager (SCM).
The four start types are: Automatic, Automatic (Delayed Start), Manual, and Disabled.
Delayed start waits 2 minutes after the last automatic service starts to improve boot performance.
Services run under LocalSystem, LocalService, NetworkService, or a domain account – never under the logged-on user account.
Default recovery action on failure is 'Take No Action'; you must configure actions to restart the service or computer.
The reset period for failure count defaults to 86400 seconds (1 day).
Use `sc config <service> start= <type>` to change start type; note the space after `=`.
A service fails to start if its dependencies are not running (error 1058).
The SCM expects a service to call StartServiceCtrlDispatcher() within 30 seconds of starting.
Services can be paused (if they support it), but pausing is rarely used.
These come up on the exam all the time. Here's how to tell them apart.
sc.exe (Service Control)
Command-line tool, suitable for scripting and remote management.
Can create, delete, configure, start, stop, and query services.
Supports all service configuration options including recovery and dependencies.
Requires knowledge of command syntax (e.g., space after `=`).
Can be used on remote computers with `\\servername` parameter.
services.msc (Services Console)
Graphical interface, easier for beginners.
Shows all services with status, start type, and log on account.
Allows configuration of most settings via property dialogs.
Cannot create or delete services directly (must use sc or PowerShell).
Limited remote management (can connect to another computer but not as flexible).
Mistake
All Windows services run under the LocalSystem account.
Correct
Services can run under LocalSystem, LocalService, NetworkService, or a specified user account. LocalService has fewer privileges, NetworkService can access network resources as the computer account, and a user account is used for services that need specific domain permissions.
Mistake
Setting a service to 'Automatic' means it starts immediately when the user logs in.
Correct
Automatic services start during system boot, before the user logs in. The SCM starts them after the boot loader and kernel initialization, based on dependencies and group order. The user login occurs later.
Mistake
If a service crashes, Windows will automatically restart it by default.
Correct
The default recovery action is 'Take No Action'. The service remains stopped until manually started or until the system is rebooted. You must configure recovery options to automatically restart the service.
Mistake
The 'sc config' command requires the service to be stopped.
Correct
You can change service configuration (start type, account, etc.) while the service is running. The changes take effect the next time the service starts. However, you cannot delete a service while it is running.
Mistake
A service that is disabled cannot be started by any means.
Correct
A disabled service cannot be started by the SCM or any service dependency. However, an administrator can change the start type to manual or automatic and then start it. Disabled is a configuration, not a permanent state.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Open the Services console (services.msc), right-click the service, select Properties, and set Startup type to 'Automatic'. Click Apply and OK. Alternatively, use the command line: `sc config ServiceName start= auto` (note the space after `=`). The change takes effect after the service is started or the system reboots.
LocalService (NT AUTHORITY\LOCAL SERVICE) has minimal privileges on the local computer and no network access as a user. NetworkService (NT AUTHORITY\NETWORK SERVICE) also has limited local privileges but can access network resources using the computer's domain identity. Use NetworkService for services that need to connect to network shares or databases.
Configure recovery options. In services.msc, go to the Recovery tab. Set first, second, and subsequent failures to 'Restart the Service'. You can also set a reset period (default 1 day). Using command line: `sc failure ServiceName reset= 86400 actions= restart/5000/restart/10000/reboot/60000` (this restarts on first two failures and reboots on subsequent failures).
Error 1058 means 'The service cannot be started because it is disabled or has no enabled devices associated with it.' This usually indicates the service start type is set to Disabled. Check with `sc query ServiceName` and look at the START_TYPE. If it is DISABLED, change it to AUTO or DEMAND using `sc config ServiceName start= auto`. Also, ensure all dependencies are running.
Yes. In services.msc, on the Log On tab, select 'This account' and enter the domain user credentials. Alternatively, use `sc config ServiceName obj= "DOMAIN\username" password= "password"`. The account must have the 'Log on as a service' right (SeServiceLogonRight), which can be granted via Local Security Policy or Group Policy.
This start type delays the service start until 2 minutes after the last automatic service starts. It improves boot time by allowing critical services to start first and reducing competition for resources. It is commonly used for non-essential services like Windows Update or BITS.
In services.msc, right-click the service and select Properties, then go to the Dependencies tab. It shows services that must run before this service (dependencies) and services that depend on this service (dependent services). Command line: `sc enumdepend ServiceName` lists services that depend on the specified service.
You've just covered Windows Services Management — now see how well it sticks with free 220-1102 practice questions. Full explanations included, no account needed.
Done with this chapter?