Installed New Version - Now Duplicati Won't Run

Support
1

Running Windows 10 64 bit.

The Duplicati tray icon popped up with a message that a new version was ready today (beta 2.5.something). I went ahead and hit the download button, and then hit the “Activate” button. The web interface disconnected and now it won’t reconnect at all.

I tried restarting the computer, and nothing. The Duplicati tray icon is missing now, and when I try to run Duplicati.GUI.TrayIcon.exe nothing happens (I see it pop up in the process list for a second, then it disappears).

Any ideas?

2

Just tried to run it from the command line to see if I get any errors, and I do:

C:\Program Files\Duplicati 2>Duplicati.GUI.TrayIcon.exe

C:\Program Files\Duplicati 2>Unexpected error: System.IO.FileLoadException: Could not load file or assembly ‘Newtonsoft.
Json, Version=10.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed’ or one of its dependencies. The located assemb
ly’s manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
File name: ‘Newtonsoft.Json, Version=10.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed’ —> System.IO.FileLoad
Exception: Could not load file or assembly ‘Newtonsoft.Json, Version=12.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b
2a6aeed’ or one of its dependencies. The located assembly’s manifest definition does not match the assembly reference. (
Exception from HRESULT: 0x80131040)
File name: ‘Newtonsoft.Json, Version=12.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed’

WRN: Assembly binding logging is turned OFF.
To enable assembly bind failure logging, set the registry value [HKLM\Software\Microsoft\Fusion!EnableLog] (DWORD) to 1.
Note: There is some performance penalty associated with assembly bind failure logging.
To turn this feature off, remove the registry value [HKLM\Software\Microsoft\Fusion!EnableLog].

at Duplicati.GUI.TrayIcon.HttpServerConnection.PerformRequestInternal[T](String method, String endpoint, Dictionary2 queryparams) at Duplicati.GUI.TrayIcon.HttpServerConnection.PerformRequest[T](String method, String urlfragment, Dictionary2 quer
yparams)
at Duplicati.GUI.TrayIcon.HttpServerConnection.UpdateStatus()
at Duplicati.GUI.TrayIcon.HttpServerConnection…ctor(Uri server, String password, Boolean saltedpassword, PasswordSou
rce passwordSource, Boolean disableTrayIconLogin, Dictionary2 options) at Duplicati.GUI.TrayIcon.Program.StartTray(String[] _args, Dictionary2 options, String toolkit, HostedInstanceKeepe
r hosted, String password, Boolean saltedpassword)

3

Assembly errors are not my area of expertise, but to gather info, what was your old Duplicati version?
C:\Program Files\Duplicati 2\changelog.txt will have that information at its top, because the update is written to (probably) C:\ProgramData\Duplicati\updates, where the old version finds it and launches it.

There were some early September Canary releases that had symptoms similar to your assembly one, and I don’t know if there is some way that a latent Program Files problem could relate to update issue.

Easy downgrade may or may be possible depending on what your previous version is. Fortunately the update looks like it might not have run far enough to upgrade the databases and block the downgrade. Seeing new backup files in your %LOCALAPPDATA%\Duplicati folder would mean it updated that DB.

Downgrading / reverting to a lower version talks about downgrading by removing new version’s folder, however another option would be to install Duplicati from the .msi file to see whether it starts properly.

Having installed 2.0.5.1 in Program Files, you could also remove it from the updates folder to be sure there’s nothing odd resulting from the two-step Duplicati launch design. Ideally an expert would arrive, and debug it better than I’m doing, but I don’t know how urgently you need to get backup going again.

4

I did some poking around and it looks like Duplicati.GUI.TrayIcon.exe wasn’t updated during the integrated update process (it was still showing 2.0.4.something for the version number).

I downloaded a fresh copy of 2.0.5.1 from the Duplicati website and reinstalled it over top of the existing installation. This time Duplicati.GUI.TrayIcon.exe was updated to the current version and things seem to be working properly again.

5

I’m glad you got it working, but it would be gather some more specifics about what went wrong.

Which one? As mentioned, nothing in C:\Program Files\Duplicati 2 is supposed to be updated.
Instead, C:\ProgramData\Duplicati\updates\2.0.5.1 is supposed to get an entirely new version.

