Windows Server Service Failures: Service Control Manager Errors & Error 1067

A Service Control Manager error on Windows Server means SCM observed a service fail to start, stop unexpectedly, time out, or encounter a dependency or account-related failure. It often does not contain the underlying application cause. Start with sc.exe queryex, then correlate the exit code with the Service Control Manager event and the Application or service-specific log. If you’re looking at Error 1067 or Event ID 7023 specifically, the SCM message identifies the failure state, but the underlying cause usually comes from the service or application itself.

This guide covers the full diagnostic workflow: Service Control Manager error correlation, Error 1067, Event ID 7023, dependency failures (Error 1068 and Error 1075), Error 1053, service account failures, hung services, and what recovery actions actually do. The lanmanserver / Error 1075 case shows up later as a worked example, not as the whole article.

Diagnose the Service Before Changing Anything

Categorize the failure before running commands. The category determines which tool actually gives you useful information.

Category 1 – Dependency or configuration failure. A configured dependency is missing or marked for deletion (Error 1075), or a required dependency exists but fails to start (Error 1068). These are different failure states and should be distinguished before editing the dependency list.

Category 2 – Service process or startup failure. The service process terminates unexpectedly, or it fails to respond to a start/control request in time. These conditions commonly surface as Error 1067 or Error 1053. The Application log or service-specific log usually provides the underlying cause.

Category 3 – Account or permissions failure. The service account lacks the “Log on as a service” right, or its password changed without the service being updated. These conditions can produce Event ID 7038.

Category 4 – Environment or application dependency failure. Missing DLL, missing registry key, corrupted binary, full disk. The service’s own log or the Application log has the detail.

These four categories cover most Windows Server service failures, though not every case. Some failures span more than one category, such as a dependency that itself fails to start because of a permissions problem. Identifying the likely category before running the first command narrows the diagnostic path considerably.

First Diagnostic Command: sc.exe queryex

Before opening Services.msc or rebooting, run this on the server:

Output shows:

WIN32_EXIT_CODE is the key field. Exit codes and what they mean, per Microsoft’s System Error Codes (1000-1299) reference:

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.

Service Control Manager Error: Correlate the Failure With Event Logs

A Service Control Manager event tells you how Windows observed the service failure. It often does not contain the underlying application cause. Use the SCM event, sc.exe queryex, and the Application or service-specific log together; none of the three tells the whole story on its own.

• sc.exe queryex – current service state and exit code
• System log – records Service Control Manager events for that service
• Application log (or the service’s own log) – usually has the application-level detail behind the SCM-level error

Pull the System log for the relevant Service Control Manager events, scoped to a specific time window rather than an arbitrary event count:

Adjust StartTime to the incident window. This is not a substitute for a full Event Viewer workflow. For filtering logs broadly, custom views, or retention and export, see Windows Server Event Log Troubleshooting. This section only covers correlating a specific service failure with the SCM events it produces.

Check What Changed

Most service failures follow a change rather than appearing at random. Before going further into a specific error below, check whether:

• a Windows Update installed in the last 24-48 hours
• software was installed or uninstalled
• a GPO applied or changed
• a service account password was rotated
• security hardening was applied (CIS benchmarks, STIG, a custom policy)
• an application upgrade ran

A recent update or configuration change is a useful correlation point, but confirm the actual failure in Service Control Manager and application logs before rolling anything back. A change around the same time is a lead, not a diagnosis. The same caution applies to hardening work: do not assume a hardening session removed “Log on as a service” from the account; verify the resultant policy before assuming.

If nothing changed, or the change is unknown, work through the exact error below instead.

Error 1067: The Process Terminated Unexpectedly

Error 1067 means the service process started or attempted to start, then terminated unexpectedly. Service Control Manager reports the termination, but the underlying reason usually appears in the Application log, a service-specific log, executable exit details, or application configuration. Error 1067 by itself does not identify which of those it is.

Diagnostic sequence:

1. Run sc.exe queryex <service> and capture WIN32_EXIT_CODE and SERVICE_EXIT_CODE.
2. Inspect the Service Control Manager event at the same timestamp.
3. Inspect the Application log or the service’s own log for the same timestamp.
4. Verify ImagePath actually points to a real, correct binary.
5. Verify the service account and its permissions.
6. Verify dependencies are present and started.
7. Verify required files and configuration the service depends on.
8. Only then repair, reinstall, or change configuration.

