Microsoft KB Archive/931182
Article ID: 931182
Article Last Modified on 3/21/2007
- Microsoft SoftGrid for Terminal Services
- Microsoft SoftGrid for Windows Desktops
When you try to start an application in Microsoft SoftGrid, you receive the following error message:
This problem occurs because the application did not run. You do not receive an application error. Therefore, this problem may be caused by any of the following reasons:
- Incorrect permissions
- Incorrect policies
- Missing files
- Incompatible files
- A problem with the application configuration
For more information about how to determine the cause of this problem and how to troubleshoot this problem, see the "More Information" section.
Obtain the FileMon utility
You can use the Sysinternals FileMon utility to determine almost all causes of this problem.
To obtain FileMon, visit the following Microsoft Web site:
For more information about how to use the FileMon utility to troubleshoot SoftGrid-enabled applications, click the following article number to view the article in the Microsoft Knowledge Base:
931819 How to use Filemon and Regmon to troubleshoot SoftGrid-enabled applications
Review the event log
First, review the Application event log in Event Viewer to find any application-specific errors.
Determine other possible causes of this problem
This problem may occur because one of the following conditions is true:
- The <VM> element is missing from the .osd file.
- The <SUBSYSTEM> element is missing from the .osd file.
One of the following conditions is true:
- The VALUE attribute of the <VM> element in the .osd file is set to "Win32". However, this value must be "Win16". Or, this value is "Win16" and must be "Win32".
- The VALUE attribute of the <SUBSYSTEM> element in the .osd file is set to "windows". However, the VALUE attribute must be set to "console". Or, this value is "console" and must be "windows".
For example, the code in the .osd file resembles one of the following code examples.
Code example 1
<IMPLEMENTATION> <VM VALUE="Win32"> <SUBSYSTEM VALUE="windows"/> </VM> </IMPLEMENTATION>
Code example 2
<IMPLEMENTATION> <VM VALUE="Win16"> <SUBSYSTEM VALUE="console"/> </VM> </IMPLEMENTATION>
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.
<VIRTUALENV> <ENVLIST> <ENVIRONMENT VARIABLE="PATH">%PATH%;%SFT_MNT%\sft_ea70.v1\Softricity\SoftGrid Example Application\DLLs;</ENVIRONMENT> </ENVLIST> </VIRTUALENV>
- 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:
<ENVIRONMENT VARIABLE="TEMP">"%SYSTEMROOT%\Temp"</ENVIRONMENT> <ENVIRONMENT VARIABLE="TMP">"%SYSTEMROOT%\Temp"</ENVIRONMENT>
Modify these lines of code to resemble the following code example.
<ENVIRONMENT VARIABLE="TEMP">"%TEMP%"</ENVIRONMENT> <ENVIRONMENT VARIABLE="TMP">"%TEMP%"</ENVIRONMENT>
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.
<ENVIRONMENT VARIABLE="TEMP">"%USERPROFILE%\Local Settings\Temp"</ENVIRONMENT> <ENVIRONMENT VARIABLE="TMP">"%USERPROFILE%\Local Settings\Temp"</ENVIRONMENT>
- 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.
- Click Add.
- 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.
Keywords: kbtshoot kbexpertiseinter KB931182