Diagnose Windows service Error 1053, Error 1067, and Error 1069
Windows service Error 1053 means the service did not answer the Service Control Manager in time, Error 1067 means the service process terminated unexpectedly, and Error 1069 means Windows could not log on with the configured service identity. This guide separates those failure paths, preserves event and configuration evidence, and applies the smallest reversible repair.
Identify the exact service, timestamp, account, binary, dependencies, Windows and service-specific exit evidence; repair only the proven cause; then demonstrate a stable start, healthy dependency chain, expected process identity, and clean observation window without weakening service-account or timeout policy.
- Windows Server 2019, 2022, 2025
- Windows Client Windows 10, Windows 11
- PowerShell Windows PowerShell 5.1, PowerShell 7+
- Local administrative access Use an approved administrator session that can read the System and Application logs and inspect service configuration. Keep console or out-of-band access for production servers.
whoami /all - Exact service name and failure time Record the service name, not only its display name, and the local timestamp of one controlled failed start. Do not repeatedly restart a service that may write data.
Get-Service -Name {{serviceName}} | Format-List Name,DisplayName,Status - Change and recovery owner Know who owns the service, its configuration and credentials, what depends on it, and how to restore the previous service definition or application package.
OneLiners never runs these steps or stores secrets. Review placeholders, versions, current state, and change-control requirements before using a command.
Full guide
What you will build
- A repeatable evidence path that begins with one exact service failure and correlates Service Control Manager state, System and Application events, service-specific logs, process identity, binary integrity, dependencies and service-account policy.
- Three distinct decision paths for Error 1053 timeout or control-handler failure, Error 1067 unexpected process termination, and Error 1069 service logon failure, each ending in the smallest source-backed repair.
- A bounded verification and rollback record that proves the service remains running under the intended identity and can perform its owned workload without recurring wrapper errors.
- The operator can explain which Windows boundary failed and can cite the exact event, exit code, path, identity, dependency or policy evidence.
- The service starts once under observation, remains stable through the agreed window, and passes an application-level check.
- No global timeout, broad ACL, disabled certificate check, weakened endpoint protection or plaintext credential is introduced as a generic workaround.
Architecture
How the parts fit together
Service Control Manager stores the service definition, starts the configured executable under its service identity, observes status transitions and applies recovery actions. The process can depend on Windows services, files, certificates, network endpoints and product configuration. Windows System events describe lifecycle failures, Application and vendor logs describe process causes, and identity and Group Policy determine whether a logon session can be created. Diagnosis follows that chain from SCM symptom to the first failed boundary.
- Capture one exact failure, service name, timestamp, state, process ID and exit evidence.
- Correlate System, Application and product events and preserve the earliest actionable cause.
- Inventory service configuration, dependencies, binary integrity and account policy.
- Enter the Error 1053, 1067 or 1069 branch and identify one failed boundary.
- Apply one reviewed reversible repair through the authoritative owner.
- Start once, observe state and logs, run a product-level check, and retain rollback evidence.
Assumptions
- The service is installed through a known product or configuration-management owner and the intended executable, arguments, account and dependencies can be verified.
- The operator has approved read access to service configuration and relevant logs plus a maintenance owner for any start or repair.
- Host time is correct enough to correlate events and relevant logs have not been cleared or overwritten.
- Production services that own data, queues or cluster roles have workload-specific stop, start and recovery procedures outside this generic guide.
Key concepts
- Error 1053
- The service did not respond to the start or control request in a timely fashion. It identifies a timeout boundary, not whether the cause is slow initialization, deadlock, dependency or incorrect service code.
- Error 1067
- The process terminated unexpectedly. The actionable cause normally comes from process, runtime, product or crash evidence before the SCM summary.
- Error 1069
- The service did not start due to a logon failure. Check the configured identity, account state, effective user right, domain path and protected credential lifecycle.
- WIN32_EXIT_CODE
- The Windows error reported through the service status; a service can also expose a separate service-specific exit code.
- Checkpoint and wait hint
- Progress and expected-duration signals a service can report while a start, stop, pause or continue operation is pending.
- Recovery action
- An SCM policy that can restart a service, run a command or reboot after failure; repeated actions can obscure evidence or amplify impact.
Fill these once. Every matching command and configuration block updates immediately; values stay in this page only.
Security and production boundaries
- Service identities are privileged operational credentials. Never put passwords in sc.exe arguments, scripts, variables, screenshots or incident comments.
- Broad Full Control grants, disabled endpoint protection and unquoted or user-writable service paths can turn a startup incident into privilege escalation.
- Crash dumps, event messages and configuration files may contain secrets or customer data; use protected evidence storage and redact exports.
- Group Policy can replace Log on as a service assignments. Identify the policy owner rather than fighting it with an untracked local change.
Stop before continuing if
- Stop if the service name, binary, owner, workload impact or exact failure time cannot be established.
- Do not keep restarting a service that writes data, processes a queue, controls a cluster resource, locks an account or creates large crash dumps.
- Stop if binary integrity, publisher, path ownership or endpoint-security evidence suggests tampering.
- Do not change global ServicesPipeTimeout, broad ACLs, security controls or service passwords without a proven cause and rollback.
- Escalate when the service account is shared and all consumers are not known.
verification
Capture the exact Error 1053, Error 1067, or Error 1069 failure
Perform one controlled start only when the service owner confirms it is safe, then record the exact Services message, timestamp, service name, current state, process ID and Win32 or service-specific exit code. The generic dialog is a routing clue rather than a root cause.
Why this step matters
The same visible failure can be produced by a timeout, a crashed executable, a logon failure, a dependency, or a product-specific startup check. Capturing identity and exit evidence before changing anything prevents unrelated repairs and creates a timestamp for log correlation.
What to understand
Use the internal service Name in every command; a translated display name can be ambiguous.
Record both WIN32_EXIT_CODE and SERVICE_EXIT_CODE because some services return their own code.
A nonzero ProcessId after Error 1053 suggests startup is still running or hung; ProcessId zero after Error 1067 is consistent with an exited process.
System changes
- None; this step records service state and the exact visible error.
Syntax explained
Win32_Service- Exposes service identity, account, path, process ID and exit state through CIM.
sc.exe queryex- Shows Service Control Manager state, checkpoint, wait hint, process ID and exit codes.
Values stay on this page and are never sent or saved.
$svc = Get-CimInstance Win32_Service -Filter "Name='{{serviceName}}'"; $svc | Select-Object Name,DisplayName,State,Status,StartMode,StartName,PathName,ProcessId,ExitCode; sc.exe queryex {{serviceName}}Name : AcmeWorker DisplayName : Acme Background Worker State : Stopped StartMode : Auto StartName : CONTOSO\svc_acme ProcessId : 0 ExitCode : 1067 [SC] QueryServiceStatusEx SUCCESS WIN32_EXIT_CODE : 1067 (0x42b) SERVICE_EXIT_CODE : 0 (0x0)
Checkpoint: One failure is tied to one service and timestamp
Get-Date -Format o; sc.exe queryex {{serviceName}}Continue whenThe ticket contains the exact Error 1053, Error 1067, or Error 1069 text, service name, timestamp, state and exit fields.
Stop whenThe service name is uncertain, a restart could corrupt data, or another change is already in progress.
If this step fails
The service immediately becomes Running after the dialog closes.
Likely causeStartup exceeded the caller timeout but later completed, or status reporting is incorrect.
Re-query state and correlate process and event timestamps without restarting again.
ResolutionTreat it as an Error 1053 timing or service-code problem, not as a crashed service.
Security notes
- Do not paste service-account passwords, command lines containing secrets, or full environment blocks into a ticket.
Alternatives
- Use an existing monitoring snapshot if another start attempt is unsafe.
Stop conditions
- Stop after one controlled reproduction if the service owns a database, queue, cluster resource, or recovery-sensitive workload.
verification
Correlate Service Control Manager and application events
Read the System log for Service Control Manager events and the Application log for the same time window. Preserve event record IDs, providers, messages and correlation fields. The first service-specific error before the final SCM summary usually contains the actionable cause.
Why this step matters
Service Control Manager reports lifecycle symptoms, while the executable, runtime, dependency or security provider often logs the cause elsewhere. Time-bounded collection avoids drowning the operator in unrelated historical events and preserves the event sequence.
What to understand
Compare System and Application entries by local time, service name, process ID and provider.
Export relevant events before log retention overwrites them.
Do not assume event ID alone proves a cause; read the complete message and service-specific log.
System changes
- None; reads the Windows event logs.
Syntax explained
FilterHashtable- Filters at the event-log provider by log, provider and start time before objects enter the pipeline.
RecordId- Provides a stable reference to the exact event on that host.
Values stay on this page and are never sent or saved.
$since = (Get-Date).AddMinutes(-{{minutesBack}}); Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Service Control Manager'; StartTime=$since} -ErrorAction SilentlyContinue | Where-Object Message -Match '{{serviceName}}|1053|1067|1069' | Select-Object TimeCreated,Id,LevelDisplayName,ProviderName,RecordId,Message; Get-WinEvent -FilterHashtable @{LogName='Application'; StartTime=$since} -ErrorAction SilentlyContinue | Where-Object Message -Match '{{serviceName}}' | Select-Object TimeCreated,Id,LevelDisplayName,ProviderName,RecordId,MessageTimeCreated : 2026-08-23 18:31:42 Id : 7031 ProviderName: Service Control Manager Message : The Acme Background Worker service terminated unexpectedly. TimeCreated : 2026-08-23 18:31:41 Id : 1000 ProviderName: Application Error Message : Faulting application name: AcmeWorker.exe, exception code: 0xe0434352
Checkpoint: The earliest actionable event is identified
Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Service Control Manager'; StartTime=(Get-Date).AddMinutes(-{{minutesBack}})} -MaxEvents 30Continue whenA chronological evidence set distinguishes the initiating error from later Service Control Manager summaries.
Stop whenRelevant logs are unavailable, time is wrong, or retention has overwritten the failure window.
If this step fails
Only the final SCM event is present.
Likely causeThe service does not log startup failures, its own log is elsewhere, or the event window is wrong.
Confirm local time and inspect the vendor-documented log path or Windows Error Reporting events.
ResolutionCollect service-specific diagnostics through its supported logging mode before changing configuration.
Security notes
- Review event messages for credentials, tokens, connection strings and customer data before sharing.
Alternatives
- Export the filtered System and Application events as EVTX for offline review.
Stop conditions
- Do not clear event logs or enlarge the search window until the exact failure timestamp is established.
verification
Inventory the service path, account, startup type, dependencies, and recovery policy
Capture the authoritative Service Control Manager configuration before repair. Compare the binary path, service account, dependencies, start mode and failure actions with the approved deployment definition or a healthy peer running the same build.
Why this step matters
An upgrade, manual edit, policy refresh or password rotation can leave the service definition inconsistent with its files and identity. A baseline makes every proposed edit reviewable and supplies rollback evidence.
What to understand
Preserve quoting around a path containing spaces and separate executable path from arguments.
Check required services and the reverse dependency set before any stop or restart.
Failure actions can create a restart loop that hides the original exit and amplifies damage.
System changes
- None; captures configuration and dependency evidence.
Syntax explained
sc.exe qc- Queries the stored service configuration including path, account, start type and dependencies.
sc.exe qfailure- Queries restart, reboot or command actions configured after failure.
Values stay on this page and are never sent or saved.
sc.exe qc {{serviceName}}; sc.exe qfailure {{serviceName}}; Get-Service -Name {{serviceName}} -RequiredServices | Select-Object Name,Status,StartType; Get-Service -Name {{serviceName}} -DependentServices | Select-Object Name,Status,StartType[SC] QueryServiceConfig SUCCESS SERVICE_START_NAME : CONTOSO\svc_acme BINARY_PATH_NAME : "C:\Program Files\Acme\AcmeWorker.exe" --service DEPENDENCIES : Tcpip START_TYPE : 2 AUTO_START Name Status StartType Tcpip Running Automatic
Checkpoint: Configuration matches an owned deployment
sc.exe qc {{serviceName}}Continue whenThe path, arguments, account, start mode and dependencies have an approved source and no unexplained drift.
Stop whenThe executable path, service owner or dependency contract cannot be verified.
If this step fails
The binary path points to a removed version directory.
Likely causeAn upgrade removed files without updating the service definition.
Compare installed package inventory, deployment logs and the healthy peer definition.
ResolutionRestore the approved package or update the path through the product installer; do not point at an arbitrary binary.
Security notes
- Unquoted service paths and writable executable directories are privilege-escalation risks; preserve evidence and escalate them.
Alternatives
- Export the relevant service registry key through an approved configuration-management inventory rather than editing it.
Stop conditions
- Stop if the service definition appears tampered with or its binary source cannot be authenticated.
verification
Verify executable presence, signature, version, and access path
Confirm that the configured executable exists, is the expected version, has a valid publisher signature when the product provides one, and can traverse its directory and read required configuration under the service identity. Inspect; do not grant broad permissions.
Why this step matters
Error 1067 often follows a missing dependency, corrupt binary, invalid configuration or access denial, while Error 1053 can follow a blocked startup read. Evidence must be compared with the vendor package rather than fixed by granting Full Control.
What to understand
Resolve the executable from the captured service configuration; do not trust an unreviewed path copied from a ticket.
Check parent-directory traversal and only the files the service actually needs.
A missing or invalid signature is not automatically malicious, but unexpected changes require integrity review.
System changes
- None; reads file metadata, signature status and ACLs.
Syntax explained
Get-AuthenticodeSignature- Checks whether the file's Authenticode signature can be validated.
Get-Acl- Shows ownership and access rules without changing them.
Values stay on this page and are never sent or saved.
$path='{{binaryPath}}'; Get-Item -LiteralPath $path | Select-Object FullName,Length,VersionInfo,LastWriteTimeUtc; Get-AuthenticodeSignature -LiteralPath $path | Select-Object Status,StatusMessage,SignerCertificate; Get-Acl -LiteralPath $path | Format-List Owner,AccessToStringFullName : C:\Program Files\Acme\AcmeWorker.exe Length : 1849344 LastWriteTimeUtc : 2026-08-20 03:12:11Z Status : Valid Owner : BUILTIN\Administrators AccessToString : NT SERVICE\TrustedInstaller Allow FullControl; CONTOSO\svc_acme Allow ReadAndExecute
Checkpoint: The configured binary is authentic and reachable
Test-Path -LiteralPath '{{binaryPath}}'; Get-FileHash -LiteralPath '{{binaryPath}}' -Algorithm SHA256Continue whenThe exact expected executable exists, its version and hash match the deployment record, and ACLs are no broader than required.
Stop whenThe binary is missing, unexpectedly changed, writable by untrusted users, or quarantined by security tooling.
If this step fails
Access appears correct on the file but startup still reports access denied.
Likely causeA parent directory, configuration, certificate key, network location or controlled-folder policy blocks the service identity.
Trace every required resource from vendor logs and inspect its narrow ACL or security event.
ResolutionGrant only the documented right on the specific resource through the owning deployment process.
Security notes
- Do not disable antivirus or application control to test an unknown executable.
Alternatives
- Restore the exact signed package from the approved artifact repository when integrity is not provable.
Stop conditions
- Quarantine and escalate if file integrity or publisher identity differs from the approved release.
decision
For Error 1053, distinguish slow startup from a blocked control handler
Error 1053: The service did not respond to the start or control request in a timely fashion means the caller or Service Control Manager timed out waiting for a valid status transition. Determine whether the process remains alive, advances checkpoints, waits on a dependency, deadlocks, or never reports service status.
Why this step matters
Increasing ServicesPipeTimeout globally can hide a deadlock, slow every boot and leave a broken service running longer. Process, checkpoint, wait-hint, dependency and service-specific evidence must justify whether the issue is code, configuration, infrastructure or a genuinely longer supported startup.
What to understand
A changing checkpoint indicates progress; a fixed checkpoint and idle process suggest a blocked stage.
Check DNS, certificates, databases and network dependencies only when logs show that startup waits for them.
For custom services, long initialization should occur asynchronously while the service reports status correctly.
System changes
- None; this branch observes the pending process and Service Control Manager status.
Syntax explained
CHECKPOINT- A service can increment this value to show progress during a pending operation.
WAIT_HINT- The service's estimate for the pending operation; it is evidence, not permission for an unlimited wait.
Values stay on this page and are never sent or saved.
$svc=Get-CimInstance Win32_Service -Filter "Name='{{serviceName}}'"; $svc | Select State,ProcessId,ExitCode; if($svc.ProcessId -gt 0){Get-Process -Id $svc.ProcessId | Select Id,StartTime,CPU,Responding,Path}; sc.exe queryex {{serviceName}}State : Start Pending ProcessId : 4820 ExitCode : 0 Id : 4820 StartTime : 8/23/2026 6:31:10 PM CPU : 0.12 Responding: True STATE : 2 START_PENDING CHECKPOINT: 0x3 WAIT_HINT : 0x7530
Checkpoint: The timeout has a named blocked or slow stage
sc.exe queryex {{serviceName}}Continue whenProcess state, checkpoint trend, dependency and service log identify the startup stage responsible for Error 1053.
Stop whenNo supported diagnostic method exists or the process is consuming resources without a bounded observation plan.
If this step fails
Many unrelated automatic services fail with Error 1053 after boot.
Likely causeA shared Service Control Manager, event-log, storage, security or dependency problem may exist.
Check system-wide SCM events, resource pressure, pending restart and sc.exe querylock evidence.
ResolutionTreat the host as a system incident; do not tune each service independently.
Security notes
- Do not attach a debugger or capture memory containing secrets without incident approval and protected storage.
Alternatives
- Reproduce on an isolated host with vendor debug logging and the same configuration.
Stop conditions
- Do not change a global timeout until the service owner proves a supported startup duration and rules out deadlock.
decision
For Error 1067, identify the first process termination cause
Error 1067: The process terminated unexpectedly means Service Control Manager observed the service process exit during startup or operation. Follow the process ID into Application Error, Windows Error Reporting, runtime and product logs, then validate the exact configuration before restarting.
Why this step matters
The 1067 wrapper contains no product diagnosis. A runtime exception, invalid configuration, incompatible library, missing file, port collision or deliberate self-check can all produce it. The earliest process-specific event and supported config validator determine the repair.
What to understand
Preserve the exception code, faulting module, product log and deployment change that preceded the first exit.
Run a service-specific configuration test when available; do not invent an unsupported command-line launch mode.
Compare binary and dependency versions after upgrades, especially side-by-side runtime or plugin components.
System changes
- None; collects process termination evidence.
Syntax explained
1000 / 1001 / 1026- Common Application Error, Windows Error Reporting and .NET Runtime evidence; providers differ by product.
Select-Object -First 30- Bounds evidence while retaining the newest relevant events.
Values stay on this page and are never sent or saved.
$since=(Get-Date).AddMinutes(-{{minutesBack}}); Get-WinEvent -FilterHashtable @{LogName='Application'; StartTime=$since} | Where-Object {$_.Id -in 1000,1001,1026 -or $_.Message -match '{{serviceName}}'} | Select-Object -First 30 TimeCreated,Id,ProviderName,MessageTimeCreated : 2026-08-23 18:31:41 Id : 1026 ProviderName: .NET Runtime Message : Application: AcmeWorker.exe; Exception: System.FormatException; File: C:\ProgramData\Acme\worker.json line 18
Checkpoint: A service-specific cause replaces the generic 1067 wrapper
Get-WinEvent -FilterHashtable @{LogName='Application'; StartTime=(Get-Date).AddMinutes(-{{minutesBack}})} -MaxEvents 50Continue whenA product, runtime, configuration or dependency error identifies the failed startup stage and supported repair.
Stop whenOnly the generic 1067 event exists and the service has no supported diagnostic mode.
If this step fails
The service exits only under Service Control Manager, not when the executable is launched interactively.
Likely causeWorking directory, session, environment, account, service-mode arguments or desktop interaction differs.
Compare the captured service definition and vendor-supported service diagnostic procedure.
ResolutionCorrect the service deployment contract; do not make it depend on an interactive desktop.
Security notes
- Crash dumps can contain credentials and customer data; collect them only into protected incident storage.
Alternatives
- Restore the previous approved application package and configuration when the failure follows a failed deployment.
Stop conditions
- Stop repeated restart loops that generate data corruption, account lockout or excessive crash dumps.
decision
For Error 1069, verify the service logon identity without exposing credentials
Error 1069: The service did not start due to a logon failure means Windows could not create the service logon session. Verify the configured account, domain reachability, account state, managed-service-account installation, password-rotation ownership and Log on as a service policy before changing credentials.
Why this step matters
Error 1069 is often caused by an expired or rotated password, a disabled or locked account, missing user right, domain trust or gMSA configuration. Resetting a password blindly can break every other service using the identity and leak a secret into process history.
What to understand
Map the identity to every service, scheduled task and application before rotation.
For a gMSA, verify host authorization and installation rather than supplying a password.
Effective user-right assignment can be replaced by Group Policy; identify the winning policy instead of editing it locally.
System changes
- None; inspects service identity and effective policy evidence.
Syntax explained
StartName- The account configured for the service logon.
gpresult /scope computer /r- Shows applied computer GPOs that may own service logon rights.
Values stay on this page and are never sent or saved.
$svc=Get-CimInstance Win32_Service -Filter "Name='{{serviceName}}'"; $svc | Select Name,StartName,State,ExitCode; whoami /all; gpresult /scope computer /rName : AcmeWorker StartName : CONTOSO\svc_acme State : Stopped ExitCode : 1069 Applied Group Policy Objects ----------------------------- CONTOSO Member Server Baseline CONTOSO Service Logon Rights
Checkpoint: The failed logon boundary and its owner are known
Get-CimInstance Win32_Service -Filter "Name='{{serviceName}}'" | Select-Object Name,StartName,ExitCodeContinue whenThe service account, account lifecycle owner, effective user-right policy and exact 1069 timestamp are recorded without exposing a password.
Stop whenThe identity is shared but its consumers are unknown, or changing it would bypass domain policy.
If this step fails
The password was rotated but Error 1069 continues.
Likely causeThe wrong identity was updated, another policy removed the user right, the account is locked, or domain connectivity is unavailable.
Re-read StartName, account state, domain events and effective user-right policy.
ResolutionRepair the proven identity or policy issue through its owner; do not keep rotating secrets.
Security notes
- Never place a service password in sc.exe arguments, scripts, screenshots, logs or this Guide's variables.
Alternatives
- Migrate a suitable service to a gMSA through a separately reviewed change when the product supports it.
Stop conditions
- Do not rotate or replace a shared service identity until all consumers and rollback owners are known.
warning
Apply only the smallest source-backed repair
Choose one repair that follows directly from the evidence: restore the approved binary or configuration, correct a narrow file right, repair a dependency, update service-mode code, restore domain policy, or update the service identity through the approved secret-management workflow.
Why this step matters
The repair step is intentionally product-neutral because the three Windows errors are wrappers. A broad permission grant, global timeout, disabled security control or blind reinstall is not justified without a source-backed diagnosis.
What to understand
Record the exact before value, proposed after value, owner, maintenance window and rollback command.
Use the product installer or configuration tool when it owns service registration.
Preserve current logs and binaries before a package rollback or upgrade.
System changes
- Creates a reviewed change record; the actual product-specific repair may change files, service configuration, policy or identity.
Syntax explained
-WhatIf- Previews the evidence-copy operation without changing files.
Values stay on this page and are never sent or saved.
Copy-Item -LiteralPath .\evidence\{{serviceName}}-before.json -Destination .\evidence\{{serviceName}}-change-record.json -WhatIfWhat if: Performing the operation "Copy File" on target "Item: .\evidence\AcmeWorker-before.json Destination: .\evidence\AcmeWorker-change-record.json".
Checkpoint: One evidence-backed change is approved
Test-Path .\evidence\{{serviceName}}-before.jsonContinue whenThe change record names one cause, one smallest repair, affected resources, verifier and rollback.
Stop whenThe proposed repair changes global timeout, broad ACLs, antivirus, firewall or multiple unrelated settings.
If this step fails
A proposed fix says to reinstall everything.
Likely causeThe generic Windows error was never resolved to a product-specific cause.
Return to the event, binary, identity and dependency evidence.
ResolutionUse a repair or rollback for the exact failed component only.
Security notes
- Credential repair must use approved protected entry, not plaintext command arguments.
Alternatives
- Rollback the last known deployment when its timing and evidence clearly match the first failure.
Stop conditions
- Stop if the repair cannot be reversed or its blast radius is larger than the failed service.
command
Start once under observation and collect the transition
After approval, perform one start while monitoring Service Control Manager and the service-specific log. Confirm dependencies first, record start duration, state transitions, process identity, exit codes and any new warnings. Do not use an automatic restart loop as validation.
Why this step matters
A controlled start proves the repaired boundary but can trigger work, network connections or queued processing. The owner must know the workload effect, and the observation must cover more than a transient Running state.
What to understand
Start required dependencies through their owners; do not recursively start unknown services.
Use a bounded wait and then inspect actual process and logs.
Record the identity and binary path of the running process so a name collision cannot create a false success.
System changes
- Starts the selected service and may cause its documented workload effects.
Syntax explained
-PassThru- Returns the service object after requesting the start.
WaitForStatus- Waits for a bounded state transition rather than sleeping indefinitely.
Values stay on this page and are never sent or saved.
$before=Get-Date; Start-Service -Name {{serviceName}} -PassThru; $svc=Get-Service -Name {{serviceName}}; $svc.WaitForStatus('Running',(New-TimeSpan -Seconds 30)); Get-CimInstance Win32_Service -Filter "Name='{{serviceName}}'" | Select Name,State,StartName,ProcessId,ExitCode; [pscustomobject]@{Started=$before;Verified=Get-Date;ElapsedSeconds=((Get-Date)-$before).TotalSeconds}Status Name DisplayName ------ ---- ----------- Running AcmeWorker Acme Background Worker Name : AcmeWorker State : Running StartName : CONTOSO\svc_acme ProcessId : 6112 ExitCode : 0 ElapsedSeconds : 4.8
Checkpoint: The service reaches Running without a new wrapper error
Get-Service -Name {{serviceName}}; sc.exe queryex {{serviceName}}Continue whenRunning state, expected account and process, exit code zero, stable checkpoint and no new Error 1053, Error 1067, or Error 1069.
Stop whenThe service starts unexpected work, enters a restart loop, uses the wrong identity or creates new errors.
If this step fails
The service reports Running and stops seconds later.
Likely causeStartup succeeded but a health check, dependency or workload path failed.
Extend log correlation through the stop time and inspect recovery actions.
ResolutionTreat it as an Error 1067 or product health failure; stop automatic restarts and diagnose the first exit.
Security notes
- Observe outbound connections and privilege-sensitive work expected from the service identity.
Alternatives
- Validate on a staging host or passive instance before production start.
Stop conditions
- Stop immediately if data integrity, account lockout, repeated crashes or unexpected network activity appears.
verification
Verify dependencies, logs, process identity, and workload health
Keep the service under an explicit observation window that covers its normal initialization and one representative workload. Verify required services, process identity, event logs, application health endpoint or transaction, and absence of restart-loop events.
Why this step matters
A successful Start-Service call proves only that the request was accepted. Stable operation requires the expected identity, dependency chain, clean event window and a product-level check that exercises the reason the service exists.
What to understand
Use an observation period long enough to cross delayed initialization and recovery-action windows.
Run the smallest read-only or synthetic product check approved by the service owner.
Compare CPU, memory, handles and connection behavior with a known healthy baseline when relevant.
System changes
- The command waits and reads state; the already-running service continues its normal workload.
Syntax explained
StartTime=$since- Restricts verification events to the observation window.
Values stay on this page and are never sent or saved.
$since=Get-Date; Start-Sleep -Seconds 30; Get-Service -Name {{serviceName}} | Select Name,Status,StartType; Get-CimInstance Win32_Service -Filter "Name='{{serviceName}}'" | Select Name,State,StartName,ProcessId,ExitCode; Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Service Control Manager'; StartTime=$since} -ErrorAction SilentlyContinue | Where-Object Message -Match '{{serviceName}}' | Select TimeCreated,Id,MessageName Status StartType AcmeWorker Running Automatic State : Running StartName : CONTOSO\svc_acme ProcessId : 6112 ExitCode : 0 Service Control Manager events since verification start: 0 errors
Checkpoint: The service is stable and useful
Get-Service -Name {{serviceName}}; sc.exe queryex {{serviceName}}Continue whenRunning state remains stable, identity and binary are expected, exit code is zero, dependencies are healthy and the application-level check passes.
Stop whenThe service repeatedly restarts, leaks resources, cannot perform its intended function or logs new security warnings.
If this step fails
Windows state is healthy but the application check fails.
Likely causeService lifecycle is repaired, but downstream configuration or dependency is still broken.
Inspect the product's health output and dependency telemetry without changing service policy.
ResolutionOpen a product-specific incident; do not keep changing Service Control Manager settings.
Security notes
- Synthetic checks must not expose production records or privileged credentials.
Alternatives
- Use existing monitoring and an approved canary transaction when direct testing is unavailable.
Stop conditions
- Do not declare recovery from service state alone; require the owned application-level success signal.
instruction
Document the cause, repair, verification, and tested rollback
Close the incident only after preserving the first cause, the exact change, before-and-after configuration, event record IDs, validation evidence, residual risk and rollback owner. Test rollback in staging or rehearse the exact production steps without causing another outage.
Why this step matters
Service incidents recur when operators save only the final command and lose the evidence that justified it. A complete record makes future Error 1053, Error 1067 and Error 1069 failures faster to classify and prevents broad folklore fixes.
What to understand
Record whether the cause belonged to code, configuration, files, dependencies, identity, policy or host health.
Preserve the exact service definition and relevant event IDs, not entire unredacted logs.
Assign follow-up for monitoring, credential ownership, deployment validation or service startup design.
System changes
- None; captures post-change evidence.
Syntax explained
ConvertTo-Json- Produces a structured service-state snapshot for the incident record.
Values stay on this page and are never sent or saved.
sc.exe qc {{serviceName}}; sc.exe qfailure {{serviceName}}; Get-CimInstance Win32_Service -Filter "Name='{{serviceName}}'" | Select Name,State,StartMode,StartName,PathName,ProcessId,ExitCode | ConvertTo-Json{
"Name": "AcmeWorker",
"State": "Running",
"StartMode": "Auto",
"StartName": "CONTOSO\\svc_acme",
"ProcessId": 6112,
"ExitCode": 0
}Checkpoint: Recovery can be explained and reversed
sc.exe qc {{serviceName}}Continue whenThe record contains cause, repair, verifier, observation result, previous configuration and a tested or rehearsed rollback.
Stop whenThe previous state is unknown or rollback would require an untested credential or package.
If this step fails
The same failure returns after the next deployment or password rotation.
Likely causeThe root cause was fixed manually but not in the deployment or identity lifecycle owner.
Compare current definition with configuration management and rotation records.
ResolutionMove the correction into the authoritative deployment or secret-management workflow.
Security notes
- Redact account identifiers only when required, but always remove secrets and sensitive event payloads.
Alternatives
- Link protected configuration-management and monitoring evidence instead of duplicating sensitive records.
Stop conditions
- Do not close the incident while the root cause exists outside the authoritative configuration source.
Finish line
Verification checklist
Get-Service -Name {{serviceName}}; sc.exe queryex {{serviceName}}The selected service is Running with a stable process ID, exit code zero and no pending or restart-loop state.Get-CimInstance Win32_Service -Filter "Name='{{serviceName}}'" | Select Name,State,StartMode,StartName,PathName,ProcessId,ExitCode; Get-Service -Name {{serviceName}} -RequiredServicesThe service uses the approved binary, arguments, account and startup mode, and every required service is healthy.Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Service Control Manager'; StartTime=(Get-Date).AddMinutes(-{{minutesBack}})} -ErrorAction SilentlyContinue | Where-Object Message -Match '{{serviceName}}|1053|1067|1069'No new Error 1053, Error 1067, Error 1069, unexpected termination or repeated recovery-action event appears during the agreed observation window.Recovery guidance
Common problems and safe checks
Error 1053 appears, but the service becomes Running later.
Likely causeStartup exceeded the caller timeout or reported progress incorrectly while continuing in the background.
Re-query ProcessId, state, checkpoint and service logs without another restart.
ResolutionFix the slow or blocked initialization and service status reporting; use a timeout change only when the vendor explicitly supports it.
Error 1067 returns after an application upgrade.
Likely causeThe process exits because a binary, runtime, plugin, configuration schema or dependency version is incompatible.
Correlate Application Error or runtime events, verify file versions and run the vendor configuration check.
ResolutionRepair the exact component or restore the previous approved package and configuration.
Error 1069 starts immediately after credential rotation.
Likely causeThe service definition still uses the previous protected password, the wrong account was rotated, or policy/account state blocks logon.
Confirm StartName, map every consumer, inspect account and effective user-right evidence.
ResolutionCoordinate the identity owner and update every approved consumer through the protected rotation workflow.
The service repeatedly starts and stops without a visible dialog.
Likely causeSCM failure actions or an external supervisor are restarting an unhealthy process.
Read qfailure configuration and correlate repeated process IDs and event timestamps.
ResolutionPause the restart loop through change control, preserve the first failure, and diagnose the underlying exit.
A dependency is Stopped, but starting it also fails.
Likely causeThe visible service is downstream of a separate incident.
Diagnose the dependency by its own service name, events, identity and product owner.
ResolutionRepair the dependency first; do not remove it from the service definition to bypass ordering.
Changing the local user right works briefly and then Error 1069 returns.
Likely causeDomain Group Policy is the authoritative owner and replaces the local assignment.
Collect gpresult and identify the winning computer policy.
ResolutionCorrect the reviewed domain policy scope or membership rather than repeating local edits.
Reference
Frequently asked questions
What does Error 1053: The service did not respond to the start or control request in a timely fashion mean?
It means the expected Service Control Manager status transition did not arrive within the allowed boundary. It does not prove that Windows needs a larger global timeout. Check the process, checkpoint, wait hint, dependencies and product log to distinguish slow progress, deadlock, blocked I/O and incorrect service code.
What does Error 1067: The process terminated unexpectedly mean?
It means the service process exited. The useful cause is usually in the earliest Application Error, runtime, Windows Error Reporting or vendor event and may be an exception, invalid configuration, missing file, incompatible module, port collision or deliberate startup self-check.
What does Error 1069: The service did not start due to a logon failure mean?
It means Windows could not create the configured service logon session. Verify StartName, account state, domain reachability, Log on as a service policy, gMSA installation and credential-rotation ownership. Never put the password on a command line.
Should I increase ServicesPipeTimeout to fix Error 1053?
Not as a first response. A larger machine-wide timeout can hide deadlock and slow boot. Consider it only when a supported service is proven to need a longer bounded startup after dependencies, logs and status-reporting behavior have been reviewed.
Can I grant Full Control to the service folder to test the problem?
Do not use a broad grant. Identify the exact denied resource and required operation, preserve the current ACL, and grant only the narrow right through the deployment owner. Unexpectedly writable service binaries are a security incident.
How do I know the Windows service is really fixed?
Require a stable Running state, expected process and account, exit code zero, healthy dependencies, no new 1053, 1067 or 1069 events during the observation window, and one product-level health or synthetic transaction.
Recovery
Rollback
Stop further retries, preserve new evidence, and restore only the changed layer: previous package or configuration, narrow ACL, dependency setting, service identity through the protected credential owner, or prior policy. Then perform one controlled start and repeat the full verification. A service account password cannot be recovered from Windows; rollback requires the previous protected credential or a coordinated new rotation.
- Stop automated restart loops and preserve System, Application and service-specific events from the failed change window.
- Identify the exact changed file, package, ACL, dependency, timeout, account or policy and its recorded previous value.
- Restore the previous value through the product installer, configuration-management, policy or identity owner rather than ad hoc registry edits.
- If the identity changed, coordinate every consumer and use the protected credential workflow; never place a password on a command line.
- Verify binary integrity, service definition, dependencies and effective policy before one controlled start.
- Repeat state, event, process identity and application-level verification and retain the failed revision for review.
Evidence