Common patterns, not an exhaustive list:

• Missing DLL: the event message mentions “failed to load” or “module not found” – reinstall the component that owns that DLL
• Windows component corruption: if the failed service belongs to Windows itself, run sfc /scannow, then DISM /Online /Cleanup-Image /RestoreHealth if SFC reports errors it could not fix. For a third-party service, use that application’s own repair or reinstall procedure instead
• Database not ready (SQL-dependent services): if a service requires SQL Server during initialization, verify the application’s supported startup and dependency design first. A vendor-supported service dependency or a delayed start may be appropriate, but do not add a dependency purely to paper over an initialization problem
• Configuration file missing: service-specific – check %ProgramData% and %SystemRoot%\Logs for the service’s own log directory

Error 1067 does not necessarily mean the process crashed. Termination can occur through more than one code path, and the log correlation above identifies which one.

Service Control Manager Error 7023

Event ID 7023 is logged by Service Control Manager when a service terminates and returns an error. The event message names the service and typically includes or identifies the error associated with the service termination. Treat that exact message as the next diagnostic clue rather than treating 7023 itself as a single root cause; the same event can appear for many unrelated underlying problems across different services.

To troubleshoot an SCM 7023 event:

1. Read the full 7023 event message, not just the event number.
2. Identify the affected service from the message.
3. Capture the current state with sc.exe queryex <service>.
4. Record both WIN32_EXIT_CODE and SERVICE_EXIT_CODE.
5. Correlate with Application or service-specific logs at the same timestamp.
6. Diagnose the specific error the event reported, not a generic “service terminated” summary.
7. Avoid generic registry edits or resets before that specific error is identified.

Event ID 7023 is not tied to one specific Windows service or one universal fix. The same event number can point to a missing dependency, a terminated process, insufficient resources, a bad configuration value, or a third-party application fault, depending on the error reported for that service.

Dependency Failures: Error 1068 and Error 1075

Error 1068 means a dependency service or group failed to start; the dependency is registered and present, but didn’t come up. Error 1075 is more specific: Service Control Manager tried to start a dependency that no longer exists in the services database at all. Error 1075 can follow a botched software uninstall, a manual sc.exe delete on the wrong service, a configuration change that removed a service registration, or an incomplete update or rollback.

The diagnostic workflow is the same regardless of which service is affected:

1. Query the current dependency string: sc.exe qc <service> – look for the DEPENDENCIES line
2. For each listed dependency, confirm it exists: sc.exe query <dependency-name>. Missing means that is the problem
3. Verify the exact service short name; a similar display name in Services.msc does not mean the underlying service is registered
4. Compare the dependency list against Microsoft documentation or a healthy server running the same Windows Server version and build
5. Only then change the dependency list

A worked example: lanmanserver (Server service) failing with Error 1075 because a dependency it expects is missing. The correct dependency list has varied across Windows versions and installed SMB components. Confirm it on a healthy server running the same Windows Server version and build, or against authoritative product documentation, before changing the affected host – do not paste a generic online default and apply it.

For any Error 1075 failure on any service: find the missing dependency in the sc.exe qc output, then either restore the missing service or remove it from the depend string with sc.exe config <service> depend= <corrected-list> – only after confirming the corrected list against documentation or a known-good server.

Registry Paths: Validating Service Configuration Directly

When sc.exe qc output looks suspicious, or you need to confirm what the Service Control Manager is actually reading, check the underlying configuration. Service settings are stored in:

Key values:

If ImagePath points to a path that does not exist, expect exit code 0x2 (file not found). If DependOnService contains a service name that is not registered under HKLM\SYSTEM\CurrentControlSet\Services\, expect Error 1075, even if something with a similar display name appears in Services.msc.

Prefer sc.exe qc or another supported service-management tool for routine inspection and configuration changes. Treat a direct registry edit here as a validation or recovery step, not the normal way to change a service’s configuration.

Walk Multi-Level Dependency Chains

Some dependency failures involve multi-level 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 instead of stopping at the first one:

Missing services print in red. Run this before manually walking the dependency list; it finds the broken link in seconds on complex chains.

Error 1053: The Service Did Not Respond in Time

Error 1053 means the service did not respond to the start or control request within the required time. That is all the error code guarantees. The underlying cause can be an application initialization problem, a dependency or resource wait, an issue in the service’s own implementation, Service Control Manager or configuration-database contention, application-specific configuration, or a system or component failure. Microsoft documents multiple distinct causes for Error 1053, so do not reduce it to a single state such as “the process is alive and just slow.”

