The main fix to all three apps involves a hopefully rare underlying problem with the code used to work with Windows’ CreateProcess API, which has a bug of it’s own that our code wasn’t compensating for.
d7x: Under some rare conditions this may cause a failure to launch 3rd party applications.
dSupportSuite: The problem was a little more complicated, and under some conditions this could cause a custom app that had a bad download link to trigger dSupportSuite to start a second copy of itself in the middle of it’s automated Maintenance routine, causing the routine to wait for a user to close the second copy of dSupportSuite before the routine will continue.
dSS Mgmt Console: Just guessing this could affect launching dSupportSuite with the appropriate command line arguments to configure itself, so it was updated ‘just in case’.
Now I will attempt to explain the “under some conditions” mentioned above for the interested.
When using CreateProcess with a path that contains a space, ex. “c:\program files\sub dir\program.exe” has two, CreateProcess would first execute “c:\program.exe” if it existed, then it would execute “c:\program files\sub.exe” if that existed, but only when both do not exist will it execute the full “c:\program files\sub dir\program.exe”. The bug was compounded by the solution (wrapping the path in quotes, duh) not actually solving that problem when using the CreateProcessW version of the API (for unicode support) unless you use the file system syntax of “\\?\c:\program files\sub dir\program.exe”, which d7x based code (including all three apps) sometimes used depending on the path, because it isn’t always necessary even with the wide version of the API. This made for a very rare but very frustrating bug. The code has been updated to always use this syntax when a space is in the path.
The issue was compounded in dSupportSuite because there exists the file “dSupportSuite.exe” alongside the “dSupportSuite Resources” subdir, so running an executable from inside that subdir instead caused CreateProcess to run “dSupportSuite.exe” instead of the app in the subdir. Also dSS was running itself with command line arguments it didn’t know how to handle, starting with ” Resources\Tools\7za.exe […]” due to how the path to 7za.exe was being chopped into the arguments passed to dSupportSuite.exe. This all might occur in the process of file integrity checks on downloaded zip files, but only when a downloaded file was corrupted would this really happen since that particular external executable isn’t used for the integrity check for every download. So hopefully rare, but now resolved.