Working with Turbo Studio

Working with Turbo Studio

Turbo Studio is a desktop application that allows you to convert any Windows application into a self-contained virtual application. Virtual applications can be delivered as standalone executables, MSIs or Turbo images.

The GUI allows users to easily edit complex configurations for applications that may require complicated settings. Whereas Turbo's command line tool builds images from containers, Turbo Studio uses static XML files (.xappl) to build images. More information about the XAPPL file format is available in the XAPPL reference.

Once created with Turbo Studio, the command-line interface builds these XAPPL files into images that you can push to the Turbo Hub. Click here for a specific example.

Turbo Studio also provides three unique methods for creating images and virtual applications:

  1. Snapshot an application or component: In this method, snapshots capture the system state before and after an application is installed. Based on the observed system changes, the virtual application settings are automatically configured. This method is ideal for virtualizing off-the-shelf applications or ones that use complex MSI installer packages that would be incompatible with the command-line interface.

  2. Build application from a template: Download configurations from the Turbo.net Hub, allowing you to quickly customize and build working applications.

  3. Install application into a container: With this option, you would run the application installer in a clean container environment. When the installer completes, the contents of the container will be used to generate the application configuration.

Turbo Studio offers a user interface to manage custom images and virtual applications as well as additional creation methods not available in the command-line interface.

System requirements and download

Turbo Studio runs on any Windows operating system, including systems running within VMware and Microsoft hardware virtualization and hypervisor environments. Turbo Studio has limited support for the Windows Preinstallation Environment (WinPE), though certain applications (depending on operating system features unavailable in WinPE) may not function properly.

Turbo Studio supports both 32- and 64-bit applications. Both 32-bit (under 32-bit mode) and 64-bit executables can be run on x64-based platforms.

Note: Turbo Studio does not support creation of 16-bit executables. To run 16-bit DOS applications, virtualize an appropriate emulator with the application and launch the application through the emulator.

Note: Turbo Studio cannot access the turbo.net hub on Windows XP or Windows Server 2003 because the platforms do not support TLS1.2 which is required to access the web resources. Snapshot, build, and other features are not affected.

Download a free 30-day trial here or try the free, express version.

UI Basics

Using Turbo Studio enables you to configure the filesystem and registry of a container, embed external runtimes and components, take application snapshots, and create Turbo Virtual Machine (SVM) or executable files. The primary interface consists of a ribbon bar along the top and several panes accessed by buttons on the left.

Title Bar

  • The Start Menu button, or the circle at the top left of the window, enables container configurations to be created, opened, saved, imported, applied, and closed.
  • The Options bar provides Turbo Studio customization options, the ability to set proxy settings, and install certificates.
  • The Help bar provides access to Turbo Studio documentation.

Ribbon Bar

  • The Virtual Application tab provides access to the snapshot, build features, and output configuration options such as the startup file, output directory, and diagnostic-mode selection.
  • The Runtimes tab provides a selection of auto-configurable runtime engines which can be embedded into your application. These include .NET Framework, Java, Flash, Shockwave, Acrobat Reader, and SQL Server 2005 Express.
  • The Advanced tab provides functions such as viewing embedded layers and platform merge.
Snapshot
  • Capture Before button is to capture the machine state before you install your application for a snapshot.
  • Capture and Diff button is to capture the machine state after you install your application for a snapshot.

For more information on the snapshot process, see Snapshot documentation.

Build
  • Build button is to build your container image output.
  • Build and Run button is to build your container image output and then execute it for testing purposes.
  • Run and Merge button builds your container image and then executes it within the Turbo Client Runtime environment. Any changes made while inside the container environment will be added back to the configuration after the application is shutdown. This can be used to quickly set defaults in your container image.
Output
  • Startup File field is to set the path to the application which runs when starting your container. The Multiple button shows the Startup File manager dialog where additional settings can be specified.
  • Output File field is the name of the file that is created when your container image configuration is built.
  • Project Type dropdown allows you to set the type of output to generate. The following values are possible:
    • Layer (.svm) is a bare Turbo container image file that can be pushed to Turbo.net Hub, used in Turbo Server, imported into the Turbo.net Client Runtime environment, or used as a dependency in another project.
    • Portable Application (.exe) is a packaged executable file which contains the Turbo.net Client Runtime components and integrates with the Turbo.net Hub or an on-premise Turbo Server.
    • Standalone/ISV Application (.exe) is a standalone executable file with no dependence on the Turbo.net Client Runtime or Turbo.net Hub. This output type requires an Enterprise or ISV license for Turbo Studio.
  • Options button shows the Output Options dialog. This is used to enable diagnostics for .exe outputs or configure Portable Executable settings.
Tools
  • Configuration Wizard button shows the startup wizard where there are quick links to common process wizards; building from template, snapshot, install into a container, or manual configuration.
  • Snapshot Merge button allows a container sandbox changes to be imported into the configuration.
  • Import Configuration button allows a container image to be imported from an external source, such as: a ThinApp configuration, MSI package, Zenworks package, the Turbo.net Hub, or from the local Turbo.net Client Runtime image repository.
Publish
  • Publish to Server button allows an output container image to be pushed directly to the Turbo.net Hub or a Turbo Server instance.
  • Publish to Local Repository button allows an output container image to be pushed to the local Turbo.net Client Runtime repository.

Left-side Button Panes

  • The Filesystem pane displays the application virtual filesystem and enables you to add and remove virtual files and directories.
  • The Registry pane displays the application virtual registry and enables you to add and remove virtual registry keys and data values.
  • The Settings pane enables you to configure container metadata, startup image, startup/shutdown shims, and process configuration options.
  • The Layers pane enables you to add external container components.
  • The Install pane enables you to configure the MSI setup package, shortcuts, and other shell integration options.
  • The Expiration pane enables you to configure application expiration options.
  • The Network pane enables you to configure container proxy and DNS settings.

Note: Turbo Studio users are responsible for any third-party licensing compliance for redistributable components included using virtualization.

Virtual Filesystem

Turbo Studio enables you to embed a virtual filesystem into your executable. Embedded files are accessible by your Turbo-processed application as if they were present in the actual filesystem. Virtual files are isolated from the host device. Virtual files do not require security privileges on the host device regardless of whether the virtual files reside in a privileged directory. Because virtual files are embedded in the application executable, shared DLLs do not interfere with those installed by other applications on the host device.

In the event of a conflict between a file in the virtual filesystem and a file present on the host device, the file in the virtual filesystem takes precedence.

Note: When running a container on Windows 7, the All Users Directory\Application Data and All Users Directory root folders will map to the same folder at runtime. To prevent one setting from overriding another, verify that the isolation settings for these folders are the same.

Isolation Modes