Query the Application log directly for what actually happened, scoped to a time window rather than a fixed event count:

Correlate the timestamp and ProviderName with the SCM failure event. Do not assume a universal provider name; different services and third-party applications log under different providers.

Increasing the ServicesPipeTimeout registry value is sometimes suggested as a fix for Error 1053. Treat it as a last-resort, application-specific option, not a default response: it requires a full restart to take effect, and it can mask the underlying cause instead of fixing it. Microsoft’s own troubleshooting guidance for this timeout documents the setting and recommends researching the underlying problem rather than treating the increase as the fix. Check the logs first.

Service Account and Logon Failures: Event ID 7038

When a service account changes, or its password expires, the failure produces Event ID 7038. Two distinct problems cause the same symptom.

Problem 1: the password changed, and the service still has the old one. Identify the account the service runs under first:

Update the credentials through an approved service-management method for the environment – a password or secrets-management process, or a group-managed service account (gMSA) where the service supports one – rather than typing a plaintext password on a command line. This section is about identifying which account and which service are involved, not about the specific credential-rotation tooling in use.

Problem 2: the account is missing the “Log on as a service” right. This happens after account changes, Group Policy changes, or security hardening that touches User Rights Assignments.

Check current assignments:

If the account is not listed, add it via secpol.msc – Local Policies – User Rights Assignment – Log on as a service.

Service Recovery Actions: What SCM Actually Triggers

The Recovery tab in Services.msc (or sc.exe failure) configures what the Service Control Manager does when a service fails. The exact trigger condition is more specific than “the service crashed after it finished starting.”

Recovery actions are triggered by how the service process terminates and reports its final status to SCM, not simply by whether the failure happened before or after startup completed. By default, SCM can queue configured failure actions when the service process terminates without reporting SERVICE_STOPPED. If SERVICE_FAILURE_ACTIONS_FLAG is enabled, SCM can also trigger them when the service reports SERVICE_STOPPED with a non-zero Win32 exit code. A process that crashes during initialization can meet the failure condition even though startup never completed. Recovery configuration still does not replace diagnosing the underlying startup or runtime failure.

Failure actions are ordered. SCM uses the first configured action for the first failure, the second for the second failure, and so on. Per Microsoft’s SERVICE_FAILURE_ACTIONS documentation, if the number of failures exceeds the number of configured actions, SCM repeats the last configured action until the failure count resets. Design the sequence for the workload rather than copying a generic restart/reboot pattern, and do not default to an automatic server reboot as a late-stage action unless there is a documented, workload-specific reason to.

Set via command line (space after reset= and actions= is required):

With this two-action example, failures after the second continue to use the second restart action (120 second delay) until the reset period of 300 seconds with no failures is reached – not “no action,” as a shorthand summary might otherwise suggest.

View the currently configured actions:

sc.exe qfailure reports configured failure actions, reset period, and reboot message – not a live failure count.

SERVICE_FAILURE_ACTIONS_FLAG changes when configured recovery actions fire. It does not create recovery actions by itself and has no effect on a service with no failure actions configured. To extend failure-action triggering to non-crash terminations for a service that already has failure actions configured:

Check the current setting:

Set the flag back to 0 to disable it. Per Microsoft’s SERVICE_FAILURE_ACTIONS_FLAG documentation, a change to this flag takes effect the next time the system starts – plan a full system restart, not just a service restart, before relying on the new behavior. failureflag and qfailureflag are documented sc.exe subcommands per Microsoft’s Configuring a Service Using SC reference.

Use PowerShell with sc.exe explicitly (the sc alias in PowerShell maps to Set-Content, not the service control tool):

Hung Services: When Stop Won’t Work

A service stuck in “Stopping” state is a different problem from one that will not start. The process is running but not responding to Service Control Manager control messages.

A service stuck in “Starting” state is one condition that can lead to Error 1053. Use the PID and logs to determine whether the process is still initializing, waiting on a dependency or resource, or otherwise unresponsive before deciding whether to terminate it.

Full Windows Service Diagnostic Workflow

When a service fails and the cause is not obvious, follow this order:

Service Control Manager Event IDs to Know

