Skip to content

SysManager 1.52.83

Choose a tag to compare

@github-actions github-actions released this 10 Jul 13:14
· 710 commits to main since this release
c2ef6d7

What's new for you

Cancelling an Ookla speed test while it's still downloading the test tool now shows a clean "Cancelled" instead of a confusing error message. A couple of edge cases where cancelling could leave a stray helper process or surface the wrong message have also been closed.


[1.52.83] - 2026-07-10

Fixed

  • Cancelling an Ookla speed test during the first-run CLI download was misreported as an error instead of "Cancelled". RunOoklaAsync wrapped the prepare phase (EnsureOoklaAsync — download, extract, signature-verify) in a blanket catch (Exception) that re-threw everything as InvalidOperationException("Could not prepare Ookla CLI: …"). Because OperationCanceledException derives from Exception, a user cancel during the download/extract was converted into that error type, bypassing the ViewModel's dedicated catch (OperationCanceledException) { OoklaStatus = "Cancelled"; } handler — the user saw Error: Could not prepare Ookla CLI: A task was canceled. for a clean cancel. Cancellation now propagates untouched when the caller's token is signalled (an OperationCanceledException without the token signalled — HttpClient's internal 2-minute timeout — is reported as a truthful "download timed out" error), and the wrapping catch carries a when (ex is not OperationCanceledException) filter so cancellation can never be swallowed again.
  • A failed cancel-kill of speedtest.exe could mask the cancellation and escape as an unhandled error. The cancel path killed the child with proc.Kill(entireProcessTree: true) but only caught InvalidOperationException. Kill(entireProcessTree: true) also throws Win32Exception (process access-denied/terminating) and AggregateException (a descendant couldn't be terminated) — either one propagated instead of the intended throw;, so the original OperationCanceledException was lost and an exception type the caller doesn't handle escaped RunOoklaAsync entirely. Now uses the same three-exception filter as PowerShellRunner's cancel-kill (InvalidOperationException or Win32Exception or AggregateException). The analogous schtasks timeout-kill in StartupService.SetTaskSchedulerEnabledAsync had the same gap — a Win32Exception from Kill() escaped to the outer catch, which mislabeled the timeout as "schtasks not available"; it now uses the same filter and reports the truthful "timed out" status.

Verify the download

Get-FileHash .\SysManager-v1.52.83.exe -Algorithm SHA256

Expected SHA256: FACBFA56E755B3F20AA03954FBE4A11B0BE9B5970A9D591548C87AD25F34A6F7