Folders may be containerized in Full, Merge, Write Copy, or Hide mode.

  • Full: Full mode is used when the directory is required to be completely isolated from the host device. Only files in the virtual filesystem are visible to the application even if a corresponding directory exists on the host device. Any writes to files are redirected to the sandbox data area.
  • Merge: Merge mode is used when the directory is required to have some level of interaction with the host device. Files will be visible from both the virtual filesystem and the host device. Any writes to files which are new or already exist on the host device will pass through and be written to the host device. Any writes to files that are in the virtual filesystem will be written to the sandbox data area.
  • Write Copy: Write Copy mode is used when the directory is required to have visibility to files on the host device but cannot change them. Files will be visible from both the virtual filesystem and the host device. Any writes to files are redirected to the sandbox data area.
  • Hide: Hide mode is used when a directory on the host device could interfere with the application's ability to run properly. The application will receive a File Not Found error code whenever an attempt is made to read from or write to files in the directory even if the files exist on the host device.

Tip: To apply selected isolation modes to all subfolders, right-click on the folder, choose Isolation, select the checkbox for Apply to Subfolders, then select OK.

File Attributes

  • Hidden: Files and folders can be hidden from shell browse dialogs and other applications. This is used to prevent internal components and data files from being displayed to the user. To hide a file or folder, select the checkbox in the Hidden column adjacent to the desired file or folder. Note: The Hidden Flag is NOT the same as the Hide isolation mode. Enabling the Hidden Flag prevents a file or folder from displaying in browse dialogs or from directory enumeration APIs; it does not prevent the application (and potentially the end-user) from accessing the folder or file contents by direct binding. To prevent the file or folder from being found by the application, enable Hide isolation mode.
  • Read Only: Flagging files and folders as read-only prevents the application from modifying the file or folder contents. To make a file or folder read-only, select the checkbox in the Read Only column next to the desired file or folder.
  • No Upgrade: By default, files in the virtual filesystem can be upgraded with patches (refer to "Updating Registration Settings" in the Register containers in the Windows Shell section for more information). If there are files in the virtual filesystem that should not be upgraded, such as user data files, select the checkbox in the No Upgrade column next to the desired file or folder.
  • No Sync: This feature only applies to containers that are delivered and managed by Turbo Virtual Desktop Server. By default, files in the virtual filesystem can be synchronized to a user's Turbo account. This enables the application state to be maintained across different devices that are Turbo enabled. If there are folders in the virtual filesystem that should not be synchronized and remain only on the local device, select the checkbox in the No Sync column next to the desired file or folder. This setting is managed on a folder level and applies to all files within that folder.
Filesystem Compression

To reduce executable size, Turbo Studio can compress virtual filesystem contents. This reduces container size by approximately 50% but also prevents profiling and streaming of the application. By default, the Compress Payload option in the Process Configuration area of the Settings panel is unchecked. Leave this box unchecked during the build process if the application will be optimized for streaming from Turbo Virtual Desktop Server.

Note: Disabling payload compression may significantly increase the size of the container binary.

Virtual Registry

Turbo Studio enables you to embed a virtual registry into your executable. Embedded registry keys are accessible by your Turbo-processed application as if they were present in the actual registry. Virtual registry keys are isolated from the host device. Virtual registry keys do not require security privileges on the host device regardless of whether the virtual files reside in a privileged directory. Because virtual registry entries are embedded in the application executable, other applications are unable to disrupt application execution by inadvertent modification of registry entries.

The Classes root, Current User root, Local Machine root, and Users root folders correspond to the HKEY_CLASSES_ROOT, HKEY_CURRENT_USER, HKEY_LOCAL_MACHINE, and HKEY_USERS keys on the host machine.

Registry string values can include well-known variables such as @WINDIR@, @SYSWOW64@, @PROGRAMFILESX86@ and @PROGRAMFILES@.

In the event of a conflict between a key or value in the virtual registry and data present on the host device registry, information in the virtual registry takes precedence.

Isolation Modes

Keys may be containerized in Full, Merge, Write Copy, or Hide mode.

  • Full: Full mode is used when the key is required to be completely isolated from the host device. Only values in the virtual registry are visible to the application even if a corresponding key exists on the host device. Any writes to values are redirected to the sandbox data area.

  • Merge: Merge mode is used when the key is required to have some level of interaction with the host device. Values will be visible from both the virtual registry and the host device. Any writes to values which are new or already exist on the host device will pass through and be written to the host device. Any writes to values that are in the virtual registry will be written to the sandbox data area.

  • Write Copy: Write Copy mode is used when the key is required to have visibility to values on the host device but cannot change them. Values will be visible from both the virtual registry and the host device. Any writes to values are redirected to the sandbox data area.

  • Hide: Hide mode is used when a key on the host device could interfere with the application's ability to run properly. The application will receive a Key Not Found error code whenever an attempt is made to read from or write to values in the key even if the values exist on the host device.

    Tip: To apply selected isolation modes to all subkeys, right-click on the key, choose Isolation, select the checkbox for Apply to Subkeys, then OK.

Key Attributes

  • No Sync: This feature only applies to containers that are delivered and managed by Turbo Virtual Desktop Server. By default, keys and values in the virtual registry can be synchronized to a user's Turbo account. This enables the application state to be maintained across different devices that are Turbo enabled. If there are keys in the virtual registry that should not be synchronized and remain only on the local device, select the checkbox in the No Sync column next to the desired key. This setting is managed on a key level and applies to all values within that folder.
Importing Registry Hive Files

Turbo Studio can import registry hive (.reg) files into the virtual registry. To import a .reg file, select the Import button in the Registry panel, then choose the registry hive file to import.

Runtimes and Components

Many components and runtime systems consist of large, complex sets of filesystem entries and registry settings. Turbo Studio contains a collection of pre-configured component settings which can be added to your container with a single click. For example, if your application is a .NET Framework 4.0 application, then selecting the .NET Framework 4.0 component will allow your executable to run on machines without the .NET Framework installed.

Additional runtimes and components are added to the container during the snapshot process, before the after snapshot is taken.

To add a runtime or component:

  1. Select the Runtimes tab on the ribbon bar.
  2. Select the appropriate runtime or component. Selected components are indicated with a highlighted button. To remove a component, click on the button again. The button will no longer be highlighted and the component will not be included.

Note: The displayed runtimes apply to the currently selected target architecture (see process settings). If the target architecture is changed, architecture specific runtimes, like .NET 2 or .NET 3.x will still be included but will not display as selected. To deselect them, the target architecture must be changed back, and the runtimes can be deselected.

Note: Depending on the size of the component, the executable size can significantly increase. Only select components that are required for proper execution of your application.

Note: You are responsible for compliance with licensing for any third-party redistributable components included in your containerized application.