Starting Duplicati starts the Program Files version, which then locates and starts the new one.
You can see paired Duplicati processes (for most of its programs) if you look in Task Manager.
Sysinternals Process Explorer can show the actual executable paths, e.g. if you mouse-hover.

Your description sounds like your .msi install overwrote Program Files (as it should), updating Duplicati.GUI.TrayIcon.exe (and wrote over the old changelog.txt – what WAS prior version?).

You possibly still have your updates folder, but I think Duplicati won’t use it, as it’s also 2.0.5.1.
This folder is supposed to be very carefully (and sometimes slowly) checked before running it.
Contents should be identical to Program Files folder version, I think, unless in –portable-mode.

Does any of this match what happened, what was prior version, and any other clues on issue?

6

Good morning,

I’m also experiencing this issue, while upgrading from 2.0.4.23_beta_2019-07-14. During installation, the web page lost connection to the service. After waiting several minutes the connection wasn’t re-established, so I decided to reboot. This didn’t solve the issue (tray icon still missing). So, I came here to determine if it is a known problem.

Reading here, I discovered C:\ProgramData\Duplicati\updates\2.0.4.5\Duplicati.GUI.TrayIcon.exe and launched it. This seemed to correct the issue as the tray icon re-appeared and the web interface reported the new version. At this point I decided to reboot the computer to see if this fully corrected the problem. After the reboot, the tray icon was still present and the web interface was connected to the server. However, the version reported by the web interface has reverted to 2.0.4.23_beta_2019-07-14.

Poking around a bit, I found C:\ProgramData\Duplicati\updates\Duplicati-crashlog.txt that was created this morning. Since I can’t upload a *.TXT file, here are the contents:

