Requirements

The following items and knowledge are required for use of this procedure:

• Familiarization with instructions on how to virtualize a software product via ThinApp (see, “How to Make a ThinApp Application” on the VMware ThinApp Blogs).

DISCLAIMER!

This site may contain information about third party products, services, tools and/or applications that are not owned or controlled by Ervik.as.Ervik.as does not endorse or make any representations or warranties about such third party products, services, tools and/or applications referenced in this site.

Notes:

It should be noted that the tools and applications listed are just examples of what can be used for application troubleshooting in general and techs should not limit themselves to just the applications/tools mentioned.  Don’t just think “outside the box” – think inside the app.  What does the app need or want to see?  What tool will tell you or help you find out what that app is looking for?  Once this information is found, how can you get the application to behave in a manner that works properly in your network environment?  Is there some tool which will help you make that cumbersome app work the way you want/need it to?

Those are the general things to keep in mind when working with an application, regardless of ThinApp or not.

Application Troubleshooting Tools

Running Process Viewers

One of the first things needed is a process viewing tool which, at minimum, shows all running processes in a detailed manner.  Having a process viewer which shows what files, registry keys and other objects processes have open, which DLLs they have loaded, etc., is a big plus when trying to find out what the troublesome application is attempting to do.

An example of a process viewer which provides more details than the built in tool is Process Explorer by Microsoft.

Activity Loggers

It is a must to have a process monitoring tool which will log all activity of an application and allow a tech to review which folders, files, registry keys, registry entries, and other objects is a must.  This kind of tool can be used as a first step in troubleshooting a misbehaving application in general (ThinApp non-specific).

An example of a process monitoring tool is Process Monitor by Microsoft.  Additionally, Microsoft has retained the predecessors to this tool which are FileMon and RegMon by Sysinternals.

Dependency Viewers

A dependency viewing tool will allow a tech to select an application’s executable and view all modules it is dependent upon.

A tool that falls into this category is Dependency Walker – a free tool that is available for download from https://www.dependencywalker.com.

Open Handle Viewers

Every now and then it is necessary to see what open handles are locking a file or registry entry.  Having a tool which shows that is a plus.

An example of something that shows this is Handle by Microsoft.

File Explorer

The majority of all techs use the built in Windows Explorer and Command Line to browse and manipulate the file structure but there are plenty of other file explorer and editing tools available for free or for a small price on the Internet.

Examples of 3rd party file explorers which should work within a ThinApp packaged application are the A43 File Manager (which does not need to be installed but can be copied into a package) and Windows File Explorer by Soft32.com (which requires an installation at the same time as the application).

Registry Editor

To mirror the file explorer comments, most techs use the built in Windows Registry Editor to view, browse, and modify the registry of a Windows system.  There are plenty of free and inexpensive registry editors available for download from the Internet which have different functionalities.

ThinApp Packaging and Troubleshooting Tools

Folder Isolation Viewer

While there is no substitute for knowing how to work with a file structure in Windows Explorer and a Command Line, it is sometimes necessary to get a different view of the file structure with isolation levels.  Having a graphical interface tool which can quickly display a ThinApp project’s folder isolation settings can prove to be very helpful.

There are plenty of free tools which can be used for this.  Examples are the Thinstall Helper by the CIS Group and the Folder Isolation Viewer by Bob Carter.

NOTE: 3rd party tools should be used with care as some of them are written for specific versions of either ThinApp or Thinstall and may not work correctly with projects created by newer versions of ThinApp.

Registry Isolation Viewer

To mirror the comments about the Folder Isolation Viewer, there is no substitute for knowing how to work within the Windows Registry; however, there are times when a graphical representation can help.

There are a number of freely available tools on the Internet.  Examples are the Thinstall Helper by the CIS Group and the Registry Isolation Viewer by Bob Carter.

NOTE: 3rd party tools should be used with care as some of them are written for specific versions of either ThinApp or Thinstall and may not work correctly with projects created by newer versions of ThinApp.

ThinApp Log Monitor

ThinApp’s own log monitor utility is great for monitoring everything a packaged application does or attempts to do.   It can provide numerous amounts of information with regards to any issue the package application may be having.

Large Text File Viewer

