Duplicati Server Crashes Every Minute

This morning I noticed that my Duplicati server was crashing when it initiated its backup to Backblaze. Every minute it was crashing and this is in the event viewer:

Application: Duplicati.Server.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: System.InvalidOperationException
   at System.Threading.Tasks.TaskCompletionSource`1[[System.Boolean, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]].SetResult(Boolean)
   at System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
   at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
   at System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem()
   at System.Threading.ThreadPoolWorkQueue.Dispatch()

This is on a Windows 10 machine. If I run the backup manually, it works fine. It also ran a local backup to my Synology NAS without issue. For some reason the server executable is giving up on this.

Same issue here.

I’ve run duplicati for several weeks now without problems. Today I found that the tray icon was missing. After relaunching duplicati it works for a few seconds before it crashes silently again. Error messages in the event viewer (also Windows 10 machine) are similar to that posted by @jmartin82

Anwendung: Duplicati.GUI.TrayIcon.exe
Frameworkversion: v4.0.30319
Beschreibung: Der Prozess wurde aufgrund einer unbehandelten Ausnahme beendet.
Ausnahmeinformationen: System.InvalidOperationException
   bei System.Threading.Tasks.TaskCompletionSource`1[[System.Boolean, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]].SetResult(Boolean)
   bei System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
   bei System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
   bei System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem()
   bei System.Threading.ThreadPoolWorkQueue.Dispatch()

and

Name der fehlerhaften Anwendung: Duplicati.GUI.TrayIcon.exe, Version: 2.0.2.1, Zeitstempel: 0x5980511c
Name des fehlerhaften Moduls: KERNELBASE.dll, Version: 10.0.16299.15, Zeitstempel: 0x4736733c
Ausnahmecode: 0xe0434352
Fehleroffset: 0x0000000000013fb8
ID des fehlerhaften Prozesses: 0x3520
Startzeit der fehlerhaften Anwendung: 0x01d3a66c8dba6f8e
Pfad der fehlerhaften Anwendung: C:\Program Files\Duplicati 2\Duplicati.GUI.TrayIcon.exe
Pfad des fehlerhaften Moduls: C:\WINDOWS\System32\KERNELBASE.dll
Berichtskennung: 6c1ae8ec-8c82-4b5f-8bc0-d502463cd254
Vollständiger Name des fehlerhaften Pakets: 
Anwendungs-ID, die relativ zum fehlerhaften Paket ist:

This is a guess based on the “every minute” comment but can you both (@jmartin82 & @Joerg) try setting Usage Logging (see main Settings menu) to None / Disabled?

It’s possible you’re running into this recently seen issue:

(Oh, and I edited both your posts by putting “~~~” before / after the error messages to make them easier to read.)

Thanks a lot for your answer!!! Problem seems to be solved here!

Just before you wrote your reply I deleted the dupl-usagereport-* files from the %temp% directory and that seems to have helped.

Now I also disabled Anonymous usage reports as you said. Many thanks to your quick answer, @JonMikelV !!!

Glad to hear it! Note that the it sounds like the next canary release will include a workaround for this issue (too many pending usage reports) so hopefully disabling usage reporting won’t have to be done for much longer.

I can report that this also helped me out. I only had about ten of the usage reports, but I deleted them and disables them in settings.

I had to fix another workstation this week with that environment variable fix I saw earlier, which I think is related to this same error. Really hope this doesn’t hit more of my workstations!

Thanks for the confirmation!

While it appears the issue is related to having too many usage reports queued up, I’m still not sure exactly why some users are having issues connecting.

Some evidence points to proxy servers but I think users who have had no issues in the past are suddenly having them as well, so unless something has changed out in internet proxy land there may be multiple sources of the problem.