System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.AggregateException: One or more errors occurred. ---> System.IO.FileLoadException: Could not load file or assembly 'Newtonsoft.Json, Version=10.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040) ---> System.IO.FileLoadException: Could not load file or assembly 'Newtonsoft.Json, Version=12.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
   --- End of inner exception stack trace ---
   at Duplicati.Library.UsageReporter.EventProcessor.<>c__DisplayClass8_0.<<Run>b__0>d.MoveNext()
   at System.Runtime.CompilerServices.AsyncTaskMethodBuilder.Start[TStateMachine](TStateMachine& stateMachine)
   at Duplicati.Library.UsageReporter.EventProcessor.<>c__DisplayClass8_0.<Run>b__0(<>f__AnonymousType0`2 self)
   at CoCoL.AutomationExtensions.<RunTask>d__10`1.MoveNext()
   --- End of inner exception stack trace ---
   at System.Threading.Tasks.Task.ThrowIfExceptional(Boolean includeTaskCanceledExceptions)
   at System.Threading.Tasks.Task.Wait(Int32 millisecondsTimeout, CancellationToken cancellationToken)
   at System.Threading.Tasks.Task.Wait(TimeSpan timeout)
   at Duplicati.Library.UsageReporter.Reporter.ShutDown()
   at Duplicati.Server.Program.RealMain(String[] _args)
   --- End of inner exception stack trace ---
   at System.RuntimeMethodHandle.InvokeMethod(Object target, Object[] arguments, Signature sig, Boolean constructor)
   at System.Reflection.RuntimeMethodInfo.UnsafeInvokeInternal(Object obj, Object[] parameters, Object[] arguments)
   at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
   at Duplicati.Library.AutoUpdater.UpdaterManager.RunMethod(MethodInfo method, String[] args)

My software:
Edition: Windows 10 Pro
Version: 1809
Installed on: 9/28/2019
OS build: 17763.914

My hardware:
Processor: Intel® Core™ i7-7820HK @ 2.90GHz
RAM: 32.0 GB
System type: 64-bit operating system, x64-based processor

I’ll hold off re-installing Duplicati for a bit, in case there’s anything else you may want/need from my system to aid your research.

Thanks,

7

It was the one in C:\Program Files\Duplicati 2. I had no idea that when the upgrade occurred it wouldn’t actually upgrade the files in the main Duplicati 2 folder, so I didn’t even check the updates folder. I assumed the updates folder was just a temporary staging area for the downloaded files. I don’t think I’ve ever seen a program updater that doesn’t update the original program files.

Duplicati.GUI.TrayIcon.exe was showing in task manager and immediately closing. No other Duplicati processes were launching.

It looks like it was 2.0.4.23. I see 3 folders in the updates folder: 2.0.4.5, 2.0.4.23, and 2.0.5.1. So it would appear that 2.0.4.23 would be the prior version.

My guess is that the update installer didn’t have the right Newtonsoft.Json.dll file, and that’s why it wouldn’t run. Doing a regular install fixed the DLL problem.

I’m guessing the update installer works differently than the regular installer (as the regular installer uses the primary Duplicati 2 folder, and not the updates folder).

8

I likely don’t know all the reasons, but I think a goal was to avoid needing administrative permissions such as the Linux root password or the password for a Windows account in the Administrators group.

What has actually happened is that autoupdate has had some troubles. Windows service requires a restart of service (or Windows) to activate, and I’m seeing some sign (like you) of a broader problem.

Release: 2.0.3.13 (canary) 2018-10-31

Added code to allow the Windows Service to correctly autoupdate

2.0.3.14-2.0.3.14_canary_2018-11-08

Removed the WindowsService restart fix as it did not work as expected

Activate downloaded upgrade sometimes fail was technical discussion, and issue seems worse now because TrayIcon previously seemed OK, and now it seems to have the same problem as Service…

What I haven’t been able to get is a “won’t run” after getting fresh .msi install, then update to 2.0.5.1.

Tried 2.0.4.23 Beta (previous latest Beta), 2.0.4.26 Canary (from September “assembly” fixing days), and 2.0.4.30 Canary. I can get “Activate” button to not bring Duplicati back up, but manual works fine. Rebooting also works. None of this was a Windows service, just the default .msi install and TrayIcon.

If you found 2.0.4.5 in the updates folder, possibly your Program Files was 2.0.3.3, the Beta before it. That’s one I haven’t tried yet.

If the folder is still there, you can compare it to the Program Files view of 2.0.5.1 for that file, but I think these all start from the same bunch of files, before diverging into .msi, .zip, and format for autoupdater.

I’m neither a build expert nor an assembly expert.

9

I had a similar problem, The interface would work once, but would not do anything after that except wink at me without killing the services.

I discovered duplicati processes were still running in the task manager / details area.

Once I killed the old tasks ( i assume spawned from the old version ), everything worked swell.

Please consider to kill or prompt to kill the currently running processes when upgrading.

Best regards and keep up the good work. Great product.

1 Like
10

Crash after update to “2.0.5.1 (2.0.5.1_beta_2020-01-18)” is another attempt to isolate the problem, including trying to learn what old versions might be in various places that might be causing an issue.

Not starting after update #4060 is the (only, I think) GitHub report of this problem, which is elusive…
I installed as far back as 2.0.3.3 in Program Files, underneath the 2.0.5.1 update, and it started fine.

Maybe the “assembly bind failure logging” mentioned would help, but I can’t explain how to run that.
Still hoping that someone who understands assembly binding will show up to help sort out the issue.

Meanwhile, anyone who can gets the issue is invited to look into what’s going on as well as possible.
Note that I’m not talking about a flaky Activate button, but the Newtonsoft.Json issue and no starting.

11

Suspicion from Crash after update to “2.0.5.1 (2.0.5.1_beta_2020-01-18)” is further confirmed.
Update from original .msi install of v2.0.2.1-2.0.2.1_beta_2017-08-01 to 2.0.5.1 does not work.

Reason is probably that the 2.0.2.1 design was replaced with a different one that is the default:

v2.0.2.11-2.0.2.11_canary_2017-10-20

Changed the way the auto-updater works. It now spawns a new version of the executable instead of attempting to run it in an AppDomain

Look in C:\Program Files\Duplicati 2\changelog.txt to see original .msi install version.
Non-Windows systems will probably reveal Duplicati’s install location in /usr/bin/duplicati script.

Web UI BaseVersionName will also show this to you, if you still have a web UI that’s working…

Among Beta releases, v2.0.3.3-2.0.3.3_beta_2018-04-02 is the first that can update to 2.0.5.1.
Old releases should be uninstalled for manual update from the .msi installer to avoid this issue.
Non-Windows systems should do the equivalent with package tools, not Duplicati autoupdater.