GUI TrayIcon crash using Windows task planner

Hi all,

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?

Welcome to the forum @Deoquaerus

That’s unfortunate, as starting from terminal might say something informative.

Where are application crash logs? suggests places to check.

v2.1.0.2_beta_2024-11-29

The change log highlights the extensive changes since 2.0. Some new issues arose.

FWIW (and I wish it wasn’t necessary), I do that the clunky way with this on shortcut:

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:

QUOTE>>>

(Source: .NET runtime
Event ID: 1000)

Category: Microsoft.AspNetCore.Diagnostics.ExceptionHandlerMiddleware
EventId: 1
SpanId: [[omitted*]]
TraceId: [[omitted*]]
ParentId: 0000000000000000
ConnectionId: [[omitted*]]
RequestId: [[omitted*]]
RequestPath: /api/v1/auth/refresh

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.

Take Care,
Deoquaerus.

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.

Developer might have a better idea.

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.