Windows - Software Lifecycle - Restart Splashtop Streamer Service

What the Splashtop Streamer restart Worklet does

This Automox Worklet™ watches the SRServer process on Windows endpoints and recycles the Splashtop Streamer Service through the Service Control Manager whenever that process is missing. SRServer is the listener that accepts incoming Splashtop sessions, so an endpoint where the process is absent is effectively offline from the perspective of a remote support technician even though the Windows host itself is healthy.

The evaluation script runs Get-Process -Name SRServer and exits 0 when the listener is up or exit 2 when it is missing. The remediation script resolves the service through Get-Service -Name "Splashtop Streamer Service", calls Restart-Service with the -Force flag to terminate any dependent handles, sleeps for 10 seconds to let the service spin up, and then re-queries Get-Process to confirm SRServer is back. Exit codes 0, 1, and 2 from remediation map to success, service-not-installed, and process-failed-to-start respectively, and each path writes a Write-Output line that surfaces in the Automox activity log.

The Worklet is idempotent. When SRServer is already running on the next evaluation, no remediation runs and the endpoint is reported compliant. The pattern fits a recurring policy that wakes hourly or on a schedule that matches your support team's working hours, so a Splashtop listener that dies overnight is back online by the time the first ticket arrives.

Why recycle the Splashtop Streamer service at fleet scale

Splashtop is the remote access channel that an MSP or internal IT operations team uses to reach a Windows endpoint that the end user cannot drive themselves. When the Splashtop Streamer Service stops, the SRServer process exits, and the endpoint disappears from the Splashtop console. Service exits happen for predictable reasons: a Windows cumulative update restarted dependencies in the wrong order, an antivirus scan suspended the binary, a low-memory event killed long-running processes, or the Splashtop Streamer installer upgraded the client without re-arming the service. None of those failures are visible to the end user; they only become visible the first time someone needs to open a session and finds the endpoint offline.

Scheduling this Worklet against the Windows fleet recycles the Splashtop Streamer Service on every endpoint where SRServer is missing, restoring the remote support channel before a technician realizes it was down. A workstation that lost the listener during a Patch Tuesday cumulative update, a server where an antivirus scan suspended the binary, and a remote employee laptop where Splashtop Streamer upgraded itself without re-arming the service all converge on a running SRServer in the same policy pass. Recurring evaluation catches the next service exit on its next hourly run.

How the Splashtop Streamer service restart works

1. Evaluation phase: The evaluation script runs Get-Process -Name SRServer -ErrorAction SilentlyContinue against the local process table. If the SRServer process is present, the Worklet writes "Splashtop process (SRServer) is running." and exits 0, marking the endpoint compliant. If the process is missing, it writes "Splashtop process (SRServer) is NOT running." and exits 2, which flags the endpoint for remediation on the next policy cycle.

2. Remediation phase: The remediation script calls Get-Service -Name "Splashtop Streamer Service" to confirm the service is installed. If the service object is null, the script writes "Splashtop Streamer service not found." and exits 1 so you can route those endpoints to a Splashtop installer policy. If the service is installed, the script runs Restart-Service -Name "Splashtop Streamer Service" -Force, sleeps 10 seconds with Start-Sleep -Seconds 10 to allow the Service Control Manager to bring SRServer back, and re-runs Get-Process -Name SRServer. The Worklet exits 0 on a confirmed restart or exit 2 if the process still fails to appear, and both paths are written to the activity log.

Splashtop Streamer restart requirements

• Windows endpoint in WORKSTATION or SERVER mode with the Splashtop Streamer Service registered in the Service Control Manager

• Splashtop Streamer client already installed; this Worklet recycles the service rather than deploying the binary

• PowerShell 3.0 or later; Get-Process, Get-Service, and Restart-Service are built-in cmdlets available in all supported Windows versions

• The Automox agent runs as SYSTEM by default, which holds the rights needed to call Restart-Service against any registered Windows service

• No Worklet variables to configure; the SRServer process name and the Splashtop Streamer Service display name are hard-coded to match Splashtop's installer defaults

• RunNow compatible, so the Worklet can run on demand from the Automox console against a single endpoint without waiting for the next policy window

Expected Splashtop connectivity after remediation

After a successful remediation, services.msc shows the Splashtop Streamer Service in the Running state and Get-Process -Name SRServer returns a process object with a non-zero Id. The Splashtop console reports the endpoint as online within a few seconds of the service starting, and an authorized technician can open a remote session without asking the end user to reboot, log out, or click anything. The remediation activity log entry reads "Splashtop SRServer restarted successfully." with exit code 0.

Validate the restoration by running Get-Service -Name "Splashtop Streamer Service" | Select-Object Status, StartType from a local PowerShell prompt and confirming Status is Running and StartType is Automatic. For a fleet-level check, query the Automox activity history for the Worklet over the last 24 hours; recurring exit-2 results on the same endpoint indicate a deeper failure (corrupted Splashtop installation, missing dependency, antivirus quarantine) that needs a reinstall rather than a service restart. Pair this Worklet with a deployment policy that installs or reinstalls Splashtop Streamer when remediation exits 1, so a single Automox group covers both the recovery and the install paths for the remote support channel.