It is essential to have a text editor for viewing large log files and ThinApp registry files.  While Windows Notepad is easy to use in a pinch, because of the fact that ThinApp’s Log Monitor utility can generate text files in excess of 1GB in size, it is beneficial to have a text file editor which can view and manipulate text files of larger sizes as Windows Notepad cannot handle files beyond 1GB very well.

EditPad Lite by JGSoft and Notepad Lite by GridinSoft are examples of free text editors capable of reading large text files.

Comparison Utility

Having a tool which can compare files, folders, and registries is highly beneficial for comparing ThinApp Projects for differences when one package works and another package doesn’t.

A comparison utility available for purchase is Beyond Compare by Scooter Software.
NOTE: At last check, Scooter Software gives 20% discounts on Beyond Compare purchases by entering the discount code of “THINAPP”.

Multilanguage Scripting Editor

Another tool worth having is a Multilanguage script editor – specifically something that can handle VBS, BAT, CMD, and INI files, and give abilities to interface with DBs, LDAP, ADSI, WMI, and COM objects.  Having a script editor which can also build executables out of the scripts which it can support is also a plus.

An editor that falls into this category is Admin Script Editor by iTripoli.
NOTE: At last check, iTripoli gives 20% discounts on any purchase of Admin Script Editor by entering the discount code of “THINAPP”.

ThinApp Multi-Version Builder Utility

When testing against issues which may potentially be related to ThinApp, it is very beneficial to have a way to easily test a package against multiple versions of ThinApp.  This tool easily allows the building of ThinApp projects into packages with different versions of ThinApp.

This tool can be found on the T3chNot3s blog.

NOTE: This is a 3rd party blog which is NOT sponsored in any way by VMware. 3rd party tools should be used with care as some of them are written for specific versions of either ThinApp or Thinstall and may not work correctly with projects created by newer versions of ThinApp.

ThinApp Multi-Version MSI Loader

This tool works in support of the afore mentioned ThinApp Multi-Version Builder Utility as it allows techs to easily load up ThinApp MSIs for multiple different versions of ThinApp.

This tool can be found on the T3chNot3s blog.

NOTE: This is a 3rd party blog which is NOT sponsored in any way by VMware. 3rd party tools should be used with care as some of them are written for specific versions of either ThinApp or Thinstall and may not work correctly with projects created by newer versions of ThinApp.

ThinApp Tips

Long File Names Issue

Often times when packaging larger projects, techs will run into long file name issues when using the default folder of “C:\Program Files\VMware\VMware ThinApp\Captures“.  An easy fix for this is to not use the Captures folder in this location but to create another captures folder off the root of the C: drive (“C:\Captures”).  Another way to easily fix this issue is to create a substitute drive which maps directly to the “C:\Program Files\VMware\VMware ThinApp” folder.  The command is as follows:
SUBST.EXE “C:\Program Files\VMware\VMware ThinApp“

NOTE:  The above command can also be placed in a shortcut located in the Startup folder of the packaging system.

Running Explorer and 3rd Party File Browsers

Running an application which spawns a Windows Explorer window will, by default, launch that EXPLORER.EXE process outside the virtual environment.  This is due to embedded settings within the Windows Operation System and EXPLORER.EXE itself.  The EXPLORER.EXE process is actually designed to first check to see if another instance of EXPLORER.EXE is running and, if not, launch itself as the desktop shell.  Therefore, all Windows Explorer processes will always reside in the physical environment unless the initial EXPLORER.EXE process is launched within the virtual environment.  See the ThinApp blog article on Running EXPLORER.EXE Inside the Bubble as well as the blog article on Creating Windows Entry Points for Troubleshooting ThinApp Packages – both can be found on the VMware ThinApp Blogs.

A number of 3rd party file browsers are present on the Internet for download which can be utilized to give the user and/or administrator of the ThinApp packaged application a view into the virtual file system – or at least, what the application thinks is the real file system.

An example of a free file browser is the A43 File Manager.  To utilize this tool, place a copy of it into your ThinApp project and create an entry point for it within your ThinApp Project’s PACKAGE.INI file.

Folder Sharing

Sharing out the VMware ThinApp folder on the host system is also a great way to allow VMware Workstation VMs running on that system access to save ThinApp Project captures by default (without manual intervention).  This means that ThinApp does not have to be installed onto the VMs prior to capturing and project folders do not need to be manually copied off the VMs prior to restoring the VMs to a known good snapshot.

