The profiles that are affected (dropped) are likely to be completely random, but a vague pattern may also appear to be the case.
We have not been able to replicate this at 2BrightSparks, but we theorize that the cause may be due to an external process locking one or more of the component files (e.g. .INI file) of the profile concerned during the program start-up. The start-up 'housekeeping' includes a silent cross-check of any Group profiles to make sure that all their 'member' profiles are valid, and if one or more of a member profile's components are locked, this internal cross-check process may decide that profile is corrupt and drop the entry/reference to it. This is to try and ensure that an entire Group is not rendered inoperative (or, would abort in mid-run, etc.) by any damage to a single member profile.
Note that this internal cross-check occurs during any start-up of any instance of the main program, including one or more instances started by a Schedule(d Task). It is thus not restricted to a manual start-up of the program, so the losses (dropped profile/s) may occur silently, overnight, and so on.
The prime candidate for such an external locking process would be anti-virus (AV) software, malware-defense software, etcetera. It had been reported by a user in our forum that a particular brand of AV (Symantec antivirus) seems to have been the cause in his particular case, but we cannot guarantee that the same software is the cause in any other case, nor that this does not happen with any other AV (etc.) software.
Note also, if trying to debug this, that AV software may not actually disable all its processes when requested (whether by design or by accident is uncertain). We have received numerous reports (in various circumstances) whereby unwanted behavior that was not prevented by 'disabling' the AV software vanished completely once that AV software was uninstalled and/or replaced.