Perhaps the most requested type of information is how to perform troubleshooting on a ThinApp package. I therefore decided to share how most of the ThinApp specialists within VMware perform troubleshooting.
Have you tried capturing an app on XP only to have it not work on Win 7?
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:
Don't we have a ThinApp FAQ?
As a matter of fact, we do have a ThinApp FAQ! It can be found here. And, while you've probably read the ThinApp FAQs, we thought it might be nice to post something a bit more recent along with some answers…and some bonus questions.
So, not just FAQs – the Top 10 ThinApp questions plus a few extra bonuses!
What do we mean when asked to use a "clean PC" for capturing our applications? This question has many answers and ultimately depends on what you want to capture. But since that common answer is a little too vague, let's dive into this topic briefly to discuss what is technically involved here.
We all know that when we ThinApp our applications we are simply parsing the differences between two snapshots of our workstation. That in itself is simple enough, but the idea of the "clean PC" really should be phrased as the "The software I want in my ThinApp that is not currently installed, so therefore the differences in my snapshots will be reflected in my capture. " 🙂 The problem is that is way to difficult to place on the SetupCapure window and thus we use the term "Clean PC". But, that is essentially what we mean.
Consider the following. I want to capture my application that requires the .NET framework. Should I already have .NET installed locally or not? This is the simple question that comes up time and again. The answer is equally as simple. Do you want your application to include the .NET framework so you don't need it on the target workstation or would you rather manage that requirement outside of ThinApp. When looked at in this context, it's much easier to make the decision of what to have pre-installed versus what to install during a capture. But what does that have to do with the idea of a clean workstation???
The idea of a clean workstation is just one that does not have the software pre-installed that you want to capture. That's really it. So, the real trick is to understand what software requirements our applications need. Most of the time we find that in the System Requirements provided to us from the application vendor. Other times, we have just learned what an application needs as a matter of practice. When you hear of folks using a "clean PC" that only has the latest SP and no other components like .NET, Java, etc…, one may ask, "Why do they bother if all they need to ensure is that their software isn't already installed?"That too is an easy answer. It's because most of our apps are LOB and we often have very little information to begin with. If I use a workstation like I just described, then the prevailing idea is that if my application needs anything, it will either install it for me or scream about it during the install. This type of error dialog is common for developers who write their setup routines to look for these types of supporting components.
So, what type of workstation will you use to capture your applications on? Just ask yourself this one question, "do i know what my application needs to have in order to run and will the workstation I use this on have those already?" After that, you decide what type of workstation makes the best platform to capture your applications. If you're like me, I have several flavors in VM Workstation to allow me the option to pick and choose what makes sense for the application in hand. Ultimately, you will do what makes sense too, but I thought it would be a good idea to discuss the technical impact to what we call a "clean PC"
It is commonly asked what tips and tricks as well as tribal knowledge and types of tools are good to use when working with and troubleshooting cumbersome applications. This article is meant to be a general guide on types of application troubleshooting tools and tips and tricks with regard to troubleshooting applications and ThinApp projects.
Here are some of the more common System32 DLLs that we've had to manually add to ThinApp projects in order to get the ThinApp packaged application to work correctly on different operating systems.
By default, ThinApp creates Entry Points (e.g. Shortcuts) in your packaged applications for CMD.EXE, REGEDIT, and Internet Explorer. But wouldn’t it be nice to have some shortcuts in your ThinApp package for troubleshooting? For example, Windows Explorer, Services, Local Machine Group Policy Editor, and other similar tools would make troubleshooting and customizing your packaged application a heck of a lot easier.
Well, here’s how you do that!