See the article on How to Make a ThinApp Application Package on the VMware ThinApp Blogs.

Sandbox Redirection

Redirecting the default sandbox for test systems to a folder of easy access (i.e. “C:\TEMP\SANDBOX”) may be a way in which to easily troubleshoot packaged applications.

See the “Controlling the Sandbox Location” section of the ThinApp Online Documentation for more information.

Using Compression

If troubleshooting or fine tuning a ThinApp package where constant rebuilds are occurring, it may improve efficiency in testing on larger projects if FAST compression is used as this decreases the time of the subsequent builds/rebuilds of the package in question.  This occurs because ThinApp creates a Build Cache where it stores all compressed files in the event of subsequent builds of the project.

Note:  Some files or file types in a project may have issues with being compressed.

Adjusting the SNAPSHOT.INI

In some instances, you may be wondering how to not continually capture a specific file or registry setting. The default settings of ThinApp can be modified by editing the SNAPSHOT.INI file in the VMware ThinApp folder. These are the default settings with which ThinApp Setup Capture operates by.

Why would you modify this file? Well, maybe you have a utility program set to run upon startup of your VM and you don’t wish for the outcome of that to be captured by ThinApp. Or, maybe you need to capture a Windows setting which, by default, is set to NOT be captured so that your application will properly run when packaged with ThinApp. Or maybe you are building specific versions of the same application and you know you need certain folders or registry settings to always be set to WriteCopy vs. Full or Merged. These types of modifications can be made by customizing your SNAPSHOT.INI.

NOTE: It is recommended to make a backup of the SNAPSHOT.INI prior to any modifications!!

Periodic Cleanup

Periodically performing cleanup of the ThinApp Build Cache is function which can keep the build system from running out of disc space.  Check the size of the “%USERPROFILE%\Local Settings\Application Data\Thinstall\BuildCache” folder and delete its contents if you deem it safe to do so.

Run the App

One of the biggest tips for properly capturing an application is, once the application is installed, run the application.  This is not only for testing the application – for an application which won’t work natively in Windows will not work as a ThinApp packaged app either (i.e. Junk In – Junk Out) – but also for the many types of applications which don’t finish their setup until the first run of the application.  An example would be applications which ask for file type associations upon first launch.

 

VMware Workstation Snapshots

VMware sells ThinApp with a licensed copy of VMware Workstation for a couple of reasons.  First and foremost, this is done to give customers an environment which is not intermixed in any way with their production system.  Secondly, this is done to keep customers from having to reallocate a production system or purchase a lab specific system for packaging, and finally, it’s done to add in the snapshot abilities of VMware Workstation.

A single clean Windows VM can be snapshotted at the clean build state and cloned (full or linked) to create a near infinite number of test environments.  Because of this, one can conduct a pre-installation ThinApp Setup Capture, install the application, test it, and keep this configuration for later troubleshooting, but still be able to role back to a clean build for additional application packaging.

 

Setup Capture Command Line for GUI

A big benefit of using ThinApp over competitor products to package applications is it’s use of the tried-and-true delta snapshot technology and it’s non-requirement to be running during the installation of an application.  In short, this means one can install the application exactly the same way they would install it on a regular workstation.  More importantly, this means the clean VM can be rebooted as many times as necessary.  After each reboot of the VM, ThinApp Setup Capture will re-launch, picking up where it left off.  If the application installation or configuration is not complete, simply cancel the setup capture or close it by clicking the red “X”.

This information to relaunch the GUI upon login is stored in registry under the following key.
HKEY_CURRENT_USER\SOFTWARE\MICROSOFT\WINDOWS\CURRENTVERSION\RUN
Entry:  ThinApp Setup Capture Continue
Value:  “<DRIVE:\><PATH\>SETUP CAPTURE.EXE” “<DRIVE:\><PATH\><SNAPSHOT FILE.SNAPSHOT>” “<SCAN ITEMS>”
Type:  REG_SZ:

It should be noted for those who use the GUI that some applications installations will wipe the HKEY_CURRENT_USER\SOFTWARE\MICROSOFT\WINDOWS\CURRENTVERSION\RUN registry key of all it’s entries, and in doing so also remove the ThinApp Setup Capture Continue entry as well.

To work around this, simply locate the initial SNAPSHOT file – usually located in the account’s %TEMP% folder although sometimes found in the %PROGRAMFILES%\VMware\VMware ThinApp\ folder- and run the value from the run window or command line.

