A windows server service failure usually starts the same way: the event log shows Error 1075, you run net start lanmanserver and get “The dependency service does not exist or has been marked for deletion.” Services.msc shows the Server service as stopped, but the dependency list looks fine at first glance.
Windows server service failures are not rare edge cases. Dependency chain corruption is one of the most common patterns – and one of the most misdiagnosed. Most content on this topic shows you how to click through the Services GUI. This article covers what actually breaks, how to read it, and how to fix it without a reboot.
- Error 1075 = broken dependency chain. Fix with
sc config <service> depend=before restarting. - Error 1053 = service did not respond in time. Check the Application event log for the real error from the service itself.
- Error 1067 = service process terminated unexpectedly. Application log or service-specific log has the detail.
sc queryexshows current state, PID, and exit code – always run this before anything else.- SCM recovery actions do not fire if the service never starts – they only trigger on unexpected exits after startup.
- “Log on as a service” right missing = service fails silently. Check Local Security Policy if the account changed.
Why Windows Server Service Failures Happen: The Four Categories
Before running commands, categorize the windows server service failure. This determines which tool gives you useful information.
Category 1 – Dependency chain broken. The service depends on another service that is not running or does not exist. Produces Error 1075 or “dependency service does not exist.” This is a configuration problem, not a runtime problem.
Category 2 – Service process crashes on start. The service binary starts, then exits with a non-zero code before completing initialization. Produces Error 1067 or Error 1053. The Application event log has the real cause.
Category 3 – Account or permission failure. The service account does not have the “Log on as a service” right, or the account password changed without updating the service. Produces Event ID 7000 with a logon failure sub-status.
Category 4 – Resource or environment failure. Missing DLL, missing registry key, corrupted service binary, full disk. Varies – the service’s own log or the Application event log has the detail.
Knowing the category before you start saves 20 minutes of guessing.
What Changed? Start Here Before Diagnosing Windows Server Service Failures
Most windows server service failures do not happen randomly. They happen after something changed. Before running a single diagnostic command, ask:
- Was a Windows Update installed in the last 24-48 hours?
- Was software installed or uninstalled?
- Did a GPO apply or change?
- Was a service account password rotated?
- Was security hardening applied (CIS benchmarks, STIG, custom policy)?
- Did an application upgrade run?
If you can identify the change, you can often skip the full diagnostic tree and go directly to the relevant fix. A service that stopped working the morning after Patch Tuesday is almost certainly a Windows Update regression or a dependent component that got modified. A service that failed after a security team hardening session is likely a “Log on as a service” right being stripped from the service account.
If nothing changed – or you do not know what changed – proceed with the diagnostic sequence below.
First Stop: sc queryex
Before opening Services.msc or rebooting, run this on the server:
sc queryex <servicename>Output shows:
SERVICE_NAME: lanmanserver
TYPE : 20 WIN32_SHARE_PROCESS
STATE : 1 STOPPED
WIN32_EXIT_CODE : 1075 (0x433)
SERVICE_EXIT_CODE : 0 (0x0)
CHECKPOINT : 0x0
WAIT_HINT : 0x0
PID : 0
FLAGS :WIN32_EXIT_CODE is the key field. Common exit codes and what they mean for windows server service failures:
| Exit code (hex) | Decimal | Meaning |
|---|---|---|
| 0x0 | 0 | Service stopped cleanly or never started |
| 0x2 | 2 | File not found – service binary missing or path wrong |
| 0xC1 | 193 | Invalid executable format – wrong architecture or corrupted binary |
| 0x422 | 1058 | Service is disabled |
| 0x425 | 1061 | Service cannot accept control at this time |
| 0x42A | 1066 | Service-specific error (check SERVICE_EXIT_CODE) |
| 0x42B | 1067 | Service process terminated unexpectedly |
| 0x42C | 1068 | Dependency service or group failed to start |
| 0x420 | 1056 | An instance is already running |
| 0x433 | 1075 | Dependency service missing or deleted |
| 0x435 | 1077 | No recovery actions configured for this service |
| 0x41D | 1053 | Service did not respond to control request in time |
If WIN32_EXIT_CODE is 1066 (service-specific error), the SERVICE_EXIT_CODE field has the meaningful number – most diagnostic workflows stop at 1066 without reading the second field.
Also pull System event log immediately after sc queryex. Per Microsoft’s sc query documentation, exit codes map directly to Win32 error codes:
Get-WinEvent -LogName System -MaxEvents 20 | Where-Object {$_.Id -in 7000,7001,7009,7031,7034,7038} | Select-Object TimeCreated, Id, Message | Format-ListOr with a filter hashtable for cleaner output:
Get-WinEvent -FilterHashtable @{
LogName = 'System'
Id = 7000,7001,7009,7031,7034,7038
} | Select-Object TimeCreated, Id, Message | Format-ListDependency Chain Failures (Error 1075)
Error 1075 is one of the most common windows server service failures. It means the SCM tried to start a dependency that no longer exists in the services database. This happens after a botched software uninstall, a manual sc delete on the wrong service, a Group Policy change that removed a service registration, or a failed Windows Update that partially rolled back.
The documented case: lanmanserver (Server service) fails with Error 1075 because its dependency on Srv – a kernel driver – was removed or corrupted. The default dependency string for lanmanserver is SamSs/Srv2/MRxSmb20/NSI, but in the corrupted state it points to Srv which no longer exists as a registered service.
- Verify the current dependency string:
sc qc lanmanserver– look for the DEPENDENCIES line. - For each listed dependency, confirm it exists:
sc query <dependency-name>. Missing = the problem. - Repair the dependency string:
sc config lanmanserver depend= SamSs/Srv2/MRxSmb20/NSI– note the space afterdepend=, required syntax. - Start the service:
net start lanmanserver - Verify:
sc queryex lanmanserver– STATE should show RUNNING.
For any Error 1075 windows server service failure on any service: find the missing dependency in the sc qc output, either restore it or remove it from the depend string with sc config <service> depend= <corrected-list>.
Registry Paths: Validating Service Configuration Directly
When sc qc output looks suspicious or you want to validate what the SCM is actually reading, go to the source. Service configuration is stored in:
HKLM\SYSTEM\CurrentControlSet\Services\<ServiceName>Key values to check:
| Registry value | Type | What it controls |
|---|---|---|
| DependOnService | REG_MULTI_SZ | Service names this service depends on (one per line) |
| DependOnGroup | REG_MULTI_SZ | Service group dependencies |
| ImagePath | REG_EXPAND_SZ | Full path to the service binary |
| ObjectName | REG_SZ | Service account (LocalSystem, NT AUTHORITY\NetworkService, or domain\account) |
| Start | REG_DWORD | 0=Boot, 1=System, 2=Auto, 3=Manual, 4=Disabled |
If ImagePath points to a path that does not exist, you will get exit code 0x2 (file not found). If DependOnService contains a service name that is not registered under HKLM\SYSTEM\CurrentControlSet\Services\, you get Error 1075 – even if something with a similar display name appears in Services.msc.
Broken Dependency Chains: Reading the Tree
Some windows server service failures involve multi-level dependency chains. Service A depends on Service B, which depends on Service C. If C is missing, both B and A fail – but Event ID 7001 only shows the immediate dependency failure. Walk the full chain.
function Get-ServiceDependencyTree {
param([string]$ServiceName, [int]$Depth = 0)
$svc = Get-Service -Name $ServiceName -ErrorAction SilentlyContinue
if (-not $svc) {
Write-Host (" " * $Depth + "MISSING: $ServiceName") -ForegroundColor Red
return
}
Write-Host (" " * $Depth + "$($svc.Name) [$($svc.Status)]")
foreach ($dep in $svc.ServicesDependedOn) {
Get-ServiceDependencyTree -ServiceName $dep.Name -Depth ($Depth + 2)
}
}
Get-ServiceDependencyTree -ServiceName "lanmanserver"Missing services print in red. Run this before manually walking the dependency list – it finds the broken link in seconds on complex chains.
Service Process Crashes (Error 1067 / Error 1053)
Error 1067 means the service binary started, ran briefly, and exited with a non-zero code. Error 1053 means the service started but did not complete initialization within the timeout window. Both produce windows server service failures that look the same from the outside.
The SCM exit code is not the real error. The real error is in the Application event log, logged by the service itself before it died. Per Microsoft’s wevtutil documentation, you can query the Application log directly:
Get-WinEvent -LogName Application -MaxEvents 50 |
Where-Object { $_.LevelDisplayName -eq "Error" } |
Select-Object TimeCreated, ProviderName, Id, Message |
Format-ListFilter by the service name in ProviderName, or look for events timestamped within seconds of the SCM failure event.
Common patterns and their fixes:
- Missing DLL: event message contains “failed to load” or “module not found” – reinstall the component that owns that DLL.
- Corrupted binary: run
sfc /scannow, thenDISM /Online /Cleanup-Image /RestoreHealthif SFC reports errors it could not fix. - Database not ready (SQL-dependent services): the service is starting before SQL Server finishes initialization – add an explicit dependency on the SQL service or increase the startup delay.
- Configuration file missing: service-specific – check
%ProgramData%and%SystemRoot%\Logsfor the service’s own log directory.
For Error 1053 specifically: the process is still running but blocked waiting for something. Check the Application log for what it is waiting on before killing the process.
A service configured to connect to a network share or database during startup will fail with Error 1053 if the target is not reachable at boot time – even if it becomes reachable seconds later. The SCM timeout is 30 seconds by default. Services that need network resources during initialization should implement retry logic or use a delayed auto-start type (sc config <service> start= delayed-auto) to give the network stack time to initialize first.
Account and Permission Failures (Event ID 7038)
When the service account changes – or the account password expires – the windows server service failure produces Event ID 7038. Two distinct problems cause similar symptoms.
Problem 1: Password changed, service still has the old password.
# Update service password via PowerShell
$svc = Get-WmiObject Win32_Service -Filter "Name='<servicename>'"
$svc.Change($null,$null,$null,$null,$null,$null,"domain\account","NewPassword")Problem 2: Account missing “Log on as a service” right. This happens after account changes, Group Policy changes, or security hardening that modifies User Rights Assignments.
Check current assignments:
secedit /export /cfg C:\temp\secconfig.inf
findstr /i "SeServiceLogonRight" C:\temp\secconfig.infIf the account is not listed, add it via secpol.msc – Local Policies – User Rights Assignment – Log on as a service.
If a GPO controls “Log on as a service” in Replace mode, adding the account locally is overwritten at the next Group Policy refresh (every 90-120 minutes by default). The windows server service failure returns, and the fix appears to have reverted. The actual fix is in the GPO, not on the server. Run gpresult /r and look for policies targeting User Rights Assignment before making local changes.
SCM Recovery Actions: What They Actually Do
The Recovery tab in Services.msc (or sc failure) configures what the SCM does when a service exits unexpectedly. Understanding the exact trigger condition matters for diagnosing windows server service failures correctly.
Recovery actions only fire when the service exits unexpectedly after startup is complete. If the service fails to start at all (Error 1053, Error 1067), recovery actions do not run. Fix the startup failure first.
Per Microsoft’s sc failure documentation, the recommended recovery configuration for critical services:
| Failure | Action | Delay |
|---|---|---|
| First failure | Restart the Service | 60,000 ms (60 sec) |
| Second failure | Restart the Service | 120,000 ms (2 min) |
| Subsequent failures | Reboot the Computer | 60,000 ms after reboot timer |
| Reset fail count after | – | 300 seconds |
Set via command line (space after reset= and actions= is required):
sc failure <servicename> reset= 300 actions= restart/60000/restart/120000/reboot/60000View current settings:
sc qfailure <servicename>To enable recovery actions even when the service exits with code 0:
sc failureflag <servicename> 1Use PowerShell with sc.exe explicitly (the sc alias in PowerShell maps to Set-Content, not the service control tool):
sc.exe failure Spooler reset= 300 actions= restart/60000/restart/120000/reboot/60000
sc.exe qfailure SpoolerHung Services: When Stop Won’t Work
A service stuck in “Stopping” state is a different type of windows server service failure from one that won’t start. The process is running but not responding to SCM control messages.
- Get the PID:
sc queryex <servicename>– note the PID value. - Check what it’s doing:
tasklist /svc /fi "PID eq <PID>" - Check the Application event log for errors from that service at the current timestamp.
- If hung with no recovery path, force-kill:
taskkill /PID <PID> /F - After killing, the SCM marks the service stopped. Verify:
sc queryex <servicename> - Investigate why it hung before restarting – killing the process clears the symptom, not the cause.
A service stuck in “Starting” state (not “Stopping”) is the Error 1053 scenario – it started but never completed initialization. Same approach: get the PID, check what it is waiting on, kill if necessary.
Full Diagnostic Sequence for Windows Server Service Failures
When a windows server service failure occurs and you do not know why, follow this order:
- Identify recent changes – Windows Update, software install, GPO change, account password rotation, hardening script.
sc queryex <servicename>– get the exit code, confirm the service is actually stopped.- System event log – filter for Event IDs 7000, 7001, 7009, 7034, 7038 at the failure timestamp.
- Application event log – filter for errors from the service name or related component at the same timestamp.
sc qc <servicename>– verify dependency list, start type, service binary path (ImagePath).- Verify each dependency –
sc query <dependency>for every service listed in DEPENDENCIES. - Verify service account – confirm “Log on as a service” right if the service runs under a custom account.
- Verify the binary – if ImagePath points to something that does not exist, reinstall the component.
Key Event IDs for Windows Server Service Failures
| Event ID | Source | Meaning |
|---|---|---|
| 7000 | Service Control Manager | Service failed to start |
| 7001 | Service Control Manager | Service start failed due to dependency failure |
| 7009 | Service Control Manager | Service did not respond within timeout (Error 1053) |
| 7011 | Service Control Manager | Service did not respond to control request (hung) |
| 7023 | Service Control Manager | Service terminated with error |
| 7031 | Service Control Manager | Service terminated unexpectedly – recovery actions fired |
| 7034 | Service Control Manager | Service terminated unexpectedly – no recovery configured |
| 7038 | Service Control Manager | Service account logon failure |
| 7040 | Service Control Manager | Start type changed |
| 7045 | Service Control Manager | New service installed |
Events 7031 and 7034 are post-mortem – they appear after the crash. The actual cause is in the Application log or service-specific log at the same timestamp. For more on filtering event logs efficiently, see the Windows Server Event Log Troubleshooting guide.
Common Mistakes
Rebooting instead of diagnosing. A reboot clears the event log context and restarts all services, which can hide the root cause if the windows server service failure was a transient condition. Always capture sc queryex output and event log entries before rebooting.
Fixing the wrong service. Event ID 7001 points to the service that failed due to a dependency problem, not the dependency that caused the failure. Walk the dependency chain to find what actually broke.
Changing the service account in Services.msc without checking GPO. If a GPO controls the service logon account, your manual change is overwritten on the next refresh. Check gpresult /r for policies targeting service accounts before making local changes.
Setting recovery actions and calling it done. Recovery actions restart a service that crashes during operation. They do nothing for a service that fails to start. Fix the startup failure – recovery actions handle runtime crashes, not initialization failures.
Using sc in PowerShell instead of sc.exe. In PowerShell, sc is an alias for Set-Content. Always use sc.exe explicitly when running service control commands from a PowerShell session.
Missing SERVICE_EXIT_CODE when WIN32_EXIT_CODE is 1066. Exit code 1066 means a service-specific error – the real code is in the SERVICE_EXIT_CODE field, not WIN32_EXIT_CODE. Most diagnostic workflows stop at 1066 without reading the second field.
Frequently Asked Questions
Why does net start give Error 1075 but Services.msc shows the dependency as present?
Services.msc shows services that are registered, including disabled ones and those marked for deletion. For windows server service failures caused by Error 1075, the SCM checks the dependency string stored in HKLM\SYSTEM\CurrentControlSet\Services\<name>\DependOnService. If that string contains a service name not present in the registry at all, you get Error 1075 even if something with a similar display name appears in Services.msc. Run sc query <dependency-name> to confirm the dependency actually exists as a registered service.
What is the difference between Error 1067 and Error 1053 in windows server service failures?
Error 1067 (process terminated unexpectedly) means the binary ran and exited with a non-zero code before or after registering with the SCM. Error 1053 (service did not respond in time) means the process is still running but has not called SetServiceStatus to report initialization complete within the timeout. With Error 1053, the process is alive and waiting on something – check the Application log before killing it.
Can I change a service’s dependencies without restarting the service?
sc config <service> depend= <new-list> updates the registry immediately, but takes effect only on the next service start. If the service is currently running with a broken dependency string, you do not need to restart it now – just fix the string so the next startup works. This is the correct approach for most windows server service failures caused by Error 1075.
Recovery actions are configured but the service stays down after a crash. Why?
Three common reasons for this type of windows server service failure: (1) the service failed to start – recovery actions only fire for post-startup crashes; (2) sc failureflag is not set and the service is exiting with code 0; (3) the failure count is past the “subsequent failures” threshold with a reboot action that is being suppressed (common in VMs). Check sc qfailure <service> to see the current failure count and configured actions. Also check if the System event log shows Event ID 7031 – if that event is present, the SCM did attempt recovery.
How do I find the service name from Services.msc’s display name?
Get-Service -DisplayName "Print Spooler" | Select-Object Name returns the short name. Or look in Services.msc Properties – the service name appears on the General tab below the display name. Event logs and sc commands always use the short name, not the display name.
What happens if a service has no dependencies configured but still fails to start?
Then it is not a dependency issue – it is Category 2, 3, or 4. Check the Application event log immediately after the windows server service failure. The SCM logs Event ID 7000, but the service binary itself usually logs the actual cause in the Application log or in a service-specific log under %ProgramData% or %SystemRoot%\Logs. When troubleshooting RDP or WinRM service failures specifically, the RDP and WinRM recovery guide covers those service failure modes in detail.
Windows Server Operations Series
8 articles — Event Logs · Performance · Services · Remote Access · Network · Storage · Backup · Boot Recovery