Using .NET Runtimes

To limit conflicts with installed .NET runtimes, the .NET runtime packages are isolated from the native file system. If the application requires access to multiple .NET versions, it is necessary to include all of the required runtimes in the virtual package. For example, including only the .NET 4 runtime will hide visibility to the .NET 3.5 runtime on the native file system. This is fine if the application only requires the .NET 4 components, but would be problematic if it also requires earlier versions of .NET.

An alternative approach would be to use the snapshot feature of Turbo Studio to build a custom .NET component for the application. This approach provides visibility into the files and registry keys that are available and allows for custom isolation settings.

Configuring the Java Runtime

Turbo Studio provides specialized support for the Java runtime. If your application is based on Java runtime, select the Sun Java Runtime button on the Runtimes ribbon bar. This displays the Java configuration menu.

Select the appropriate version of the Java runtime from the Java runtime version drop-down menu. If you deploy your application as a set of .class files, select Class from the Startup Type drop-down menu; if you deploy within a .jar file, select Jar. Enter the startup class name or Jar name in the appropriate textbox, along with any additional Java runtime options.

Snapshotting

Many applications require combinations of filesystem and registry entries. To facilitate containerization of these applications, Turbo Studio can snapshot application installations and automatically configure them based on modifications made to the host system during setup.

Process

Snapshots use before and after images of the host machine to determine configuration:

  • Before: This snapshot is taken prior to installing the application and captures the state of the host device without the target application installed.

  • After: This snapshot is taken after installing the application and captures all changes to the host device during application installation. Turbo Studio then computes the changes between the before and after snapshots, and inserts these changes into the configuration.

Complete the following steps to use the Snapshot feature:

  1. Prepare the host device: remove the target application and all dependencies or copy Turbo Studio onto a clean machine.

  2. Capture the before image: select the Virtual Application tab on the ribbon bar and then Capture Before. This may take several minutes to complete.

  3. Save the before snapshot (optional): saving the before snapshot enables you to skip this step in subsequent applications from the same clean machine. Select the down arrow underneath Capture Before and choose Save Snapshot. Turbo Studio automatically saves the most recently captured before snapshot; this snapshot is reset once the Capture and Diff is complete.

  4. Install your application: also install any other files, settings, runtimes, and components you want to include in the image. Refer to Add Runtimes and Components for more information. If the application setup requests a reboot, save the before snapshot, then proceed with the reboot.

  5. Capture the after image: on the Virtual Application tab on the ribbon bar, select Capture and Diff. This captures the after snapshot, computes the deltas between the two snapshots, and populates the image with the delta entries.

  6. Review the filesystem and registry entries: also remove any files or settings which are not required for proper execution of your container. Removing unused entries will reduce image size. Avoid accidental removal of required resources, as it will cause your image to no longer function properly.

Capture Application Updates via Snapshot

Container updates can be captured within Turbo Studio via snapshots.

Complete the following steps to capture an update via snapshots:

  1. Install the native version of the application on a clean machine.

  2. Select Capture Before.

  3. Install necessary updates to the native application.

  4. Select Capture and Diff to create the after snapshot. This captures the deltas between the original and updated versions.

  5. Set the Project Type to Component, then select Build to create the SVM.

This process only captures changes between the original executable and installed updates. You can then apply the resulting SVM to the original virtual package.

For more information on updating containers using SVMs, refer to Create and Use Shared Virtual Components and Specify Additional SVMs for a container.

Best Practices

  • Performing the snapshot on a clean machine ensures that all dependencies are installed by the application setup. Installing on a machine with existing components can inadvertently include dependencies in the before snapshot and exclude them from the final output.

  • If you configure a clean machine using whole-machine virtualization tools such as Microsoft Virtual PC and save a before snapshot based on this image you can snapshot many distinct containers in rapid succession by reverting the whole-machine virtual state and using the same before snapshot.

  • Most applications should be configured by performing the snapshot on the earliest (least common denominator) target operating system. A small number of applications may require multi-platform merge for successful deployment across all operating system variants.

  • When selecting a folder to save the Capture and Diff snapshot, select Make New Folder in Turbo Studio. This folder will not be included in the snapshot. If the folder is included in the Capture and Diff snapshot, remove it using the Filesystem tab.

  • Before beginning the pruning process, save a backup of the Capture and Diff snapshot (snapshot.xappl). Revert to the original Capture and Diff snapshot in the event of an error.

  • Run and use the native application to understand what registry keys and folders are updated at runtime. This will help determine the proper isolation settings for folders and registry keys.

  • To determine if a folder should be set to full isolation or merge isolation, decide if the user would want access to files created within that folder outside the container environment. If yes, the folder should be set to merge, if no, full.

  • Remove uninstall shortcuts during the pruning process.

Snapshotting Google Chrome Install

Below is a walkthrough of the steps required to snapshot Google Chrome.

Start with a Clean Virtual Machine

When using the snapshot method to containerize an application, it is important to start with a clean system so that no components are missed during the capture and diff process.

The snapshot process can be performed on a virtual machine or a physical machine. Typically a virtual machine is used so that the system can easily be reset in case the process needs to be repeated.

There are many options for virtual machine software including VMWare Workstation, Oracle Virtual Box (free) and Microsoft Virtual PC. In this example I will be using Oracle Virtual Box.

Turbo Studio can be downloaded from https://turbo.net/studio.

In this example we will be creating a snapshot of Google Chrome.

Using the Wizard to Capture the Application Install

Select the third option in the Wizard, Snapshot a third-party application or component.

Select Next on the following screen to capture the "before" snapshot.

Chrome can be installed in two different locations on the system. The standard location is underneath the Current User profile. There is another enterprise installer available on the Google website for installing Chrome under Program Files. In this example the enterprise location will be used, but both approaches will be discussed in the following steps.

Launch Chrome.

Close the open tabs and then exit Chrome (ensure it is not running in the background by checking the system tray and task manager) .

Navigate to Services. Disable both Google Chrome update services.

Open %LOCALAPPDATA%\Google\Chrome\User Data\Default\Preferences with Notepad. Configure the preferences as you see fit. In this example, we set the following configuration:

{ 
  "homepage" : "http://www.google.com", 
  "homepage_is_newtabpage" : true, 
  "browser" : { 
	"show_home_button" : true, 
	"check_default_browser" : false
  },

	"download": {
	"directory_upgrade": true,
	"extensions_to_open": "",
	"prompt_for_download": true

  },
  "bookmark_bar" : { 
	"show_on_all_tabs" : true 
  }, 
  "distribution" : { 
	"msi" : true,
	"system_level" : true,
	"verbose_logging" : true,
	"skip_first_run_ui" : true, 
	"show_welcome_page" : true, 
	"import_search_engine" : true, 
	"import_history" : false, 
	"create_all_shortcuts" : false,   
	"do_not_launch_chrome" : true, 
	"make_chrome_default" : false 
  }, 
  "first_run_tabs" : [ 
	"welcome_page", 
	"new_tab_page" 
  ] 
}