NOTE:  You will need to remember your initial scan settings.  Default is the C: drive, the HKEY_LOCAL_MACHINE and HKEY_USERS hives.

Example:
“C:\Program Files\VMware\VMware ThinApp\Setup Capture.exe” “C:\DOCUME~1\Admin\LOCALS~1\Temp\{7498EF29-9F66-4018-BAD3-B0B5E645CACB}.snapshot” “C:\ HKEY_LOCAL_MACHINE HKEY_USERS”

NOTE:  The above command line is a single line but may appear word wrapped in your browser.

ThinApp Packaged App Troubleshooting – Slow Apps

Often times we hear the app works but starts up slowly.  The first thing to help you here is this; does it start slowly the first time ONLY or does it start slowly each and every time.  Remembering the application is creating, building, and extracting contents to the sandbox a little more so the first time it executes, we can assume that if the application only runs slow the first time, it must be something which is being extracted, created, built, or otherwise dumped to the sandbox.

Regardless of this, here are some additional items to check:

• Services are starting up.  It could be the case the services are not needed – if so, disable the services either in the ThinApp Project registry (HKEY_LOCAL_MACHINE.TXT file) or set the AutoStartServices=0 BuildOption in the PACKAGE.INI.  If the services are needed and they are taking a long time to launch, test the services start/stop times on a native Windows clean VM and see if the same thing happens there.  If so, a call to the app manufacturer is in order.
  Example:  Office will load and set the Machine Debug Manager (MDM.EXE) service and CTFMON.EXE services to auto-start.  These are not necessarily needed to launch a ThinApp’ed version of Office and can usually be disabled.
• Fonts being extracted on the fly to the sandbox during initial startup.  Look for a %FONTS% folder in the sandbox and copy it into the ThinApp project.  Rebuild the ThinApp project and retest this.
• Awaiting numerous fonts to be loaded.  Sometimes an app will load every font it can find.  In this scenario, it might be wise to remove all but the necessary fonts from the %FONTS% folder in the ThinApp Project and install them natively to the Windows host.
• Auto-repair functions.  Most apps will auto-repair themselves when they detect something incorrectly configured – and sometimes ThinApp will cause this if isolation or other settings are not properly configured in the ThinApp package.  Look for things like the MSIEXEC.EXE process/service running (attempt to stop if possible) and other app-specific auto-repair functions or processes.  Seeing these run may indicate a misconfigured application and often times kick off an auto-repair of the application without even showing this process to the user executing the application (ThinApp’ed or not).
• Excessive package size.  If the ThinApp project is excessive in size (there is no specific size here – it’s specific to what the environment can handle), it can take longer to load depending upon how the application works and loads itself, and – of course – the environment it is running on.  Remove unnecessary items from the ThinApp project before building.  Typically items such as the following can be removed from a project (MAKE A BACKUP OF THE PROJECT FIRST!):
• • %SYSTEMROOT%\INSTALLER — The contents of this folder will likely contain some MSI files – these MSI files can usually be removed if they are not needed.
  • %APPDATA%, %LOCAL APPDATA%, and %PROFILE% — Since these folders are all part of the user’s “profile”, if the application is installed to the entire system (meaning, anyone can login to the specific system the app is installed on and launch the app), then the contents of these folders are not typically needed unless it is desired to package the customer user configuration information with the application.
  • %PROGRAMFILESDIR%\<app folder>\<app backup folder> — Sometimes an application will install a backup of itself into a subfolder of the %ProgramFilesDir%\App folder. This is typically for auto-repair functionality as well, much like the %SYSTEMROOT%\INSTALLER folder contents are for repairing the app.
    Example:  Adobe products (depending upon the product and the version of the product) will often store a complete backup of the installation source code in %PROGRAMFILESDIR%\ADOBE\<Product>\Setup Files.  Sometimes it’s hidden in %PROGRAMFILESDIR%\ADOBE\ADOBEPATCHFILES as well.  So…it boils down to “Know Thine App”!
  • %COOKIES%, %HISTORY%, and %INTERNET EXPLORER CACHE% — Unless actually capturing an IE application or an IE plugin/addon, these folders may not be needed for your specific application, and thus the entire folder can be removed.

Click here to read the full article