OpalSpan

Windows service starts then stops: find the cause before restarting

Published

A service briefly starts, then Services reports that it stopped. The message describes a state change, not its cause. It can mean an intentional idle stop, a startup exception, an unavailable dependency or a failed operation under the service account. Changing every service to Automatic will not distinguish them.

For a support provider, the useful first result is a short evidence chain: which service, which start attempt, what Windows recorded, what the application recorded and what work failed. Collect that before changing configuration or trying another restart.

This guide covers the local diagnostic workflow on Windows 11 and Windows Server 2022/2025 installations within their applicable support lifecycle. The read commands work in Windows PowerShell 5.1 or PowerShell 7 on Windows. The separate .NET note concerns modern hosted workers, not every Windows service. Check the application’s own supported OS and runtime versions before changing it.

1. Decide whether stopping is actually a failure

Identify the Service name in the service’s Properties dialog; it can differ from the display name. Record the application version, recent deployment or configuration change and the time of the failed start, including time zone.

Some services are designed to run on demand and stop when idle. Microsoft documents trigger-started services that stop themselves when no work remains. Check the vendor’s expected behavior and whether the real client operation fails. A stopped service with no pending work is not automatically broken.

For an authorized customer device, open PowerShell locally. Replace ExampleService with the exact service name; do not use a wildcard. These commands read state and configuration without starting or stopping anything:

$serviceName = 'ExampleService'
$svc = Get-Service -Name $serviceName -ErrorAction Stop
$svc | Select-Object Name, DisplayName, Status, StartType
$svc.ServicesDependedOn | Select-Object Name, Status
$svc.DependentServices | Select-Object Name, Status
sc.exe query "$serviceName"
sc.exe qc "$serviceName"
sc.exe qtriggerinfo "$serviceName"

Use sc.exe, not the shortened sc: Windows PowerShell can interpret the latter as an unrelated alias. query reports state and exit information; qc shows the installed binary command line, account and declared dependencies. qtriggerinfo reads configured triggers; it does not explain every application’s idle policy.

ServicesDependedOn lists services this service requires. DependentServices lists services that rely on it: useful when judging the impact of a proposed restart, not a list of prerequisites to start indiscriminately.

If a read is denied, use the device’s approved administrative access. Keep account names, binary arguments and configuration paths in the private case; they can reveal sensitive information. A missing service is a naming or installation finding, not a reason to create a replacement service from memory.

2. Correlate one attempt with System and Application events

Choose a tight time window around the known attempt. This example reads the last fifteen minutes, so change the window if the incident happened earlier. It deliberately includes information events as well as errors: an orderly stop can matter too.

$since = (Get-Date).AddMinutes(-15)
$until = Get-Date
Get-WinEvent -FilterHashtable @{
    LogName = 'System'
    ProviderName = 'Service Control Manager'
    StartTime = $since
    EndTime = $until
} -MaxEvents 100 |
    Select-Object TimeCreated, Id, LevelDisplayName, Message

Get-WinEvent -FilterHashtable @{
    LogName = 'Application'
    StartTime = $since
    EndTime = $until
} -MaxEvents 100 |
    Select-Object TimeCreated, ProviderName, Id, LevelDisplayName, Message

The System query is provider- and time-bounded, not restricted to one service. Match the event’s service identity and time; do not attribute a neighboring service’s failure to your target. Application events may identify the executable, .NET exception or vendor logger. Then inspect the application’s documented log location for the same attempt.

The 100-event cap keeps the initial read manageable. If a busy machine reaches it, narrow the time range or use the identified application provider before concluding that evidence is missing. No matching events, an unreadable log and an application that does not log are different findings. None proves health. Keep original logs intact; redact secrets and unrelated customer information before sharing excerpts.

Let the specific error choose the next check

Microsoft’s system error definitions distinguish several superficially similar failures:

  • 1053: the service did not respond to a start or control request in time. Investigate slow or blocked initialization and its logs; do not begin by extending a machine-wide timeout.
  • 1067: the process terminated unexpectedly. Find the application exception or crash evidence; the code alone does not identify the faulty setting.
  • 1068: a dependency service or group failed to start. Inspect that named prerequisite and its own evidence rather than starting every stopped service.
  • 1069: service logon failed. Check the configured identity and the organization’s account-management procedure. Do not replace it with a privileged account to make the message disappear.

