This behavior seems to be mostly or completely restricted to users with a server OS, though that is not guaranteed/proven. We are unable to reproduce this behavior at our side under any circumstances with any version of Windows.
But, after some exhaustive checks & tests by various users, it appears it is the Scheduler itself (or Windows in general, in response to the Scheduler) logging an error when trying to unload the Windows user-profile used in/by the Scheduled Task from memory. This deduction is reinforced by the fact that if the user in question is already logged in (and stays that way), the error apparently doesn't happen (something which you might want to check for yourself).
This error is seemingly not being generated by SyncBack, which is only incidental, being the software mentioned in the Task's command-string (plus, debug logs have demonstrated it happens after the instance of SyncBack used to run the profile would actually have closed). Users have reported the same error arises if some other software is Scheduled.
The cause is unclear, but may be related to some corruption (or, 'unusual configuration') in the registry and/or the system files which manipulate it. So far it appears to be benign, albeit maybe annoying.