Home > Blogs > VMware ThinApp Blog

Solving MSI self-repair issues in ThinApp

Ever seen one of these running a ThinApp package?


Yes, is probably your answer.. Getting MSI self-repair messages when running ThinApp applications is not unheard of. Luckily it is often easy to fix.

First some background.. If you have not fully mastered KeyPath, Features, Components and what-not within MSI packages please read this great blog post on the topic (not ThinApp specific but explains the whole concept very well): http://www.vmwareinfo.com/2011/09/surgically-eliminating-windows.html
You must understand the topics discussed in the above blog post in order to be able to troubleshoot MSI self-repair issues.

So why is it not uncommon to get MSI repairs running ThinApp? You probably captured your application on a very clean platform. When the application now runs on a PC with many more components locally installed is it not too hard to realize that the packaged application might be a little eager to please its user by integrating components and features now available to it. Since you packaged the application having a standalone, isolated execution in mind, the packaged application will often fail to see the whole native environment, triggering a MSI self-repair. The issue can also be caused by a component being missing on the target platform.

So let me walk you through an easy to understand example to get you started in solving these MSI issues..

In this example will I use Microsoft Project 2003, captured on Windows XP. The package works without any problems on all platforms except on Windows 7 64-bit where I’m getting an MSI repair dialog box every time I run the package.


Looking in the Event Viewer can I see what caused the MSI repair to trigger:


In this example it is pretty obvious since the missing KeyPath is in clear text. So I have two options.
1.    Copy the missing MSVBVM60.DLL into the project folder’s %SystemSystem%, rebuild and you are good to go.
2.    Find the KeyPath in the registry and delete it. Whether the KeyPath file is actually something needed for Project 2003 or not can I not really say but as far as I can tell Project 2003 runs just fine without it.

Since this blog post is about troubleshooting and how to find out why a MSI self-repair is triggered I will go with option 2.

The first thing we need is a method of investigating the registry and how it appears to the virtualized Project 2003. The easiest method is to simply activate regedit.exe as an Entry Point within your project. Edit your package.ini to activate regedit.exe and rebuild your project.


Now, on your Windows 7 64-bit machine launch the Entry Point of regedit.exe and search for the Component indicated as missing its KeyPath. The event indicated {BF4D7A70-D89D-11D1-A17D-00A0C90AB50F} as the troublesome component. Having read the blog post referenced previously we know that {BF4D7A70-D89D-11D1-A17D-00A0C90AB50F} translates to 07A7D4FBD98D1D111AD7000A9CA05BF0 in the registry and it will be located in HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Components..


So by simply deleting the KeyPath the MSI self-repair will disappear..


And Project 2003 now starts on Windows 7 64 bit without initiating a MSI self-repair.


The fix is now located in the users Sandbox. In order to apply the fix to your project you can use sbmerge.exe or manually update the registry files in your project. The easiest method I would say is using sbmerge and here's another blog post on how to use it: http://blogs.vmware.com/thinapp/2010/11/video-howto-using-sbmerge-to-update-a-thinapp-project.html


Many thanks to my colleague Rob Upham for sorting out my language in this blog post..


This entry was posted in Troubleshooting and tagged , , , , on by .
Peter Bjork

About Peter Bjork

Peter Bjork is a Senior Staff Architect, Technical Marketing at VMware. He specializes in Identity and Access Management. He's widely appreciated as a speaker at events like VMworld, VMUG and vFORUM. He is the author of two books as well as numerous white papers and blog posts. When the work day is over, Peter volunteers as a Scout leader for the local Sea Scout troop outside Stockholm, Sweden. Twitter: @thepeb.