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.
Applications, Operating Systems and ThinApped applications all share the fact that we have to consider a lot of variables. I am not talking about a variable that gets converted into a specific path. No I mean we normally have a lot of unknowns to consider. This is what makes it sometimes very hard to troubleshoot an issue. Therefore is one of the first steps my colleagues and I do is to limit the variables or the unknown. We use a pretty simple test procedure for this.
A dirty test is one that is conducted on the CnB (Capture and Build machine) with the application still locally installed. Any issues arising from this test will most likely be code related and will present obvious issues right away.
Simply use Add/Remove Programs to uninstall the application from the CnB. Then run the ThinApp to test. If any issues occur here, the likelihood that they are related to missing components or settings is very high.
Revert your CnB back to a clean state and test your ThinApp. This test builds upon the ides of the washed test and will also provide insight to any potential issues that may result from files and setting that are not removed during an uninstall procedure.
Using your ThinApp, test in a live production workstation. Local policy, security applications and other items may cause issues. This test will allow you to determine if problems are environmental in nature.
During these different tests will you probably find things that makes you go hmmm.. (to quote an old hit song). Depending on what your findings are will you take different next steps. The best approach in my view is to build a hypothesis, i.e. ask yourself a question and create an answer to the question that you can try to verify through tests. Perform the test to see if your hypothesis will fix the problem, if not hopefully have you found something new that makes you go hmmm. Build a new hypothesis and give it a try. During your different findings and tests make sure you document each step and result. This will be very valuable if your debugging will be extensive and you start to forget what have already been proven in a previous hypothesis and test run.
Real life scenarios
What would a debugging blog post be without some real meat to feed your screaming stomachs with?
Case study 1, dirty test failure
This case study did I run into just the other week. Nothing special was noticed during capture of this application. The application depends on an older Java version. I packaged the Java and the application in one package. After my Capture process did I build and test launched my Entry Point. Immediately did I get an error message stating: “Problems during startup. Check the log files for more details..”. I took a look at the application logs but nothing really indicated what was wrong. Someone knowing more details of the application would probably know what it was all about from the application logs but since no one knew anything about the application did I have to carry on my debugging.
I activated CMD.EXE as an Entry Point and launched it. I navigated to the application folder and tried to launch the application from within the cmd. The application launched happily. This proved my issue was related to my Entry Point and at the same time did it prove that ThinApp was able to run the application. My hypothesis being that there is something wrong with the Entry Point and if I change its parameter will the application run. I went back to the package.ini file and investigated the Entry Point settings. Quite often is the problem missing WorkingDirectory= but in this case the parameter was there and it pointed to the same folder I had been in launching the application from within cmd. But what caught my eye was that the CommandLine= parameter was using %USERPROFILE% as a parameter. %USERPROFILE% is a System variable and not a ThinApp Folder Macro variable. ThinApp uses %PROFILE% instead. I changed all references of %USERPROFILE% to %PROFILE% and rebuild. The application launched just happily on all other test procedures, DIRTY, WASHED, CLEAN and PRODUCTION.
Case study 2, production test failure
Another case study, probably my favorite one. It is one I encounter many years ago. I had to make an old Windows 2000 only application run on Windows XP with latest Service Pack. The applications dependencies were Internet Explorer 5.5, Quicktime 4.1.2 and a CDROM with media files. The application used IE 5.5 engine and Quicktime to display instruction videos. The CDROM was virtualized with VirtualDrives=. The package was working flawless on Windows 2000 in all three test phases, DIRTY, WASHED and CLEAN. When I moved to my Windows XP machine (PRODUCTION) did most of the application work but the movies that the Quicktime plugin should display didn’t. So my finding being that differences between W2K and Windows XP is breaking the application. Unfortunately was I now facing pretty many variables. I needed something I could focus on, something that made me go hmmmm..
I used Log Monitor to create a trace file from a successful launch on a clean W2K and did the same on Windows XP. I thought I should compare both of them to see if I could get some more clues. For all of you who have used Log Monitor, you know that comparing the two trace files line by line would be pretty much impossible. I started out searching for what was not working, i.e. Quicktime. In the trace file from W2K did I probably find thousands of entries referring to Quicktime. In my Windows XP trace did I find only three. Pretty much in the beginning in the W2K trace did I see plugin.ocx and Quicktime in many rows. This caught my interest so I searched the Windows XP trace file for plugin.ocx but couldn’t find any entries at all. Google told me plugin.ocx was removed from Windows XP in Service Pack 2. So my hypothesis being that if I add plugin.ocx to my package Quicktime will work. I added my favorite tool CMD.EXE as an Entry Point and within cmd copied plugin.ocx into c:\Windows\System32 (this made sure the file got copied into the Sandbox) and still inside cmd did I register it with regsvr32. I shutdown cmd and launched the application and the movies worked perfectly. Finally did I use sbmerge.exe to merge my working Sandbox into my original project and rebuilt. My PRODUCTION test was now successful.