When you try to start an application in Microsoft SoftGrid, you receive the following error message:
The SoftGrid Client could not launch Application.
The application exited before the launch sequence was complete. Please report the following error code to your System Administrator.
Error code: xxxxxx-xxxxxx04-00000428
The application cannot locate a required file. To determine the missing file, use the FileMon utility.
The file may exist in the package. However, the executable file for the application cannot locate the file. To resolve this problem, specify the path ofth to the file. To do this, configure the PATH environment variable that is specified by the VARIABLE attribute of the <ENVIRONMENT> element in the .osd file.
For example, consider the following scenario:
The executable file is "%SFT_MNT%\sft_ea70.v1\Softricity\SoftGrid Example Application\sft_ea.exe".
The file that is not found is "%SFT_MNT%\sft_ea70.v1\Softricity\SoftGrid Example Application\DLLs\sft_ea.dll".
In this scenario, configure the VARIABLE attribute of the <ENVIRONMENT> element by using code that resembles the following code example.
<ENVIRONMENT VARIABLE="PATH">%PATH%;%SFT_MNT%\sft_ea70.v1\Softricity\SoftGrid Example Application\DLLs;</ENVIRONMENT>
The application uses an incompatible version of a file. Use the FileMon utility to determine the incompatible file.
This problem may occur because the file exists in the package but the file is incompatible with the operating system. For example, this problem occurs if the package was created in Microsoft Windows 2000 Professional and then the package is streamed to Microsoft Windows Server 2003.
If the file is a system file that is located within the %SystemRoot% folder or its subfolders, open the package. Then, remove the file from the package. When the package is streamed to the SoftGrid Client, the executable does not locate the file in the package. Instead, the executable uses the local computer and locates the file in the %SystemRoot% folder or a subfolder.
When the application starts, it runs the Dr. Watson (Drwtsn32.exe) debugger.
To troubleshoot this problem, use the FileMon utility or Windows Task Manager to monitor the Drwtsn32.exe process. When you run Dr. Watson, review the items in the Application Errors list. Dr. Watson generates a Drwtsn32.log file and a User.dmp file. You may be asked about these files if you contact Microsoft Customer Support Services.
The application writes to the %TEMP% folder or the %TMP% folder when it runs. However, the user who runs the application does not have user rights for these folders. Use the FileMon utility to verify that access was denied.
This problem frequently occurs because the TEMP and TMP environment variables are set to "%SystemRoot%\Temp". These environment variables are specified by the VARIABLE attribute of the <ENVIRONMENT> element in the .osd file. However, users typically do not have user rights to this folder in Terminal Services. To resolve this problem, use one of the following methods:
Modify the .osd file. Change the values for the TEMP and TMP environment variables to "%TEMP%" and "%TMP%".
Completely remove the environment variables from the .osd file. If the variables do not exist in the .osd file, the application uses the environment variables that are configured on the local computer.
For example, the .osd file contains the following lines of code:
Note This example assumes that the local %TEMP% and %TMP% environment variables are set to valid locations. Otherwise, use code that resembles the following code example to configure the TEMP and TMP environment variables.
The application does not run because Windows is running in side-by-side (SxS) mode.
It may be difficult to verify that this problem occurs because of SxS mode. The easiest method is to stream the application to Windows 2000. If the application streams to Windows 2000 but the application does not stream to Windows XP or Windows Server 2003, this problem is likely related to SxS mode.
The application does not run when another instance of the same application is already running.
Some applications verify that an existing process is running for the same executable file when the application runs. If this process exists, the application tries to attach itself to the existing process. If that existing process is in the virtual environment, the SystemGuard environment prevents the application from accessing the existing process. Therefore, the application does not run.
A user who has administrator rights can run the application. However, a user who has restricted user rights cannot run the application.
For example, one of the following conditions may be true:
The user does not have access to local files.
A system policy prevents a required action.
To determine which condition is true, use the FileMon utility to determine whether access is denied or an action does not occur.
Test a user who has restricted user rights. No Windows policies must be applied to this tested user.
The application requires that the user who streams the application has the "Create global object" user right. However, the user does not have this user right.
To verify this, follow these steps:
On the Terminal Server, run the Group Policy Object Editor (Gpedit.msc).
Expand Local Computer Policy, expand Computer Configuration, expand Windows Settings, expand Security Settings, expand Local Policies, and then expand User Rights Assignment
Right-click Create global objects, and then click Properties.
In the Enter the object names to select box, type Authenticated Users.
Stream the application
A file version mismatch exists with the Softricity files.
In this case, no application streams to the SoftGrid Client. This problem may occur the following behavior occurred:
The SoftGrid Client was manually uninstalled, and a Softricity DLL remains.
A newer SoftGrid Client was installed. However, the newer version of the client did not overwrite the DLL.