Windows Server 2025 SCM Service Fails to Start at Boot — Fix & Prevention

📖 ~3 min read

Table of contents

1. Symptom & Impact
2. Environment & Reproduction
3. Root Cause Analysis
4. Quick Triage
5. Step-by-Step Diagnosis
6. Solution — Primary Fix
7. Solution — Alternative Approaches
8. Verification & Acceptance Criteria
9. Rollback Plan
10. Prevention & Hardening
11. Related Errors & Cross-Refs
12. References & Further Reading

Symptom & Impact

After rebooting Windows Server 2025, one or more critical services managed by the Service Control Manager (SCM) fail to start automatically. This may manifest as application errors, missing network connectivity (if TCPIP or DHCP Client fails), or database connection failures (if SQL Server or a dependent service is stopped). Event Viewer logs Event IDs 7000 (service failed to start), 7001 (dependent service failed), 7022 (service hung), or 7023 (service terminated with error). Unlike a complete boot failure, the server appears to start normally but the services are silently failed, causing downstream application errors that may take minutes to hours to be noticed by monitoring systems.

Environment & Reproduction

Reproducible on Windows Server 2025 in any of these scenarios: (1) Service executable or DLL is missing or corrupted after an update. (2) Service account password changed but the service was not updated. (3) Service dependency chain includes a service set to Manual that is not started. (4) Registry permissions on HKLMSYSTEMCurrentControlSetServices{ServiceName} were modified.

# Check failed services and their error codes
Get-EventLog -LogName System -Source 'Service Control Manager' -EntryType Error -Newest 20
Get-Service | Where-Object {$_.Status -ne 'Running' -and $_.StartType -eq 'Automatic'}
sc query type= all state= inactive

Root Cause Analysis

The SCM logs an exit code for every failed service start. Code 1069 means logon failure (wrong service account password). Code 1053 means the service did not respond to start request in time (hung). Code 2 means the system cannot find the specified file (missing executable). The dependency chain is the most common overlooked cause: if Service A depends on Service B and B is set to Manual, A will fail on boot with Event ID 7001 even though A’s own executable is healthy.

Quick Triage

Five quick checks to narrow down the SCM service failure root cause in under two minutes.

# Five quick triage checks
# 1. What services are not running?
Get-Service | Where-Object {$_.Status -ne 'Running' -and $_.StartType -eq 'Automatic'} | Select Name,Status,DisplayName
# 2. What error code did they fail with?
sc query {ServiceName}
# 3. Check dependencies
Get-Service {ServiceName} | Select -ExpandProperty ServicesDependedOn
# 4. Does the service executable exist?
(Get-ItemProperty 'HKLM:SYSTEMCurrentControlSetServices{ServiceName}').ImagePath
# 5. Recent SCM errors
Get-EventLog -LogName System -Source 'Service Control Manager' -Newest 5

Step-by-Step Diagnosis

Run the triage commands above. Record the error code from `sc query`. Check Event Viewer → Windows Logs → System, filter Source = Service Control Manager. Look for the sequence: Event 7001 (dependency) before Event 7000 (service itself). If 7001 appears first, fix the dependency service first. If error code is 1069, the service account password is the cause.

# Full SCM error investigation
Get-WinEvent -FilterHashtable @{LogName='System';ProviderName='Service Control Manager'} | Select TimeCreated,Id,Message | Format-List
sc qc {ServiceName}   # Shows service config including dependencies
net helpmsg 1069       # Decode error code

Solution — Primary Fix

The fix depends on the error code. For logon failure (1069): update service account password in Services.msc. For missing executable (2): reinstall or repair the affected application. For dependency failure: ensure all dependencies are set to Automatic and start them. For hung service (1053): increase the service startup timeout in the registry.

# Fix logon failure: update service credential
$cred = Get-Credential
$service = Get-WmiObject Win32_Service -Filter "Name='ServiceName'"
$service.Change($null,$null,$null,$null,$null,$null,$cred.UserName,$cred.GetNetworkCredential().Password)

# Fix dependency: set to Auto
Set-Service -Name DependencyServiceName -StartupType Automatic
Start-Service DependencyServiceName
Start-Service ServiceName

# Fix timeout (increase SCM wait from 30s to 60s)
Set-ItemProperty -Path 'HKLM:SYSTEMCurrentControlSetControl' -Name 'ServicesPipeTimeout' -Value 120000 -Type DWord

Solution — Alternative Approaches

Alternative 1: Use sc.exe for granular control when PowerShell Set-Service is insufficient. Alternative 2: Dependency Walker — use the deprecated but still functional Dependency Walker tool to trace DLL loading failures. Alternative 3: Enable service failure actions (restart on first/second failure) via Services.msc → Recovery tab to auto-recover after transient failures.

sc config ServiceName start= auto
sc failure ServiceName reset= 86400 actions= restart/5000/restart/10000/restart/30000
sc start ServiceName

Verification & Acceptance Criteria

All automatic services running. Event Viewer shows no 7000/7001/7022/7023 events after reboot. Application health checks (if any) report green. Monitor for 15 minutes post-boot to confirm no delayed failures.

# Verify
Get-Service | Where-Object {$_.Status -ne 'Running' -and $_.StartType -eq 'Automatic'}
Get-EventLog -LogName System -Source 'Service Control Manager' -EntryType Error -After (Get-Date).AddMinutes(-30)

Rollback Plan

Revert by reverting service account credentials or re-setting dependency startup types to their original values. If the service timeout was increased, revert ServicesPipeTimeout to the default (30000ms = 30s) once the underlying cause is resolved.

# Rollback service timeout
Set-ItemProperty -Path 'HKLM:SYSTEMCurrentControlSetControl' -Name 'ServicesPipeTimeout' -Value 30000 -Type DWord
# Rollback auto-start for any service you changed
Set-Service -Name ServiceName -StartupType Manual

Prevention & Hardening

Create a Desired State Configuration or Group Policy to enforce critical service startup types. Use Windows Server 2025 health attestation or a monitoring agent to alert on any Automatic service that stops. Implement service failure recovery actions for all business-critical services via Services.msc Recovery tab.

# DSC to enforce service state
Configuration CriticalServices {
    Node localhost {
        Service SQLServer {
            Name = 'MSSQLSERVER'; State = 'Running'; StartupType = 'Automatic'
        }
        Service W32Time {
            Name = 'W32Time'; State = 'Running'; StartupType = 'Automatic'
        }
    }
}

Related Errors & Cross-Refs

Related: Windows Server 2025 hung at ‘Applying Group Policy’ on boot (GPO dependency issue), Event ID 41 Kernel-Power after unexpected shutdown affecting service start state, COM+ component failure causing dependent services to fail. See also the post on Active Directory replication failure which often presents as SCM errors for Netlogon.

View all Windows Server 2025 tutorials on the Tutorials Hub →

Browse all common problems & solutions on the Tutorials Hub.

References & Further Reading

Microsoft KB4090913 covers a known SCM race condition on multi-core systems during boot. TechNet article ‘Service fails to start with error 1069’ at support.microsoft.com. Windows Service Internals documentation in ‘Windows Internals’ by Russinovich, Solomon, and Ionescu. Sysinternals Autoruns documents all boot-time startup mechanisms including services.