A process that starts and exits within seconds with no window is a crash during startup, before the UI is created. That narrows it a lot, because only a handful of things run before the first window paints.
Get the actual error first. These apps are almost all built on a web-engine shell, and every one of them writes a log. Two ways in, in order of usefulness:
- Launch it from a terminal instead of the icon. The startup exception is very often printed to standard error and simply thrown away when you launch from the desktop. This one step solves most of these.
- Find the log directory. These shells use a conventional per-user application data location per operating system — an app-data folder on Windows, an application support folder on macOS, a config or share directory under your home on Linux. Look for a
logs folder under the app's own directory there, sorted by modification time.
With the message in hand it is usually obvious. Without it, work through the four things that cause this, in this order:
1. Corrupted local application data. The overwhelming favourite, and it fits "worked yesterday, reinstalling did not help" exactly — because uninstalling does not remove the per-user data directory, so the reinstall dutifully loaded the same broken state. A partial write during a crash or an update leaves the cache or the local database inconsistent, and the app dies reading it.
The fix is to move that directory aside — rename, do not delete — and start the app. If it opens, you have your answer and you still have the old directory to recover data from.
2. GPU acceleration. A driver update, or a change of external monitor, and the shell crashes creating its rendering surface. Every one of these apps accepts a command-line flag to disable GPU acceleration; launch it once with that flag and see. If it opens, turn hardware acceleration off in its settings and it will keep working.
3. A proxy or TLS interception in the way. Many of these apps make a network call during startup — sign-in, sync, a licence check — and some handle a failure at that point very badly. On a corporate network with an intercepting proxy, the app cannot validate the certificate, the startup promise rejects, and nothing ever renders. Test on a different network, or on a phone hotspot, and if it opens you know.
4. Antivirus or endpoint protection. It quarantined part of the app or blocks its helper process. This produces exactly the silent instant exit. Check the protection software's quarantine log for the app's name — that is a thirty-second check that occasionally is the whole answer.
On getting your collections out, which is the actually urgent part: they are in that same per-user data directory, usually in a local database file. Before you do anything at all — before renaming, before reinstalling again — copy that entire directory somewhere safe. It is small. Then you can experiment freely.
If the app never opens again, the data is still recoverable from that copy: these local stores are usually a well-known embedded database format, readable with ordinary tools, and the requests are typically stored as documents you can pull out and reshape into an import file.
And if you had signed in and sync was enabled, your collections are on the server too and the fastest route back to working is the web version or a fresh profile.