A zero exit code is not proof that useful work completed. It can accompany an orderly stop, including a hosted worker stopping after an exception.

3. Check the service context, not just your interactive session

A program that works from your desktop can fail as a service. Your terminal’s current directory, mapped drives, credentials and profile are not evidence that the configured service account can read the same files or reach the same share.

Start with the binary command line and account recorded by qc. Compare the installed configuration with the vendor’s expected paths and arguments. For a missing-file exception, establish the resolved path the service actually tried, not merely that a similarly named file exists in your own working directory.

Check only the implicated configuration file, directory or endpoint. An administrator’s successful file read does not establish service-account access. Use vendor-supported diagnostics under the existing service identity where available. LocalService, for example, presents anonymous credentials on the network; switching an application to it can change share access even though local startup succeeds.

A focused correction might be restoring one documented configuration path from a known-good backup after the log identifies that path as missing. Preserve the current configuration privately, correct only that setting through the supported editor and keep the same intended account and security controls. If the evidence instead shows malformed XML, an inaccessible dependency or a runtime mismatch, address that specific finding through the application’s supported procedure. Do not combine these into a speculative repair bundle.

If the only apparent fix requires a new account, wider permissions or replacing the installed service, stop the change and give the responsible administrator or vendor the evidence. Do not disable endpoint protection, grant broad folder access, reinstall blindly or hide the original exception behind automatic retries.

For a custom .NET worker: a running process can still have failed

Microsoft documents that, from .NET 6 onward, the default BackgroundService behavior stops the host after an unhandled worker exception. A clean host stop can leave service recovery settings without the failure signal a developer expected. The current Windows-service tutorial uses .NET 10 examples and describes this distinction.

Find the first logged worker exception before changing recovery behavior. Making the host ignore exceptions can leave a process running without useful work. If you own the source, correct the evidenced initialization or worker fault and test the intended lifetime, cancellation and failure reporting on a supported runtime. If it is a vendor service, escalate the exception and exact version instead of applying a generic code fix.

4. Verify the correction with one real operation

Before starting the service, confirm that this is a suitable customer-approved maintenance window and review dependent-service impact. Starting a backup or integration service may immediately launch real work. Do not replay an operation whose earlier outcome is uncertain.

For a stopped service that is expected to run continuously, use the application’s supported start procedure once. If that procedure is an ordinary service start, an authorized administrator can run:

$verificationStart = Get-Date
Start-Service -Name $serviceName -ErrorAction Stop
Get-Service -Name $serviceName |
    Select-Object Name, Status
sc.exe query "$serviceName"

A returned Running state is only the first check. Complete one approved operation that previously failed: for example, process a designated test input without touching production data, or use the vendor’s health check. Observe through the previous failure interval or one documented work cycle, then re-read state and events from $verificationStart onward. For a trigger-started service, verify its trigger and completed work; it may correctly stop afterward.

Leave the case with the original error and timestamp, the single correction, private backup or rollback location, successful check and observation interval. Record unresolved access or application failures plainly. If the service stops again, keep that second attempt’s evidence and investigate it; a restart loop is not verification.

Keep the evidence chain with the device work

In OpalSpan, Mech lets a technician direct authorized device work in a browser conversation and review findings in the case context. A useful request is: inspect this named service and the incident window without changing it, identify the narrowest supported correction, then report what the subsequent authorized verification establishes. That is a workflow example, not a claim that this article’s incident was repaired by OpalSpan.

An external assistant can also operate OpalSpan Agent CLI with the same user permissions; the technician does not have to operate that CLI manually. OpalSpan supports Windows and Linux; macOS is a technical preview, in active development. This Windows diagnostic procedure is not a Linux or macOS service recipe, and OpalSpan does not guarantee a repair or replace every capability in an existing RMM stack.

See how OpalSpan fits one support job.

Sources and scope

Technical references checked 13 October 2026. This is an original diagnostic guide prompted by a real question, not a reproduction of forum answers or proof of search volume.