If all your profiles are stored in the user-area for user-name 'syncback', it presumably can't be an instance of Pro running in another user's session. But it could still be a separate instance of the program - running 'as' the same user - started by some other means that is locking the profile(s) in question. Multiple instances can be started by command-line (Scheduled Tasks, shortcuts, batch files, scripts). Plus, almost any other trigger method (manual, hot-key, OnChange profile, etc) if you happen to have a foreground Pro instance open.
It's also possible that if you have Repeat/Duration (or 'Repeat Until [Time]') settings in your Scheduled Task (and you obviously must have one or the other) that mean it will try to Repeat at the same time as (or beyond) the next overall Scheduled time, you could get double-instances of the Task spawning double-instances of the program trying to load the same profiles, with possible locking issues by the first instance to load (which then 'gears up' the profiles) causing 'locked' issues for the 2nd instance when it reviews the validity of the same profiles as it loads them initially).
The same issue (more than one instance in memory) could arise if your Scheduled Task creates another instance (of itself, thence Pro) because one run took longer than normal, and is in fact still running at the next trigger time. Unfortunately, XP/2003's Task Scheduler has no functionality to prevent that.
But the development department have reported back that they had no success trying to replicate this with a mock-up of your set-up (group with many profiles, set to run repeatedly every 5 minutes, running in an XP VM for over 24 hours). Nothing lost, deleted, whatever. Of course it's impossible to replicate your environment & traffic patterns 100% and we had no external triggers of any kind, whereas we cannot guarantee you don't (unknowingly, maybe). Ditto re any external process that might be locking the profile INI (AV scan, etc).
Unfortunately, if we cannot replicate it, we cannot trace the cause. Sorry, but we're now officially out of ideas.
It's also possible that if you have Repeat/Duration (or 'Repeat Until [Time]') settings in your Scheduled Task (and you obviously must have one or the other) that mean it will try to Repeat at the same time as (or beyond) the next overall Scheduled time, you could get double-instances of the Task spawning double-instances of the program trying to load the same profiles, with possible locking issues by the first instance to load (which then 'gears up' the profiles) causing 'locked' issues for the 2nd instance when it reviews the validity of the same profiles as it loads them initially).
The same issue (more than one instance in memory) could arise if your Scheduled Task creates another instance (of itself, thence Pro) because one run took longer than normal, and is in fact still running at the next trigger time. Unfortunately, XP/2003's Task Scheduler has no functionality to prevent that.
But the development department have reported back that they had no success trying to replicate this with a mock-up of your set-up (group with many profiles, set to run repeatedly every 5 minutes, running in an XP VM for over 24 hours). Nothing lost, deleted, whatever. Of course it's impossible to replicate your environment & traffic patterns 100% and we had no external triggers of any kind, whereas we cannot guarantee you don't (unknowingly, maybe). Ditto re any external process that might be locking the profile INI (AV scan, etc).
Unfortunately, if we cannot replicate it, we cannot trace the cause. Sorry, but we're now officially out of ideas.