Sometimes antivirus or system security functions identify backend libraries (DLL files in windows or support files in mac\unix) as possible intrusions or virus, and disable the running context necessary for them to function correctly, when the installer isn't run from a standalone package. If still bugged, try the standalone download installer. Try software, if still bugged, uninstall, and repeat the process, then reinstall the apps, logout CCDesk, then back in again. However, to make this less intrusive, many extra services, offered as part of the new software functionality where the services match common use of the software, are hosted online as file downloads, instructionals etc.Ħ. The new Software as A Service model relies heavily on hashfiles and checksums to verify ownership over the internet. I don't work for adobe, but I watch my system carefully, and I have some understanding of recent techniques with software anti-piracy. This should regenerate the hash file with the values necessary for the apps to run. You can regenerate the hash by logging out, restarting, exit CCDesk if its running, then open it again and log in if needed. IF the file is accessible (on my system, my system monitor shows the app attempting to access but failing), it may still be the old version, making the apps crash, as they believe you have a pirate copy. This is unfortunate, since a new hash must be generated to include the information for the new apps. The hash file, if it already exists, is typically RUNNING in the background if you are logged in to CCDesktop, and it cannot be replaced with a new one. When the apps are installed, there is a hash file set created (if it doesn't already exist) in your running user data (windows is appdata in your user folder, on mac, in user library), and it holds security values for your system and for the account in adobe CC. It isn't an installation issue, per se, but it is a file that is a part of the fileset that the app needs in order to start up. Unfortunately, on my system, the file cannot open from the substance apps. The file that is being accessed by the substance programs is actually in the files for CCDesktop.
If they are not running in the proper context, or only one program is running in a particular process tree's context (this is usually numbered like interrupt queing), then they are not in sync. They really need to be in sync, and running in the same context (for permissions in processing, permissions in memory, and permissions in general).
Threading and application multitasking, especially with one app interfacing with another before performing the full operation, can be hazardous with new security measures in place like rootless and protected memory space.
If I may.a lot of app verification anymore is time sensitive, or more accurately, processor clock sensitive. I'm having the same problem, will try the fix suggested.