Return to the Turbo Studio wizard. Click Next.

Click Next.

Create a folder named Chrome and Click OK.

Click Next.

Click Next.

Click Next.

Enter filename as chrome49 and then click Save.

Navigate to FileSystem and delete the Update folder found in the install directory.

Delete the Installer folder.

Navigate to Local Application Data (Low Integrity). Delete the Microsoft folder, if it exists.

Navigate to Application Data. Delete the Microsoft folder, if it exists.

Navigate to Registry then navigate to current user root > software. Delete the Microsoft folder.

Repeat this step for:

local machine root\SOFTWARE\Wow6432Node\Microsoft local machine root\SOFTWARE\Microsoft

Navigate to Registry then navigate to current user root > SOFTWARE and set the Google key's isolation setting to Full.

Repeat this for: local machine root\SOFTWARE\Wow6432Node\Google

Navigate to Settings->Process Configuration.

Check the checkboxes for Enable windows class isolation and Always launch child processes as current user.

Set the project type to component and then click Build.

Click Ok to finish and close Turbo Studio.

Copy the created Chrome foldeer that contains the svm file from your VM to a fileshare.

Read http://stage.turbo.net/docs/deploying for information about deploying the application.

Container Settings

The following is a table of the definitions and uses of features available in Turbo Studio. These features allow you to edit and customize the settings for an image or virtual application configuration.

Setting Description
Startup File The executable or viewable file that opens when the user starts the virtual application. Multiple files can be selected by clicking the Multiple button.
Output File The name of the output file from Turbo Studio build process.
Project Type Application: A virtual application project produces an executable file output (.exe file) that can be run directly from the operating system. Application output mode is appropriate for most users and is the default selection.

Component: A component project produces an SVM (.svm file). SVM is a Turbo file format which encode all virtual application configuration and content into a single binary file. SVMs cannot be executed directly from the operating system. SVMs are used to exchange virtual application and component data between multiple virtual applications.

Note: In order to create SVMs for use in streaming applications on Turbo Server, the project type must be set to Component.
Executable Metadata Standard metadata includes information such as product title, publisher, description, icon, web site URL, and version. By default, Turbo Studio applies metadata inherited from the virtual application startup file to the output virtual application executable. To override the default meta data, uncheck the Inherit Properties box.

Custom metadata can be used by specialized external executable viewer applications, inventory scanners, and other asset and licensing management systems. For information on custom executable metadata, consult the Microsoft Windows Software Development Kit.
Startup Image A startup "splash" image to display during application startup. Startup images improve application branding and are useful when the application requires several seconds to initialize.

Transparency keying enables the startup image to contain transparent regions. Transparencies improve the visual effectiveness of your startup image.
Directory Binding Turbo Studio enables you to limit where an application will run, based on queries to an Active Directory Domain Controller.
Command Line Arguments Command line arguments specified by the user are passed to the virtual application startup executable by default. You can override and specify a fixed set of command line arguments to pass to the startup executable. For example, you can specify Java virtual machine behavior.
Sandbox Location By default, the sandbox is placed in the @APPDATALOCAL@\Turbo.net\Sandbox\@TITLE@\@VERSION@ folder, where @APPDATALOCAL@ represents the local Application Data folder, and @TITLE@ and @VERSION@ represent the application title and version. In addition to the standard root folder variables, the sandbox location can contain the following variables:

@TITLE@: Product title
@PUBLISHER@: Product publisher
@VERSION@: Full version string, in dotted quad format
@WEBSITE@: Publisher website
@BUILDTIME@: Virtual application build time, in a format similar to 2008.02.01T08.00.

With the exception of the @BUILDTIME@ variable (set automatically), these variables are based on the values specified in the Properties section of Settings.
Working Directory Working Directory determines the active directory at the time of process launch.

Use Startup File Directory sets the working directory to the directory of the virtual application startup file. In the case of a jukeboxed application, the working directory is set to the directory of the startup file specified on the jukebox command line.

Use Current Directory sets the working directory to the directory from which the virtual application is launched.

Use Specified Path enables you to specify a working directory. This specification can include environment and well-known root folder variables.

The working directory is set to the directory of the startup file by default.
Application Type If you select an executable startup file, Turbo Studio automatically configures the virtual application to run in the same subsystem as the startup file. If you select a non-executable startup file, you must manually override the application type. Most applications execute in the GUI subsystem. To override the application type, select the mode from the Application Type menu in the Process Configuration section of the Settings panel. The Inherit mode sets the application type based on the type of the startup file.
Target Architecture Target Architecture is automatically captured during the snapshot process and generally should not be altered for applications packaged through the snapshot process.
  • x86: Use this option for applications that were packaged using the snapshot process on x86 systems. This option maps the Program Files directory to C:\Program Files on x86 systems or to C:\Program Files (x86) on x64 systems. .NET applications compiled to target any CPU architecture always run as 32-bit applications.
  • x64: Use this option for applications that were packaged using the snapshot process on x64 systems. This option maps the Program Files directory to C:\Program Files on x64 systems. The Program Files (x86) directory is mapped to C:\Program Files on x86 systems and C:\Program Files (x86) on x64 systems. .NET applications compiled to target any CPU architecture run as 32-bit applications on x86 systems and 64-bit applications on x64 systems.
  • Any CPU: This option maps the Program Files directory to C:\Program Files on x86 systems and C:\Program Files on x64 systems. .NET applications compiled to target any CPU architecture run as 32-bit applications on x86 systems and 64-bit applications on x64 systems. Use this option to place a .NET application that is compiled to target any CPU architecture in the Program Files folder.
Environment Variables Most virtual environment variables overwrite any environment variables defined in the host environment. However, PATH and PATHEXT environment variables always merge with the corresponding host environment variables.

Environment variables are automatically captured and merged during the snapshot delta process.
Virtual Services Windows services are specialized applications that run in the background. They are typically responsible for providing system services such as database services, network traffic handling, web request processing, and other server functionality. Many applications install and require specific services in order to function properly. Turbo Studio fully supports virtualization of certain Windows services.

Service installation and settings are captured automatically during the snapshot process. The primary exception occurs with virtualized applications intended to run as background worker services (for example, virtualized web servers); in this case, it is often required to enable the Keep Alive option.
SVMs You can specify additional SVM layers for applications, in the case of updates or patches.
Child Process Exceptions Some applications create new child processes while they run. Depending on the virtual application context, you can create such child processes within the virtual application, or in the host operating system.