7009 correlates with a start or control timeout – the same underlying condition behind Error 1053 – but read the exact wording and context in the event itself rather than treating the two as universally interchangeable. Events 7031 and 7034 are post-mortem; they appear after the failure. The actual cause sits in the Application log or the service’s own log at the same timestamp. This table is a reference layer; it doesn’t replace the dedicated Error 1067 and Event 7023 sections above for actually diagnosing a specific failure.

Common Mistakes

Rebooting instead of diagnosing. A reboot does not clear the Windows event logs, but it does restart every service and reset process state, which can make a transient failure much harder to reproduce. Capture sc.exe queryex output and the relevant log entries before rebooting, not after.

Fixing the wrong service. Event ID 7001 points to the service that failed because of a dependency problem, not the dependency that actually broke. Walk the dependency chain to find the real failure.

Changing the service account in Services.msc without checking GPO first. If a GPO controls the service logon account or its rights, a manual change gets overwritten on the next refresh. Check the resultant policy for service accounts or User Rights Assignment before making local changes.

Treating recovery actions as the fix. Recovery actions can respond to some startup-phase crashes as well as runtime failures, depending on how the process terminates and the service’s failure-action flag. They do not explain or fix the root cause, so diagnose the startup failure even if SCM successfully restarts the service.

Using sc in PowerShell instead of sc.exe. In PowerShell, sc is an alias for Set-Content. Use sc.exe explicitly for service control commands in 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 SERVICE_EXIT_CODE, not WIN32_EXIT_CODE. Most diagnostic workflows stop at 1066 without reading the second field.

FAQ

What is a Service Control Manager error?

Service Control Manager (SCM) records service start, stop, termination, timeout, dependency, and account-related failures. The SCM event usually describes the failure state, such as stopped, timed out, terminated, or dependency missing, rather than the underlying application cause. Correlate the SCM event with sc.exe queryex output and the Application or service-specific log to find the actual reason.

What does Error 1067: The process terminated unexpectedly mean?

The service process started or attempted to start, then ended without a clean stop. Service Control Manager reports that the process terminated; it does not report why. The Application log, a service-specific log, or the executable’s own exit details usually contain the actual cause.

How do I fix Error 1067 on Windows Server?

Query the state and exit code with sc.exe queryex, correlate the SCM event timestamp, inspect the Application or service-specific log at that same timestamp, then verify the binary path, service account, and dependencies before changing configuration. See the dedicated Error 1067 section above for the full sequence.

What is Service Control Manager Event ID 7023?

Event 7023 means a service terminated and Service Control Manager logged the error it returned. The event’s exact error text, not the event number, is what determines the next troubleshooting step; the same event ID appears across many unrelated failure causes.

What is the difference between Error 1067 and Error 1053?

Error 1067 means the service process terminated unexpectedly; SCM reports the termination but not the underlying reason. Error 1053 means the service did not respond to the start or control request in a timely fashion. It does not identify the underlying cause by itself – initialization problems, resource waits, service implementation issues, configuration, or component failures can all produce this symptom. Check the Application log before concluding either way.

Why does Error 1075 occur?

Service Control Manager tried to start a dependency that is not registered in the services database at all. It can follow a botched software uninstall, a manual sc.exe delete on the wrong service, a configuration change that removed a service registration, or an incomplete update or rollback. Run sc.exe qc <service> to see the dependency string, then sc.exe query <dependency-name> for each entry to confirm which one is actually missing; a similar display name in Services.msc does not mean the underlying service is registered.

Recovery actions are configured but the service stays down after a crash. Why?

A few common reasons: no failure actions are configured for the service; the failure does not meet the configured failure-trigger semantics, for example SERVICE_FAILURE_ACTIONS_FLAG is not enabled and the service reports SERVICE_STOPPED with a non-zero exit code rather than terminating without reporting it; the configured action itself fails to run; or the reset/action configuration is not what was intended. Run sc.exe qfailure <service> to see the currently configured failure actions and reset period, not a live failure count. Also check whether the System event log shows Event ID 7031, which reports the corrective action SCM intends to take.

What should I check when a service has no dependencies configured but still fails to start?

Then it is not a dependency issue; it is a process, account, or environment problem. Check the Application event log immediately after the failure. SCM logs Event ID 7000, but the service binary itself usually logs the actual cause in the Application log or a service-specific log under %ProgramData% or %SystemRoot%\Logs. For remote-administration services specifically, see the RDP and WinRM recovery guide. For the Windows Update Agent service (wuauserv), see WSUS Client Not Reporting and WSUS Not Downloading Updates.