Syncthing Tray 2.0.8 Windows Crash: Isolate the Built-in

Symptoms and Exact Error

A disappearing Syncthing Tray window and notification-area icon do not prove that Syncthing itself stopped. The tray can connect to an already running Syncthing process, or it can run the built-in Syncthing supplied with the distribution. The visible symptom can look identical while the failed process and the recovery path are different.

The public issue reports Windows 11, the official syncthingtray-2.0.8-x86_64-w64-mingw32 build, the built-in Syncthing instance, and an application that closes after running for a while. That is enough to investigate the same combination, but the issue body provides no fault module, stack trace, maintainer reproduction, or linked fix. This guide therefore does not attribute the failure to a particular Go version or function.

The 2.0.9 release note states only that the built-in Syncthing library was updated to 2.0.15. It does not say that this specific Windows exit was fixed. A successful update is useful operational evidence, but it is not proof of causation on its own.

Values to Check First

Observation	Value to preserve	How it changes the diagnosis
Tray process	Executable path, file version, and exit time	Rules out testing a portable copy or an older binary by mistake.
Syncthing process	PID and survival state of a separate `syncthing.exe`	Shows whether only the tray exited or the backend exited as well.
Launch mode	Built-in library or external executable	Limits an A/B test to one changed variable.
Windows event	Provider, Event ID, faulting module, and time	Distinguishes a process error from a device connection loss.
Tray configuration	Active INI location and backup copy	Prevents a configuration reset from being mistaken for a version fix.

Record the current executable and process state first. If the tray has already exited, whether a Syncthing process remains alive is especially important.

$tray = Get-Process syncthingtray -ErrorAction SilentlyContinue
$backend = Get-Process syncthing -ErrorAction SilentlyContinue
$tray | Select-Object Id, StartTime, Path
$backend | Select-Object Id, StartTime, Path
Get-Item .\syncthingtray.exe | Select-Object FullName, LastWriteTime, VersionInfo

A regular installation normally stores tray settings in %APPDATA%\syncthingtray.ini. A portable installation can use a file with the same name next to the executable, so identify the file that is actually in use and preserve it before testing.

$config = Join-Path $env:APPDATA 'syncthingtray.ini'
if (Test-Path $config) {
    Copy-Item $config "$config.before-2.0.8-test"
}

Cause Branches

A Syncthing log entry saying that a device connection was lost describes the network or remote-device state; it does not prove a tray-process crash. By contrast, an Application Error or Windows Error Reporting event whose executable and timestamp match the exit is evidence for a process failure.

If the Syncthing Tray CLI executable is installed, run it from a console and preserve its output. The Go runtime documentation says GOTRACEBACK=wer requests an operating-system-style crash without disabling Windows Error Reporting. This setting matters only when the failure passes through the Go runtime path, and it does not guarantee a report for every possible termination.

$env:GOTRACEBACK = 'wer'
.\syncthingtray-cli.exe *> .\syncthingtray-2.0.8-crash.log

After the exit, read the Application log over a broad time window and narrow the result by executable name. If no event appears, record that no matching Windows event was found through this path; do not rewrite that result as proof that no crash occurred.

$since = (Get-Date).AddHours(-4)
Get-WinEvent -FilterHashtable @{ LogName='Application'; StartTime=$since } |
    Where-Object {
        $_.ProviderName -in @('Application Error', 'Windows Error Reporting') -and
        $_.Message -match 'syncthingtray'
    } |
    Select-Object TimeCreated, ProviderName, Id, Message

Fix Sequence

Freeze the current state. Record the tray version, executable path, Windows build, built-in Syncthing setting, and time to exit. If another copy is registered for autostart, compare paths before changing anything.
Check backend survival. If a separate syncthing.exe is still running and its web UI opens after the tray exits, do not treat the tray and backend as one failure.
Compare an external backend. Point the tray launcher to an external Syncthing executable as documented by the project. Keep folders, remote devices, and network conditions unchanged so that launch mode is the only variable.
Match the observation window. A run shorter than the usual time to failure is not a pass. Preserve the exit time and Windows events in the same format as the previous run.
Test an official update. Try 2.0.9 or later while noting that the update changes both the tray and its built-in library. Keep the updater backup described by the documentation, or a separately preserved executable, available for rollback.
Repeat the same conditions. Stability only on the newer release can justify an operational upgrade, but the public evidence still does not identify the exact faulting function.

Verification and Rollback

Only the tray exits while external Syncthing remains alive: Do not begin with database recovery. Focus on the tray executable, configuration, integration paths, and Windows event evidence.
The built-in mode alone exits: An external Syncthing process is a reasonable operational workaround. Ensure that built-in and external instances are not both configured for autostart.
Both modes exit the tray: The built-in library alone cannot explain the result. Investigate common configuration, the tray itself, security-software intervention, and the recorded fault module.
Syncthing exits while the tray remains: That is a backend failure outside this guide. Diagnose the Syncthing log and database state separately.
The issue does not recur after updating: Record an operational recovery, while also recording that the 2.0.9 release note does not explicitly claim a fix for this crash.

When ending the external-backend test, preserve enough information to restore the launcher path and autostart settings. Do not assume that a newer tray configuration or built-in Syncthing data is backward compatible. Roll back only within the settings and executable scope you preserved, and keep an independent backup of synchronized data before testing.

A useful reproduction report includes the exact executable name and version, Windows build, built-in or external mode, time to exit, faulting module, and relevant event text. Those details make it possible to decide whether the report belongs to the tray project or the Syncthing backend project.

Official Documentation and Verification Basis

Syncthing Tray issue 427 — Public report of an application exit with the official 2.0.8 build and built-in instance on Windows 11
Syncthing Tray documentation — Built-in versus external Syncthing, configuration locations, and updater backup behavior
Syncthing Tray 2.0.9 release — Release record stating that the built-in Syncthing library was updated to 2.0.15
Go runtime package documentation — Windows Error Reporting behavior of GOTRACEBACK=wer
Microsoft Get-WinEvent documentation — Querying the Application log with FilterHashtable

Earlier verification notes preserved from this article

Verification level: Official documentation cross-check

This article was directly edited against the public issue and official documentation. The failure was not reproduced on a Windows 11 test system, so observations and causal inference are kept separate.

Editorial and correction policy · Report an error

Syncthing Tray 2.0.8 Windows Crash: Isolate the Built-in Backend