after updating to the last but one beta-release in Dec '24, the tray icon application crashes after some time of running (i.e., the process disappears from Windows task manager and the icon from the taskbar, no backups are done till restarting the application). As far as I can see, this is independent of the question whether a job has already been executed or not. This does not happen if Duplicati was started manually (see below for the setup). The setup I use is as follows:
System: Win 10 22H2 64bit, latest patches all installed
Duplicati 2.1.0.5 stable (problem occures since version 2.1.0.2 beta)
Duplicati.GUI.TrayIcon.exe started via Windows task scheduler, in order to give it elevated rights (I need VSS to backup open files);
Windows user logon used as trigger;
task executed as standard user with elevated rights (tested running as “System”-process; doesn’t work at all);
task set to delay one minute after logon (tested with different settings - no effect);
Duplicati itself set to delay any activity for 30 sec after launch (tested with different settings - no effect);
three backup jobs configured, two using a local hard drive (USB), one MS OneDrive (problem occured for the first time before the OneDrive job was set up);
all tasks set to be halted on battery power.
The backups themselves run without trouble (as long as I remember plugging the external drive in, but that’s another question, of course). What I tried so far is de-installing and re-installing versions 2.1.0.2 through 2.1.0.4, and finally updating to 2.1.0.5 yesterday, to no effect. I didn’t find any crash-logfiles or error events in Windows. Also, before 2.1.0.2, the said setup worked for more than two years on the same system without trouble.
I’ve got not even a clue where else to look for a reason (or if I’m just missing something right in front of me). Any ideas?
This brings up UAC prompt. After satisfying that, shortcut runs a batch startup script, which leaves a terminal window around. If it fails that way, maybe it’ll say something.
Hopefully you’ll find something in the Windows Application event log, e.g. from .NET.
Thanks ts678; I thought I’d checked all the places listed for containing logfiles - but it seems that I’ve missed something in the first place, as indeed .NET throws errors related to Duplicati in Windows error reporting. At least today the timestamp (10:16 AM today, if this is of any relevance) fits the moment I became aware of the tray icon “vanishing” (indeed: it’s there, and on mouseover, it vanishes…). The same report shows every day, at different times - I couldn’t figure out any regularity. Especially, it seemingly doesn’t depend on jobs being executed or not yet. The only clue I have so far is, that the “vanishing” (and, probably, the errors I’m talking about) happens once after Duplicati is launched by the Win10 task planner. And here’s the Gobbledegook the error reporting “tells” me:
An unhandled exception has occurred while executing the request.
Exception:
Duplicati.WebserverCore.Exceptions.UnauthorizedException: Authorization failed due to missing cookie.
at Duplicati.WebserverCore.Endpoints.V1.Auth.<>c.<b__3_0>d.MoveNext()
— End of stack trace from previous location —
at Microsoft.AspNetCore.Http.RequestDelegateFactory.g__ExecuteAwaited|92_0[T](Task1 task) at Duplicati.WebserverCore.Middlewares.HostnameFilter.InvokeAsync(EndpointFilterInvocationContext context, EndpointFilterDelegate next) at Duplicati.WebserverCore.Middlewares.LanguageFilter.InvokeAsync(EndpointFilterInvocationContext context, EndpointFilterDelegate next) at Microsoft.AspNetCore.Http.RequestDelegateFactory.<ExecuteValueTaskOfObject>g__ExecuteAwaited|129_0(ValueTask1 valueTask, HttpContext httpContext, JsonTypeInfo`1 jsonTypeInfo)
at Duplicati.WebserverCore.Middlewares.WebsocketExtensions.<>c__DisplayClass0_0.<b__0>d.MoveNext()
— End of stack trace from previous location —
at Microsoft.AspNetCore.Diagnostics.ExceptionHandlerMiddlewareImpl.g__Awaited|10_0(ExceptionHandlerMiddlewareImpl middleware, HttpContext context, Task task)
<<<END QUOTE
Can anyone interpret this? I can’t, as I’m not a programmer at all.
Are these IDs of any relevance/importance? I can report them, too, if necessary; but as it says “ID” and I have no idea to what they refer, I’d rather leave them out in the first place. Maybe I’m paranoid.
Hopefully the Duplicati programmer can help. Some previous notes:
Except yours wasn’t log output. For the first, invalid password shouldn’t be fatal.
I think the login attempts can come from the open browser tabs, or the TrayIcon.
For browser tabs, you could either start logging or close them and see if it helps.
Logging depends on browser, but it’s often in developer tools or click on F12 key. Goal is to see what went in, although I wouldn’t expect much without user action.
What browser is this? If you close Duplicati tabs, it might not matter. Otherwise, it might. Refresh seen is the kind of thing that might happen after 15 active minutes.
This is an error message from the webserver. It means that the login did not succeed because the request had no previously created authentication tokens (stored in a browser cookie).
It is normal and will happen if you try to access the WebUI without being logged in.
It is not a crash, it is just logging that the authentication code threw an exception.
No, they are only relevant for debugging locally on the machine.
Windows has long had a quirk where a TrayIcon can stay visually after it crashed. But it is also possible that the mouse-over is triggering the crash. @ts678 did you report seeing that at some point?
Do you notice any correlation between the time it stops and the messages? I am fishing a bit here, because without an error message of sorts, it is almost impossible to figure out what happens.
Do you happen to see other messages in the event log that could be relevant? Usually crashes are logged in Windows / Application in EventViewer.
I can’t find it now, but at one point I thought mouse-over would eventually crash, however I think conclusion was it was a delayed crash happening by itself, and mouse-over just made the icon vanish.
I can now confirm that it is not mouseover which causes the crash, at least at my machine. At least once I found that Duplicati, after being started (prooved by the job logs), had crashed already before I looked at the systray for the first time at that day.
No, not any more. I thought so in the first place, but I’ve monitored this (as far as my work admitted me to do so) for the last couple of days, but there is no coincidence.
I use Firefox (most recent stable release at a time), but I don’t open Duplicati tabs usually - the normal setting for me would be to have Duplicati started automatically, and not looking at it until I need a backup (so, hopefully, never [again]…). From time to time, but not on a regular basis, I would check for error warnings. Only now, as I know that Duplicati doesn’t work as it should, I have a closer look at it.
With some digging into Windows error reporting - I went to places I’ve never been before - I found another error report. One stems from Feb '25, after a row of dozens of errors of the server-login-type (all with the same timestamp, one second before this one):
REPORT DATA>>
Name der fehlerhaften Anwendung: Duplicati.GUI.TrayIcon.exe, Version: 2.1.0.4, Zeitstempel: 0x66470000
Name des fehlerhaften Moduls: coreclr.dll, Version: 8.0.624.26715, Zeitstempel: 0x66479681
Ausnahmecode: 0xc00000fd
Fehleroffset: 0x0000000000071bd7
ID des fehlerhaften Prozesses: 0x16e8
Startzeit der fehlerhaften Anwendung: 0x01db85fd5b1558d2
Pfad der fehlerhaften Anwendung: c:\Programme\duplicati 2\Duplicati.GUI.TrayIcon.exe
Pfad des fehlerhaften Moduls: c:\Programme\duplicati 2\coreclr.dll
Berichtskennung: e6eb93c0-1eee-4989-be48-1dee3f93d4ce
Vollständiger Name des fehlerhaften Pakets:
Anwendungs-ID, die relativ zum fehlerhaften Paket ist:
<<END DATA
To this event I also found a error report file (filetype WER), which contains this:
Hope this helps, for this is all I can contribute.
I also checked whether I could find a setting within the task scheduler, but: nothing. The only difference I can figure out is that the said type of crash occurs when I start Duplicati via the scheduler; and that it does - as far as I can see - not happen if I start it manually, i.e. via desktop icon or start menu (always as admin/with elevated rights); and that start with scheduler does not work at all if I define a path to start in (independent of the actual path). If I define a path in the task, nothing happens at all. The desktop icon seems to set the installation path as starting path by default; I didn’t change that.
I have found at least one possible cause for this.
The way the image displayed is loaded was not properly closing old images.
After some time, and on a machine with plenty memory, this could cause over 10000 images to be in an open state, and at that point Windows will refuse to open more.
I am not sure what causes the frequent image reloads, but I have fixed the issue by keeping the same images open instead of re-opening them. This fix is included in canary 2.1.0.112
