Seems it changed in: lib: Return error from db.FileSet.Snapshot (fixes #7419, ref #5907) (… · syncthing/syncthing@310fba4 · GitHub
It no longer returns empty completion, but returns a 404 now.
Thanks for the hint. This seems to be the culprit. Then I’ll just refrain from querying this for paused directories and devices.
To follow up on my previous idea: It looks like Syncthing itself allows to dump events via the -audit CLI option. I haven’t tried it myself but this kind of log would be useful. Maybe I can make Syncthing Tray consume such a log instead of polling for real events to ease testing/reproducing. Of course I also needed the config and answers to other REST-API calls.
I have just had the same crash today, on the very same machine. This is strange, because I had had no such crashes in the past, and the device configuration itself has not really changed since then. Syncthing Tray at the moment is v1.1.5 (Qt 6).
The crash seems to be happening with no particular reason after several days of working fine. This time it was 4 days. Also, it happens when the machine is idle, and nothing special goes on then, except for Syncthing working in the background.
Just in case, if there existed some kind of a debug build that could help diagnose this kind of problems, then I would be glad to test it 
.
Under GNU/Linux (with systemd) I’d just use coredumpctl to start the debugger GDB for investigating crashed applications. For better results I’d create a build with debug symbols (but maybe still with optimizations because the problem might not be reproducible anymore when turning them off).
I’m sure Windows offers something similar to investigate a crashing application. I haven’t used Windows for development for ages but I remember that it even offered one to start Visual Studio’s debugger when an application crashed. It should also be possible to conduct a debug build under Windows using GCC/mingw-w64 (e.g. via MSYS2) or Visual Studio’s C++ compiler/stl¹.
¹I’ve never been using Visual Studio to compile Syncthing Tray because as an open source project Syncthing Tray’s focus is on using open source technology. Hence you might run into configuration, compilation and runtime errors.
I have a problem with Syncthing Tray not trying to connect to Syncthing. I have both set to start on boot in Windows using the Task Scheduler. This likely means that when Syncthing Tray starts for the first time, Syncthing is not yet ready, so not being able to connect then is understandable.
However, I have also set the reconnect interval to 60000 ms, so I would expect Syncthing Tray to try to connect again later. However, it doesn’t seem to be case. Basically, Syncthing Tray seems to never re-try to connect. The only way to work around this appears to be to press “connect” manually in the GUI. Then it connects almost immediately.
The re-connect interval is a connection-specific setting so be sure that it is set for the relevant connection. Also make sure that the internal launcher’s state is not used (the check boxes in the launcher setting are unchecked). (Generally the same counts for the systemd integration.)
I have gone through the settings one more time and realised that I had forgotten to tick the “Connect automatically on startup” box on this machine 
.
Apologies for wasting your time 
.
Oh, right. In my explanation I’ve also forgotten to mention this one. No problem you’ve asked 
With Qt 6.2.0 TLS support has been pluginized so I’ve been creating a Windows build which is using Schannnel instead of OpenSSL: https://martchus.no-ip.biz/repo/arch/ownstuff-experimental/os/x86_64/mingw-w64-syncthingtray-qt6-1.1.11-1-any.pkg.tar.zst
It would be interesting to know whether this works well for you, in particular on old Windows versions. No longer bundling the security relevant OpenSSL library is obviously only an advantage if the platform’s own TLS implementation is sufficient.
I could test on Windows 7, but I’d need a 32-bit version to do it. Would it be possible to compile a 32-bit test release?
Also, if I try to download and unpack the archive linked above, I get a CRC failed error. This is in 7-Zip with a zst plugin, so I can’t say for sure whether it’s the archive or something else.
This archive contains an i686 build. I usually extract such archives via bsdtar (with zstd support) which one can easily install using MSYS2 under Windows. Otherwise I can extract the archive for you on the server.
I’ve managed to unpack with zstd 
.
However, the problem is that the binary won’t start under Windows 7 at all.
Didn’t Qt 6.0 drop support for Windows 7/8?
They did. It still kept working, at least for the subset of Qt modules/features I’ve been using. Of course it can always cease to work so an error message like that isn’t completely unexpected. Likely it is the best to simply keep supporting Qt 5 for a few years in parallel. For GNU/Linux that’s also required anyways (because KDE and a majority of style plugins likely takes a while to adapt Qt 6 and older distributions so far don’t ship Qt 6 at all).
It looks like Qt Core is linking against that DLL. So this has nothing to do with enabling Schannel. I suppose it means we’re simply out of support here and considering that Qt 5 still exists I would refrain from trying to hack around it.
I think this is some linking error, because CreateEvent located in api-ms-win-core-synch-l1-1-0.dll, not api-ms-win-core-synch-l1-2-0.dll even on Windows 10.
CreateEventA is available via both DLLs in Windows 10. It just seems a bit needless to link against the newer one of course. Not sure what configuration in Qt’s build system or mingw-w64 causes this. However, I’d like to note that it doesn’t say the DLL is missing. It just says the symbol is missing. So apparently the newer version actually exists on Windows 7 but just doesn’t contain the symbol. Not sure whether the older version would contain the symbol there.
I’ve just read the Git history of Qt (qtbase repository) between versions 6.1.3 and 6.2.0 because I believe some change in Qt caused this. (My build environment is still mingw-w64 9.0.0 and GCC 11.2.0 so nothing significant should have changed compared to my last Qt 6.1.3 build.)
I haven’t spotted the change which causes linking against api-ms-win-core-synch-l1-2-0.dll yet and likely I also won’t be able to because there were tons of build system changes. However, I found many other changes which could cause problems at runtime on older Windows versions. So maybe it is actually a good thing that startup is prevented completely because this is better than users experiencing misbehavior at runtime.
So I’ll simply document in the README that one should stick to the Qt 5 build when using older Windows versions.
I’ve just updated to v1.1.11 (Qt6) under Windows 10, and the application doesn’t connect to Syncthing anymore at all. I’m guessing that this may be related to the “Schannnel instead of OpenSSL” change you mentioned before.
I’ve switched to the Qt5 version for now, which works normally.
For the record, these are typical settings that I use (working in the Qt5 version).
