Occasionally, Application Launcher cannot automatically repair a broken application, even when it has access to the application's installation files (from the network in connected mode or from the NAL cache in disconnected mode). This is because of the method Application Launcher uses to detect broken applications.
When Application Launcher successfully launches the file (in other words, the CreateProcess call it makes returns a true), it assumes a successful launch. In some cases, however, the file that Application Launcher calls doesn't actually start the application but in turn calls another file to start the application. If that file is broken, missing, or cannot launch, the application launch fails without Application Launcher prompting the user to verify the application. For example:
If you delete WinZip's wz32.dll and then launch winzip32.exe, Application Launcher successfully calls winzip32.exe, so it assumes a successful launch. However, when winzip32.exe calls wz32.dll, the launch fails because wz32.dll does not exist. Because Application Launcher only automatically prompts users to verify applications that it cannot launch, and it successfully launched winzip32.exe, the application is not automatically repaired.
You delete consoleone.exe and then try to launch the application. Because Application Launcher calls Java, which in turn starts ConsoleOne®, the launch fails. However, Application Launcher does not automatically verify ConsoleOne because it successfully launched Java.
In these cases, Application Launcher displays the following message:
Error message: Application Launcher Status - Could not launch Application_Object_Name (id=xxx) The filename, directory name, or volume label syntax is incorrect.
Although Application Launcher cannot automatically prompt users to verify applications that fit this scenario, user's can manually initiate the verification on their own. For information about how to do this, see the next section, Using Application Launcher to Verify an Application.