The extra processes are caused by the updater.
When Duplicati starts, it spins out a new process. If there are no updates, this new process is running the same executable as the main process. If there is an update, the spawned process is the updated executable.
Previously, Duplicati relied on “AppDomains” to spin up the new version inside the same process, but that was buggy, and .Net seems to abandon this idea, as it was “complicated”.
When running as a Windows service, there is a special executable that is responsible for interacting with the Windows Service system, Duplicati.WindowsService.exe, which basically listens for the service start/stop signals and writes to the event log. This executable then starts the real Dupicati.Server.exe (updated executable) and forwards the start/stop signals.
The tray-icon the starts and connects to the server process, also using an updated executable, if one is found.
So in total, this setup would give 2x WindowsService, 1x Server and 2x TrayIcon = 5x processes.
Unlike most auto-updates systems, Duplicati’s approach allows you to install an update “over” an existing installation, allowing roll-backs as well, without needing administrator privileges.
The downside to this is having an extra “entry” process (and 2 of those in the service/client scenario).
If you do not want to use the auto-updater system, and just install the new MSI, you can set the environment variable AUTOUPDATER_Duplicati_SKIP_UPDATE=1 on the system, and it will bypass the auto-update system and only run a single process (leaving you with 3x processes for the service/server/trayicon setup).