Child processes include processes created to service COM local server requests.

Note: Child processes created outside of the virtual application cannot access virtualized filesystem or registry contents. These processes can access or modify host operating system contents, even if otherwise forbidden by the virtual application configuration.

Child processes are created within the virtual application by default. To manually create child processes outside of the virtual application, uncheck the Spawn child process within virtualized environment option.

COM servers are created outside the virtual environment by default to allow COM communication between native applications and virtual applications. To create COM servers within the virtual environment, check the Spawn COM servers within virtualized environment option.

You can determine exceptions to the child process virtualization behavior using the Child Process Exception List... Process names listed in the child process exception list behave opposite to the master child process virtualization setting. To edit the child process exception list, select the Child Process Exception List... button. Process names will match without including the filename extension.
Read-only Virtual Environments Prevent modifications to the virtual environment.
Automatic Sandbox Reset Any changes made to an application's virtual environment are reverted when the application closes.
Shutdown Process Tree On Root Process Exit Enables the shutdown of all child processes when the root process exits.

Note: The startup file is the root process by default. If a virtual service is specified in the application configuration file and is set to auto-start when the application is launched, the virtual service acts as the root process in the process tree.

Compress Payload Enables compression of the output file. Note: Both the application profiling and streaming processes require that packages be built uncompressed. To build applications without compression, leave the Compress payload option unchecked.
Startup Executable Optimization Launches the startup executable within the initial virtual machine process. This prevents the creation of a separate application process and can be incompatible with some applications.
Turbo Command-line Arguments Turbo supports command-line arguments of the /X[arg] form, which modify virtual application behavior at run-time. In rare instances, these arguments may conflict with command-line arguments designed for use by the virtualized application. To disable processing of these arguments, uncheck the Enable Turbo command-line arguments box.
Window Class Isolation Prevents viewing window classes that are registered by external processes. You can use this to prevent interaction between virtualized and non-virtualized versions of the same program when the application checks for existing class registrations.

Enhanced DEP Compatibility for Legacy Applications Enables compatibility for systems with Data Execution Protection (DEP) enabled. Use this configuration for virtual applications running on Windows 2003.
Enhanced DRM Compatibility Enables additional compatibility with common DRM systems, such as Armadillo.
Trace Process Starts in Debug Output Sends a notification to OutputDebugString whenever a new process is started within the virtual environment. This notification is in XML format and comes as a basic information description. It can be monitored with any debugging tool. You can also monitor the notification by a parent process within the virtual environment if a child process is being debugged.
Force Read-share Files Forces any file opened within the virtual environment to open with the READ_SHARE flag. Use this option to resolve compatibility issues caused by sharing violations.
Always Launch Child Processes as Current User Provide child processes with the same level of privileges as the virtual machine root process. Child processes launched by the virtual machine have reduced privileges by default.
Emulate Elevated Security Privileges Forces an application to run as if it has elevated security privileges, even if the application does not. Enabling this option eliminates UAC security prompts for elevation and subsequent application crashes.

Standalone Executables

A popular option for organizations that have an existing endpoint management solution like LANDesk Management Suite ®, Microsoft System Center, or Novell ZENworks is to deploy containerized applications as standalone executables. These executables are built on the SVM architecture and work just like a container.

Deploying applications within containers is convenient for running different versions of applications like Internet Explorer 8 and 11 side-by-side on the same system.

To produce an executable output, set the Project Type to ISV Application in Turbo Studio. Executables can be deployed directly to the users device or to a network share and do not have any dependency requirements.

An enterprise license for Turbo Studio is required to enable executable outputs. Contact our sales team for more information.

Command Line Options

Standalone executables have many command line options to change settings at runtime. The following is a list of available options. Note that these are case sensitive and must be specified before any command line options to the application itself.

Setting Description
/XEnv=VariableName=Value Specifies additional environment variables. Multiple /XEnv arguments can add additional environment variables.
/XLayerPath=LayerPath Adds the given SVM into the virtual environment. Multiple /XLayerPath arguments can add additional virtual layers. Refer to 'Specify Additional SVMs for a Container' for more information.
/XSandboxPath=SandboxPath Specifies the path for the application sandbox.
/XShellEx=Command Specifies a shell execute command to launch from within the virtual application environment. This option overrides any startup files specified in the virtual application configuration. Only one /XShellEx argument can be specified.
/XShellExVerb=CommandVerb Specifies the verb to use in conjunction with the XShellEx command. The default verb is OPEN.
/XLogPath=LogPath Specifies the destination path for generated log files (only applies to executables running in diagnostic-mode). This path can include a custom file name pattern (ie. "/XLogPath=c:\logs\mylog*.log"). The output directory must exist for the logs to be written.
/XSpawnVmExceptions=ProcessExceptions Accepts a semi-colon delimited list of processes add to the child process exception list.
/XRegRoot=RegistryCacheRoot Specifies an override to the runtime-registry-cache portion of the sandbox.
/XEnable=Setting and /XDisable=Setting Enables or disables specific process configuration options. These options include: ChildProcAsUser DeleteSandbox DEPCompat Diagnostics DRMCompat ExeOptimization IndicateElevated IndicateVirtualization IsolateWindowClasses NotifyProcStarts ReadOnly ReadShare ShutdownProctree SpawnComServers SpawnVM SuppressCollisionCheck

See VM Settings for details on the available settings.

/XCollisionCheck=FALSE Disables detection of multiple apps attempting to use the same sandbox at the same time. This should only be used to support legacy behavior.

Specify Additional SVMs for a Container

When you have updates or patches you can use Turbo Studio to specify additional SVMs for applications. Studio provides two mechanisms to accomplish this. Both methods support path tokens (ie. @APPDIR@) and must specify the full path to SVM dependencies.

Using Studio

One mechanism is to specify the SVM dependencies in Turbo Studio.

The SVMs dependency editor can be accessed by clicking on 'Settings' button, then 'Process Configuration' tab, then 'SVMs' button.

The first field is the 'SVM Search Pattern' field. Here users can enter the complete path to where multiple SVMs are located using a wildcard. An example of using a wildcard in the search field is '@APPDIR@\patches*.svm'.

Multiple SVMs may be specified for the 'SVM Search Pattern' field in a semi-colon delimited list. SVMs specified first in the list will take precedence over SVMs specified later in the list. If multiple SVMs match a search pattern through the use of the '*' wildcard, the SVMs are applied in reverse-alphabetical priority (ie. items in patch_002.svm would have higher priority than items in patch_001.svm).

The second field allows required SVMs to be specified. Wildcard characters are not valid for this and a specific path must be used. If the file is not found during application launch, an error will be reported and the launch will be aborted.

