It seems I was a bit early by saying I had found a work around. When the 2 tasks are not in the same context ('start with windows' in the root, 'on login' in the syncbackpro context) not always do both taks run as they should, unfortunately. Some logins result in both running, some in the exit of the 'start with windows' task. Gives me the idea that at some logins the 'start with windows' task runs quickly enough to not yet detect the other process, and sometimes it is too late, detects the other syncback process and exits.
So, I changed the trigger of the 'on login' task in the scheduler. The advanced setting 'delay task for' was set to 5 seconds by default, I changed it to 15 seconds. That way I'm certain the 'start with windows' task gets the chance to run, not detect any other syncbackpro instances, and stay minimized and active.
This workaround works very well. Not once in more than a few restarts and logins did the 'start with windows' task exit. So finally there is a work around, but the fiddling in task scheduler advanced settings should imo not be done by the end user. Maybe it's possible to change the way syncbackpro creates tasks in the scheduler, eg the 'start with windows' task gets the default delay of 5 seconds and the 'on login' tasks get a delay of 15 or 20 seconds. Still, that would be a work around. It would be better to change the way the 'start with windows' task checks for running instances.
So, I changed the trigger of the 'on login' task in the scheduler. The advanced setting 'delay task for' was set to 5 seconds by default, I changed it to 15 seconds. That way I'm certain the 'start with windows' task gets the chance to run, not detect any other syncbackpro instances, and stay minimized and active.
This workaround works very well. Not once in more than a few restarts and logins did the 'start with windows' task exit. So finally there is a work around, but the fiddling in task scheduler advanced settings should imo not be done by the end user. Maybe it's possible to change the way syncbackpro creates tasks in the scheduler, eg the 'start with windows' task gets the default delay of 5 seconds and the 'on login' tasks get a delay of 15 or 20 seconds. Still, that would be a work around. It would be better to change the way the 'start with windows' task checks for running instances.