Independent App-V Blog

Troubleshooting SoftGrid applications often includes taking a look under the hood and inside the Q:\ drive (or whatever drive letter you set it to). Obviously this cannot be done directly from Windows Explorer. Doing this will result in an error “Q:\ is not accessible. Access is denied.”            

Luckily, there are many ways to take a look inside the Q-drive, through explorer or command line, and successfully troubleshoot a SoftGrid package. In this post I´ll elaborate the most common ones I use.

1. Map a drive
The easiest one I´ve seen (and just recently found out through Aaron Parker’s techblog) is to just simply map a drive to the Q: drive.

NET USE * \\%COMPUTERNAME%\Q$

This works for both the localhost as for remote computers. You can instantly browse the root of the mounted drive through a command line or through Windows Explorer. However you can only browse subdirectories of the applications that are actually running. This might an issue if you’re troubleshooting the application startup in the first place

So that’s where the “advanced” stuff comes in.

2. Edit section in OSD
This section includes editing the OSD file(s). The best way to do this is by using an editor like Notepad++ or a designated tool like the OSD Editor from Login Consultants. If you’re confident enough you could also use good old Notepad.
For the steps below it’s important to create a copy of the original OSD. It doesn’t matter which one as long as it’s from the same (virtual) application. Editing the original one might break the application.

VERSION value
Instead of starting the original application we have to start another program (like cmd.exe) in which we can do our troubleshooting. To do this first make sure that you change the VERSION tag of the (copied) OSD. Also make sure that you are running in the correct environment and that the application is already loaded. Not changing the version key will overwrite the OSD in cache, making the original application(shortcut) starting the “debug program”.

From:
<softpkg name="Example Application" version="1.0">
To:
<softpkg name="Example Application" version="debug">

The “debug” setting above is arbitrary and can contain any text you like.

SUBSYSTEM value
In the specific case of running a command prompt also be sure to change the SUBSYSTEM to console.

From:
<subsystem value="windows">
To:
<subsystem value="console"> 

The “console” value above is a fixed value and should contain either “windows” or “console”.
If you don’t change the SUBSYSTEM value and start cmd.exe you’ll get an error: “Cannot create a file when that file already exists”.

FILENAME value
When the above settings are applied you need to change the FILENAME value in the tag to contain the program you like to start (in this example it’s cmd.exe).

From:
<codebase filename="C:\SAMPLEAPP\APP.EXE">
To:
<codebase filename="C:\WINDOWS\SYSTEM32\CMD.EXE">

Be sure to clear out the PARAMETERS value if it’s set.

Although you can basically start any program you like here, you have to make sure that the specific program is locally available (installed) and can be started in a separate memory space. If the latter is not the case the program can’t be started simultaneously in both a virtual and real environment. For example: this is the case for Regedit and Windows Explorer.

If you do want to run Windows Explorer from the section follow this article from Aaron Parker’s techblog. You’ll need to set a registry key for Windows Explorer to start each instance in a separate memory space. This can be done both in the real world as well as in the virtual environment.

3. Edit section in OSD
You can also run the custom command before the actual application is launched. To do this, locate the DEPENDENCY tag and add the SCRIPT tag with the following code:

<dependency>
   <script event="LAUNCH" protect="TRUE" wait="FALSE" timing="PRE">
      <scriptbody>cmd.exe</scriptbody>
   </script>
</dependency>

The difference between editing the CODEBASE section and the SCRIPT section is that the first one will show up in your cache as a separate “application”. The second one will have to be edited in the original OSD where no other changes are made.

You can toggle the wait value to let the application wait for the custom command to finish (wait=”TRUE”) or to launch simultaneously (wait=”FALSE”). If you set the wait value to TRUE you might want to include the TIMEOUT=”0″ value to the SCRIPT tag if you are debugging. The TIMEOUT value tells the application how long it should wait for the script before exiting. The value of 0 (zero) tells it to wait indefinitely.

More information on the SCRIPT tag is explained perfectly here.

4. File Open from within the virtual application
If you have an application that has a “File -> Open” or similar menu, you could use it to locate the application that you want to run. As I said earlier, your application has to start in the first place.

Sometimes you can’t just select for example cmd.exe en press Select in the dialog box. What I always do in this situation is right-click the desired program and select open or “run as”. Even when you don’t supply any additional credentials, the application just opens separately.

A trick to get Windows Explorer to run (without having to set the registry key as said earlier) is to kill the explorer.exe outside the virtual environment and to start it again inside using the File -> Open command.

5. SFT Explorer
Last but certainly not least is the tool SFT Explorer by Kalle Saunamäki. With this tool you are able to look inside an SFT without ever having to load it on a machine. You can actually see what the files/registry keys would look like if the virtual application was applied on the target machine. You cannot make changes to the application however.

Well, that’s it. These are the ways I use to get inside the SoftGrid applications to do my troubleshooting. If you know any additional tricks, feel free to let me know as long as you don’t tell me that I’ve missed the sequencer itself though :-0