Using Command Line

Another mechanism is by using the /XLayerPath= command line option. This parameter takes a path to additional SVMs to load. This can be useful for dynamically creating container environments depending on other user settings. These runtime settings augment any which are built into the SVM.

An example of a specified SVM path using full path:

# look for 'patches.svm' in the same directory as 'virtual-app.exe'
> virtual-app.exe /XLayerPath=@APPDIR@\patches.svm

# look for 'patches.svm' in a specific location on the local machine
> virtual-app.exe /XLayerPath=c:\path\to\patches.svm

# look for 'patches.svm' on a unc share
> virtual-app.exe /XLayerPath=\\server\dir\patches.svm

An example of specifying SVMs from multiple locations:

> virtual-app.exe /XLayerPath=@APPDIR@\patches.svm /XLayerPath=@APPDIR@\officepatches.svm

An example using a path with wildcard:

> virtual-app.exe /XLayerPath=c:\path\to\patches\*.svm

This performs a wildcard match finding any files that match the pattern, such as 'c:\path\to\patches\patch_001.svm'.

Note: SVMs that are discovered by wildcard are applied in reverse-alphabetical priority. For example, items in 'patch_002.svm' have higher priority than items in 'patch_001.svm'.

Large Executables

Where creating container packages, it is possible that the virtual .exe packages exceed 4GB in size. This is a problem because Windows has a hard limit of 4GB for .exe files and will not allow them to be executed and you will get an error message like this:

The solution for this is to split your package into two pieces, one small .exe and one large .svm. Then, at runtime, combine them using the above mentioned techniques (either with /XLayerPath or specifying required layers in Turbo Studio).

Follow these steps to convert your existing container image xappl:

  • Save a copy of your xappl as data.xappl.

  • Open data.xappl in Turbo Studio

    • Change the Project Type to Component

    • Change the Output File to data.svm

    • Save the file and build

  • Open your existing xappl in Turbo Studio

    • Add @APPDIR@\data.svm to the SVM Search Pattern and data.svm to the list of required layers

    • Remove everything from <Filesystem> and <Registry> nodes. If you have multiple layers, you can remove all layers other than the default layer. If your application is configured to inherit metadata and icons from the startup file, then you will need to keep the startup file .exe in the <Filesystem> node (including its full directory hierarchy).

    • Save the file and build
  • To deploy, place your .exe and your .svm in the same directory.

Startup File Triggers

A container package can define several startup files. These can all be activated on launch or they can be configured to only be launched given a specified trigger. This is useful for suite applications (like Microsoft Office) where most of the container package is shared.

In Turbo Studio, the startup file triggers are managed in the 'Startup Files' dialog.

In this example, an application package is defined with three startup files; word, excel, and access. Any startup files that don't have a specific trigger or have Auto Start enabled will be launched by default. Any startup file that has a trigger (but not 'auto start') will not be launched unless the trigger is specified. Multiple startup files can have the same trigger to enable grouped launching.

To launch a startup file by its trigger, specify its trigger as the first parameter to the container .exe:

# to launch word
> virtual-app.exe WORD

# to launch access
> virtual-app.exe ACCESS

# to launch excel
> virtual-app.exe EXCEL

# to launch excel as the default
> virtual-app.exe

To create an easy-to-access shortcut for a trigger, right-click on your packaged executable and select Create shortcut. Then, right-click on the newly created shortcut and append the trigger to the Target field. Change the shortcut name and icon to differentiate the application entry point that will be launched when the user runs the shortcut.

Building from the Command Line

The command-line version of Turbo Studio is called XStudio.exe and can be found in the Turbo Studio installation directory. See below for a list of command-line arguments and options for the XStudio tool.

Command Usage Description
<path to XAPPL configuration file> /l <path to license file> [/o <path to output>] [/component] [/d] [/compressed] [/uncompressed] [/deletesandbox] [/v <version>] [/startupfile <virtual path to file>]

Builds the virtual application based on the application configuration file.

/l - Path the the license file. The license file needs to be stored in Unicode format.

/o - Path to the output file. This will override the setting in the XAPPL configuration file.

/component - Sets the Project Type to Component resulting in an SVM output rather than EXE output. 

/d - Enables the Generate diagnostic-mode executable setting.

/compressed - Enables the Compress payload setting.

/uncompressed - Disables the Compress payload setting.

/deletesandbox - Enables the Delete sandbox on application shutdown setting.

/v - Sets the Version of the output exe.

/startupfile - Sets the Startup File of the virtual application.

/before

/beforepath <path to where snapshot file is saved>

Performs a before snapshot and saves the snapshot to the specified folder.

/beforepath - Path to the where the snapshot file is saved.

/after

/beforepath <path to where snapshot is saved> /o <path to where XAPPL configuration file is saved>

Performs an after snapshot using the specified before snapshot path.

/beforepath - Path to the before snapshot file.

/o - Path to where the XAPPL configuration file is saved.

/import

/i <path to the configuration file to be imported> /o <path to where XAPPL configuration file is saved>

Import MSI, AXT, or ThinApp configurations.

/i - Path to the configuration file to import.

/o - Path to where the XAPPL configuration file is saved.

/sandboxmerge

/i <input-config> /o <output-config> <sandbox-path>

Merge configuration and sandbox.

/i - Path to source configuration file.

/o - Path to output merged configuration file.

sandbox-path - Path to sandbox.

/vmsettings

/i <input-file-xappl-exe-svm> [name]

Getting virtualization settings from the configurations file or application.

/i - Path to the configuration file (xappl, exe or svm).

name - Name of settings or empty for all settings.

/pathreplace

[/reg] [/revert] <path>

Replace path from native to virtual format.

/reg - Path is a register path instead of filesystem path.

/revert - Revert path from virtual to native format.

path - Path to replace.

/nologo

Switch for suppress printing copyrigth and logo information.


**Note:** Configuration files that are generated from the command-line after using the **/after** flag do not have an output file specified in the **XAPPL** configuration file. When using scripting for snapshots, it may be necessary to apply changes to the generated **XAPPL** file, either manually or programmatically.

Note: If running XStudio displays the error, " is missing from the string table", it is because the XStudio application cannot be run while Turbo Studio is also running. Turbo Studio must be closed before running XStudio via the command line.

Startup/Shutdown Scripts and Shims

Turbo Studio allows for custom operations to be performed at the beginning and end of a container's life. This allows for application specific configuration steps to be performed before a container starts (ie. install a necessary driver) or clean up to be performed afterward.

Container Life Cycle

Containers are managed with a root parent process known as a "boostrap process". This process hosts the virtual machine engine from which the rest of the container executes. In the Turbo command line environment, turbo.exe hosts a shared bootstrap process for each instance of the same container. For Turbo standalone executables ("ISV Applications"), a seperate bootsrap process is used for each invocation of the .exe.

