Hey all
Is anyone else seeing Splashtop Streamer consuming lots of CPU on servers since a few days ago?
We have it happening across multiple customers and so far only seems to affect servers.
I wonder if there was a new version pushed out or something!
Stopping and disabling the server helps until it auto restarts!
So I am having to uninstall it on affected servers!
Yes, I’ve just seen this on two separate workstations in the last 24 hours. I’ve just opened a ticket with support.
Thanks, Donogh. At least it’s not just me 
I have created a support case too. Hope they can get it sorted quickly. I have customers burning through Azure credits because of this!
Yes, not ideal! I’ve also gone ahead and removed the splashtop agent from all devices for the time being.
This is supposed to be fixed with version 3.5.8.0.
Hi Isaacg
Will this automatically update?
Please can you tell me how to force an update via Syncro?
Regards
Ben
It does eventually, but it’s slow to update. I posted over here. https://community.syncromsp.com/t/version-information-for-syncrormm-and-splashtop/11437/2
Thanks, Jimmi
Fingers crossed v3.5.8.0 sorts the problem out.
I can confirm the community script to redeploy Splashtop works too, but not on mass, as the download gets throttled by Splashtop servers!
Yeah, that just started happening a couple of weeks ago. So now I’m having to attach it as a script file instead.
We fixed this issue. We ran a script MSP wide to uninstall the Splashtop Streamer and remove the UUID from the asset details (THIS PART IS IMPORTANT). Then sent another script to Force Sync. This allowed Syncro to reinstall and reconfigure, and the CPU usage is back to normal.
Would it be possible to share this script? Thanks.
This is an issue we started having yesterday. Thought it was only on a couple of old computers, but I can confirm that it is happening across all of our clients, workstations and servers alike. Whatever SRAgent.exe is doing, Sentinel One doesn’t’ like it and is monitoring the Splashtop process constantly, which is causing even more slowdowns. Glad to know that we are not the only ones with the problem. We were able to make a asset policy to just disable the agent, but that’s not a fix. If that script mentioned above would fix the issue, it would be great to get a copy of that.
Jimmie has put the script on this thread
https://community.syncromsp.com/t/version-information-for-syncrormm-and-splashtop/11437/2
We run this on every machine, and it just takes care of the uninstallation and the force sync. One run and problem solved. Also, be sure to give it at least a 3-minute runtime for the slower machines.
Edit: Keep in mind, this fixes the issue if Syncro is providing the Splashtop. If you have BYO Splashtop, then replace the first part of the script with the one shared above by @ben2.
Import-Module $env:SyncroModule
# Uninstall Splashtop Streamer
$Program = "Splashtop Streamer"
$INSTALLED = Get-ItemProperty HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall\* | Select-Object DisplayName, UninstallString
$INSTALLED += Get-ItemProperty HKLM:\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\* | Select-Object DisplayName, UninstallString
$SEARCH =$Program
$RESULT =$INSTALLED | ?{ $_.DisplayName -ne $null } | Where-Object {$_.DisplayName -match $SEARCH }
Write-Host "We fould the following program match: $RESULT"
if ($RESULT.uninstallstring -like "msiexec*") {
$ARGS=(($RESULT.UninstallString -split ' ')[1] -replace '/I','/X ') + ' /q'
Start-Process msiexec.exe -ArgumentList $ARGS -Wait
} else {
Start-Process $RESULT.UninstallString /VERYSILENT -Wait
}
# Clear Streamer UUID
Set-Asset-Field -Name "Splashtop UUID" -Value ""
# Force Sync
$UpdateTime = (Get-Date).ToUniversalTime().AddMinutes(5).ToString("yyyy-MM-ddTHH:mm:ss.0000000Z")
#Update Syncro last_sync registry value
Set-ItemProperty -Path "HKLM:\SOFTWARE\WOW6432Node\RepairTech\Syncro" -Name "last_sync" -Value "$UpdateTime"
function Run-InNewProcess{
param([String] $code)
$code = "function Run{ $code }; Run $args"
$encoded = [Convert]::ToBase64String( [Text.Encoding]::Unicode.GetBytes($code))
start-process -WindowStyle hidden PowerShell.exe -argumentlist '-windowstyle','hidden','-noExit','-encodedCommand',$encoded
}
$script = {
$CurrentDateString = (Get-Date).ToString("yyyyMMdd")
$LogLocation = "C:\ProgramData\Syncro\logs\$CurrentDateString-Syncro.Service.Runner.log"
try {
Import-Module $env:SyncroModule -erroraction stop
}
catch {
$env:RepairTechUUID = (Get-ItemProperty -Path "HKLM:\SOFTWARE\WOW6432Node\RepairTech\Syncro" -Name "uuid").uuid
$env:RepairTechApiBaseURL = "syncromsp.com"
$env:RepairTechApiSubDomain = (Get-ItemProperty -Path "HKLM:\SOFTWARE\WOW6432Node\RepairTech\Syncro" -Name "shop_subdomain").shop_subdomain
$env:RepairTechFilePusherPath = "$($env:PROGRAMDATA)\Syncro\bin\FilePusher.exe"
Import-Module "$($env:PROGRAMDATA)\Syncro\bin\module.psm1" 3>$null
}
Start-Sleep -s 10;
Restart-Service -Name "Syncro" -Force
Log-Activity -Message "Restarted Syncro Service for Full Sync" -EventName "SyncroRestart"
# Hack to get Get-Content -wait to work properly
$hackJob = Start-Job {
$f=Get-Item $LogLocation
while (1) {
$f.LastWriteTime = Get-Date
Start-Sleep -Seconds 1
}
}
# Job that confirms if the sync happened
$job = Start-Job { param($LogLocation)
try {
Import-Module $env:SyncroModule -erroraction stop
}
catch {
$env:RepairTechUUID = (Get-ItemProperty -Path "HKLM:\SOFTWARE\WOW6432Node\RepairTech\Syncro" -Name "uuid").uuid
$env:RepairTechApiBaseURL = "syncromsp.com"
$env:RepairTechApiSubDomain = (Get-ItemProperty -Path "HKLM:\SOFTWARE\WOW6432Node\RepairTech\Syncro" -Name "shop_subdomain").shop_subdomain
$env:RepairTechFilePusherPath = "$($env:PROGRAMDATA)\Syncro\bin\FilePusher.exe"
Import-Module "$($env:PROGRAMDATA)\Syncro\bin\module.psm1" 3>$null
}
Get-Content $LogLocation -tail 0 -wait | where { $_ -match "Large sync complete" } |% { Log-Activity -Message "Full Sync Successful" -EventName "SyncroFullSync"; break }
} -Arg $LogLocation
# Wait for the Activity-Log job to complete or to timeout
Wait-Job $job -Timeout 60
# Cleanup jobs
Get-Job | Stop-Job
Get-Job | Remove-Job
}
Run-InNewProcess $script | Out-Null
Exit 0
I heard it has something to do with an increase in logging, which makes sense for an AV to have an increase in activity on the process.
Thanks, both versions of the script are on that post. Personally, I’d use the URL in the first script, download the EXE and attach it as a script file to use for the second method. The URL is giving 403’s when running in bulk, and it’s the same URL that Syncro is using in their script.
Eh, not really needed, you can run the install over itself and it updates without needing to uninstall. The good thing about the update script is it works with both RMM, and BYO without interfering with BYO settings. It’s also good if you are having issues connecting to a machine, it will reinstall over the top and fixes it in a most cases.
If you use the EXE to perform the uninstall, it will remove the registry entries, including the UUID.
start-process -wait -Filepath $file -ArgumentList "msiexec /qn /x setup.msi"Oh wow, I see. I did not know you could get the installer without a deployment code attached. We use t have BYO, so I thought the link needed to be your own installer. It’s a universal. Well, going to fix mine now too. Thanks for the updated information.
How do you get the universal MSI installer without a BYO account?
Yea that does make a lot of sense. Luckily, the update script here on the thread seems to be correcting the issues on the problematic computers.