Home > Blogs > VMware ThinApp Blog


ThinApp Troubleshooting – Repost

Since it was a bit hard to find, I figured I would repost this section of the much larger blog article (linked here and at the bottom of this article) where we discuss application troubleshooting. The larger article (Application Troubleshooting Tools and Tips for VMware ThinApp) has many other good tidbits but we often get asked these specific items – hence the repost.

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.

To reiterate, all of this and much, much more can be found on the previous ThinApp Blog Article Application Troubleshooting Tools and Tips for VMware ThinApp.

This entry was posted in Applications, Tips, Troubleshooting and tagged on by .
Dean Flaming

About Dean Flaming

Dean is currently an EUC Architect and member of the VMware End User Computing Enablement and Lighthouse Support teams, working to develop communications and IP around VMware End User Computing products and solutions as well as support many various Lighthouse accounts with their own EUC practices. Prior to this, from 2008 through 2012 Dean was one of VMware's End User Computing Specialists. Throughout his time at VMware, Dean has also written and published various articles, videos, and podcasts regarding VMware's EUC Solutions.