Startup shims and scripts are executed when the container bootstrap process is started but before the startup files are started. Execution of the shims and scripts will block the startup files so any long running operations will delay container startup.

Shutdown shims and scripts are executed when the container bootstrap process is closed.

Note that because of the nature of mulitple possible bootstrap processes for standalone executables, multiple executions of the shims and scripts may occur if multiple invocations are possible. Therefore they must be written handle that case.

Scripts

For simple tasks, a .bat or .cmd script can be configured.

Put the script in the container file system (a full isolated folder in @SYSDRIVE@ such as "scripts" is recommended). Specify the full path to the script in studio. Note that the untokenized form of the path must be used here ("c:\scripts\init.cmd" rather than "@SYSDRIVE@\scripts\init.cmd").

An example startup script might look like this:

    @ECHO Initializing environment
    if exist C:\workspace\first goto Skip
    
    :Create-Workspace
    @ECHO Preparing Workspace
    mkdir C:\workspace\first
    echo print("Hello World!") > C:\workspace\first\helloworld.py
    goto Done
    
    :Skip
    @ECHO Workspace already created, skipping step
    
    :Done
    @ECHO Done.    
    exit

A common use of startup scripts is to install some required component (driver, etc) to the native system if not already present. Such installers will require admin privileges so will require UAC elevation. Below is one way this can be accomplished using a runtime generated VBS script:

    # create vbs script to ShellExecute a command with "runas" verb to show the UAC prompt if required
    echo Set UAC = CreateObject^("Shell.Application"^) > "%temp%\elevate.vbs"
    echo UAC.ShellExecute "cmd.exe", "/c ""c:\path\to\installer.exe", "", "runas", 1 >> "%temp%\elevate.vbs"
    
    # execute the vbs script and wait until it completes
    start /b /wait >nul cscript /nologo "%temp%\elevate.vbs" 2>&1
    
    # clean up
    del "%temp%\elevate.vbs"

To troubleshoot script issues, set the "__DEBUGINITSCRIPTSHIM" environment variable to "true". This will show the command window that is executing the script so you can see output and any generated errors.

Shims

For complex tasks, a DLL can be written to be executed. DLLs can be written in any programming language that supports them but do note any framework requirements must be configured inside the container.

The shim must conform to Turbo Studio interface in order to be loaded properly. Startup shims must be compiled with an exported OnInitialize function. Shutdown shims must be compiled with an exported OnShutdown function. The same DLL can be used for both if both functions are exported.

Shim function signatures: typedef BOOL (__stdcall *FnOnInitialize) (LPCWSTR pwcsInitializationToken); typedef void (__stdcall *FnOnShutdown)(LPCWSTR pwcsShutdownToken);

The return value of the startup shim indicates to the bootstrap process whether it should proceed with execution of the container.

The functions are acquired by the virtual machine with ::LoadLibrary and ::GetProcAddress calls.

    LPCWSTR pwcsInitToken = "VendorSpecificToken";
    HMODULE hShim = ::LoadLibrary("c:\path\to\shim.dll");
    FnOnInitialize fnOnInit = (FnOnInitialize)::GetProcAddress(hShim, "OnInitialize");
    BOOL fResult = fnOnInit(pwcsInitToken);

Note that the DLL must be compiled for the correct architecture (x86 or x64) in order to be loaded. Since the DLL is loaded by the bootstrap process, it must match its architecture, not the startup file.

MSI Settings

The following is a table of descriptions of the settings that you can use for MSI outputs from Turbo Studio.

Setting Description
Output location Name and location of the MSI file output.
Product Info Meta data that will go into Add/Remove Programs when the application is installed.
  • Product Name
  • Product Version
  • Company Name
Installation Parameters Specifies where to install the application and if it will be installed for all users or in the current user profile.
Shortcuts List of Start Menu and Desktop shortcuts that are created when the MSI is installed.
ProgIds List of ProgIds that are created on the host system when the MSI is installed.
Extensions List of file extensions that are configured on the host system when the MSI is installed.

Troubleshooting

Once your container package is built, it is time to test on the platforms that you expect to encounter. When issues surface there are several things that can be done to track down the cause.

Turbo.net Professional Services

Turbo has a team of knowledgable support engineers to help you build your packages. We can help you through any problems that you face. Email our team at support team. See Support Programs for more information on the services that we offer.

Diagnostic Mode

When troubleshooting issues with containers, it is often useful to generate diagnostic logs for analysis. These logs show detailed information about system calls and error codes that were generated during the application life.

There are three ways to enable diagnostic mode. With all methods, the log files will be written to the same directory as the container .exe unless the /XLogPath command line parameter is used.

The first way is to create a diagnostic mode build of your container. This is done in studio by selecting the 'Generate diagnostic mode executable' build option.

The second way is using a command line parameter. This allows access to diagnostic information without rebuilding your container package.

> virtual-app.exe /XEnable=Diagnostics

The third way is using an environment variable. This allows access to diagnostic information when the command line options are not easily modified (ie. service containers, container launched from non-container, etc).

> SET __VMDIAGNOSTICS=true
> virtual-app.exe

NOTE: Can also specify this as a global environment variable.

Analyzing Logs

In diagnostic mode, a log file will be created for each process that is spawned in the container environment. By default the virtual machine logs are named "xclog_[pid].txt" and the network logs are named "xcnetwork_[pid].txt", where "pid" is the process ID in hexidecimal format. The virtual machine logs show diagnostic information about the code executing in the process. The network logs show specifics about network handling, virtual proxies, and routing.

Virtual Machine Logs

Virtual machine logs show every system function call that comes from the process.

An example of a log is below:

pid:1240, tid:5416, tick:0x1757B5, lvl:LOG, func:NtQueryValueKey, status:0xC0000034, name:"InprocServer32", class:0x2, length:0x90, resultlength:0x0, handle:0x79E, path:"\Registry\Machine\Software\Classes\CLSID\{4B429D05-8931-11D2-A213-0008C71AB540}\InprocServer32"

The fields of the log entry are:
pid - The ID of the process that generated the log entry.
tid - The ID of the thread that generated the log entry.
tick - The tick count when the log entry was written. Tick count is the number of elapsed milliseconds since the machine was started.
lvl - The severity of the log entry. Possible values include "OK", "LOG", "WRN", and "ERR". "OK" indicates the entry was a success case. "LOG" indicates that the function failed or was other informative non-function call log entry. "WRN" indicates that something failed unexpectedly and may suggest a problem. "ERR" indicates that something failed unexpectedly and is likely a problem. Note that not all "LOG" entries are ignorable and every "ERR" entry is a problem, any log entry requires analysis based on the context of the call.
func - The function where the log entry was written from. Most often these will be Windows APIs that have entries in Microsoft Docs or Microsoft Developer Network that can give more context about the parameters in the log entry.
status - The NTSTATUS code that is returned from the function. See NTSTATUS Values for a list of values. In this case we see 0xC0000034 which is for STATUS_OBJECT_NAME_NOT_FOUND. Not all functions return NTSTATUS codes. Some may have "gle" which is the system error code returned from GetLastError. See System Error Codes for a list of values. Other functions have "hr" which is for an HRESULT code. HRESULT values are usually very context specific so no single resource catalogs their values. A quick web search will often find their meaning.

After the return value, the log entry will show the list of parameters that were passed to the function. This will depend on the function being called and is where checking the Microsoft documentation can be helpful.

In our example for "NtQueryValueKey", the Microsoft documentation is here. Note, many of the function calls in the virtual machine are at a very low level and will be listed in the documentation for drivers with "Zw" rather than "Nt" (ie. "ZwQueryValueKey" not "NtQueryValueKey"). This is Microsoft naming convention for user-mode and kernel-mode APIs.

In this doc, we see that the signature for "NtQueryValueKey" is:

NTSYSAPI NTSTATUS ZwQueryValueKey(
  HANDLE                      KeyHandle,
  PUNICODE_STRING             ValueName,
  KEY_VALUE_INFORMATION_CLASS KeyValueInformationClass,
  PVOID                       KeyValueInformation,
  ULONG                       Length,
  PULONG                      ResultLength
);

From this Microsoft documentation, we see that the purpose of this function is "return a value entry for a registry key" and the remaining fields of the log entry are:
name - The name of the value entry to obtain data for.
class - A KEY_VALUE_INFORMATION_CLASS value that determines the type of information returned in the KeyValueInformation buffer. For more information about the values that this can be, see the doc on KEY_VALUE_INFORMATION_CLASS.
length - The size, in bytes, of the KeyValueInformation buffer.
resultlength - The size, in bytes, of the key information.
handle - The handle to the key to read value entries from. This was created by a previous call to NtCreateKey or NtOpenKey.
path - The resolved path in the container that the handle represents.

From viewing this log entry, we can determine that this thread was looking up a COM GUID to determine how it should be activated. It was not able to find the information it was looking for at this location. This might be a problem or it might continue its search in another location (ie. in HKCU, etc). NOTE: There are always many error codes returned by system calls so determining which error is causing a problem can be tricky.

This is just one example but following the same procedures to cross reference with Microsoft documentation can be used to decipher most any log entry.

Virtual Machine Analysis Strategies

Virtual machine logs are frequently very large and it can be a difficult task to isolate which of the many error conditions are causing problems. There are several techniques that can be employed to make the task easier.

The first technique is to compare working logs to failing ones. In many cases, a container will work in most situations but fails in a certain environment. Collecting logs on both working and failing machines allows us to ignore the errors that are "expected" and focus only on those that are unique. This technique is most useful when there are working and failing cases on very similar platforms (ie. both Win7 x64). Comparing logs from different platforms (ie. WinXP vs Win10) often have too many differences to be of much use. To compare the logs, tools such as WinDiff or WinMerge can be used. Even having the files open side-by-side can produce results.

The second technique is to narrow the scope of the logs that you have to look through. For example, if an error only occurs after a button is pressed, then copying off the logs immediately before and after the button press will allow you to determine the set of log entries that were written for the operation that led to the error (the difference between the before and after logs). This can be especially effective when coupled with the first technique of comparing working to failing logs.

Network Logs

Network logs show details about any network operations that pass through the process.

An example of a log is below:

Bind succeeded: 127.0.0.1
Connect succeeded: 127.0.0.1
GetAddrInfoW resolving detectportal.firefox.com
Host detectportal.firefox.com resolved to: 104.80.89.26
Host detectportal.firefox.com resolved to: 104.80.89.24
GetAddrInfoW resolving detectportal.firefox.com
Connect succeeded: 104.80.89.26
Host detectportal.firefox.com resolved to: 104.80.89.26
Host detectportal.firefox.com resolved to: 104.80.89.24
DnsQuery_A resolving a1089.d.akamai.net
GetAddrInfoW resolving location.services.mozilla.com
Host location.services.mozilla.com resolved to: 34.252.164.43
Host location.services.mozilla.com resolved to: 52.16.107.9
Host location.services.mozilla.com resolved to: 52.17.111.251
GetAddrInfoW resolving location.services.mozilla.com
Host location.services.mozilla.com resolved to: 34.252.164.43
Host location.services.mozilla.com resolved to: 52.16.107.9
Host location.services.mozilla.com resolved to: 52.17.111.251
DnsQuery_A resolving locprod1-elb-eu-west-1.prod.mozaws.net
Host locprod1-elb-eu-west-1.prod.mozaws.net resolved to: 52.16.107.9
Host locprod1-elb-eu-west-1.prod.mozaws.net resolved to: 52.17.111.251
Host locprod1-elb-eu-west-1.prod.mozaws.net resolved to: 34.252.164.43

This log snippet was generated by starting an instance of a Mozilla Firefox browser container. Here we see that the winsock calls to GetAddrInfo, DnsQuery, etc were made as well as how each of the hosts were resolved. These logs can be especially useful when troubleshooting issues with virtual network routing and proxies.

Viewing Container Environment

Some problems are caused because the xappl configuration didn't render an environment as was expected. To determine if files and registry keys are as they should be, instances of Windows command prompt or registry editor can be started in the container.

To start a command prompt instance in a virtual application's container environment:

> virtual-app.exe /XShellEx=cmd.exe

This will start a command prompt inside the application's container. Now you can move around the file system to see exactly what the application's in the container can see. Make special considerations for paths that have 32-bit vs 64-bit implications (ie. "program files" vs "program files (x86)"), especially when troubleshooting environments with mixed process architectures.

Note, it is easy to forget that a command prompt is for the container rather than for your native system. To prevent confusion it is recommended to set the title of the command prompt by executing title in container which will put "in container" as the prompt title.

To start a registry editor instance in the virtual application's container environment:

> virtual-app.exe /XShellEx=c:\Windows\system32\regedt32.exe
-OR-
> virtual-app.exe /XShellEx=c:\Windows\syswow64\regedt32.exe

This will start an instance of the registry editor inside the container environment. Note that Windows only allows one instance of the registry editor to be running so close down all other instances before running this command or else you may not be viewing what you think you are.

The 32-bit vs 64-bit registry is also something to be aware of with the registry editor. Select the registry editor to launch based on the architecture of the process that you are investigating.

Questions? Projects? Talk to us.