I'm migrating a VSTO OUTLOOK add-in from 32-bit to 64-bit. It works well on Office 2007 32-bit. The goal is to make it run on Office 365 64-bit.
I have recompiled the add-in for a 64-bit plateform and updated the installshield project.
When I install the add-in on a new Windows 10 machine using my account (I have admin privilege), it works fine. I can see it in Outlook and I can use it.
However, if I log out and ask someone else to log in on the save machine (this someone else also has admin privilege), the add-in shows up in Outlook but this error is shown when the user uses it:
System.Runtime.InteropServices.COMException (0x80040154): Retrieving
the COM class factory for component with CLSID
{29AB7A12-B531-450E-8F7A-EA94C2F3C05F} failed due to the following
error: 80040154 Class not registered (Exception from HRESULT:
0x80040154 (REGDB_E_CLASSNOTREG)).
Any idea?
Details:
This add-in uses only one external DLL: a 64-bit DLL from Redemption.
The solution has been compiled in Visual Studio 2015. Platform target: x64.
To install it on a computer, I use a MSI that I've created using InstallShield Express on Visual Studio 2015.
In InstallShield, I have specified ALLUSERS-1 (Per-machine installation).
The DLL is registered using the following code:
Dim WshShell
Set WshShell = CreateObject("Wscript.Shell")
WshShell.run "regsvr32 /s ""C:\Program Files (x86)\MyCompany\AddInName\Redemption64.dll"
Set WshShell = nothing
Actual Steps: Just an attempted, pragmatic summary on top: 1: Whilst logged in as the second user, try to launch regedit.exe and export HKCR (maybe HKCU as well), then register the COM dll, export again and diff with a suitable diff tool (if the launching worked at all that is). 2: Download ProcMon.exe and monitor your application / add-in launch to determine what is going on.
3: Use Visual Studio and step-through and checking the Modules view to determine what is going on during launch. 4: Use oleview.exe to see what registration the COM file requires (open embedded typelib). File => View Typelib.... More details below.
Quick Check: Maybe check this first: Outlook Redemption - using RedemptionLoader without regsvr32 the DLL.
Also, did you shut down everything before the second user logged on? Or did you just switch users? Maybe try both, make sure your first login has nothing loaded or locked.
The below "registration debugging" might miss the target. It looks like this could be something more peculiar. Maybe just skim it.
Deployment Mnemonic: Maybe try this deployment mnemonic. A little paragraph with reminders how you can think to try to solve deployment problems: "What is locking, what is blocking, what is missing, etc..."
Registration: Though this looks like a simple missing registration, it could be something more peculiar. I have this application launch check list that you can skim. Not written for add-ins, but might give you some ideas.
regsvr32.exe: Did you try to run regsvr32.exe manually as the second user to check if that works? Though it is possible to register a COM file per-user, I don't know of a way to use regsvr32.exe to do so that is reliable.
ProcMon.exe: Are you familiar with using ProcMon.exe? Her is a rudimentary example. And Hanselman showing how it is done (YouTube). You can use that to try to determine what is failing and when. Needs some practice to use effectively, but it is my "first and last resort".
Visual Studio: I like to use Visual Studio to step through the code and look in different windows (modules for example) to understand how the application works and hence to determine what can be wrong during launching.
oleview.exe: To figure out what a COM-file registers during self-registration there are several ways. Launching oleview.exe with admin rights and then going File => View Typelib... and then locating the COM file you want to check and opening gives you the embedded IDL details.
RegSpy2.exe: Alternatively you can use RegSpy2.exe for COM registration extraction. See sample here.
Capture Compare: Finally a setup capture tool can be used for debugging. It scans the registry (and disk) for before and after changes. In other words you make a baseline, register the dlls and then scan for differences. The reliable tools are expensive (AdminStudio, Advanced Installer Architecht, etc...). The poor man's version of a setup or registration capture is to export HKCR before and after using regedit.exe, and then diffing with a file/text-diff tool.
Self-Registration: Self-registration is not recommended for COM registration as described here: MSI register dll - Self-Registration considered harmful. In Installshield you can simply register a COM file by extracting the COM data at build as illustrated in the image below. You can also enable COM-Interop registration in the same list by setting the flag ".NET COM Interop" to yes:
.
COM Interop: .NET assemblies can be registered for COM use using regasm.exe. That is (almost) the same as the .NET COM Interop setting mentioned above set to "yes". If you want to use a COM file from .NET you need to generate an Interop assembly file and then installing and registering the real COM file (which you do). Both operations must be performed.
Throwing in a couple of links. These (ancient) articles deal with the use of regasm.exe, tlbexp.exe, tlbimp.exe and gacutil.exe. Not needed for you, but leaving in for reference:
Calling COM Components from .NET Clients
Calling a .NET Component from a COM Component
Some Links:
Registering COM EXE with WIX
Registering a CPP dll into COM after installation using Wix Msi installer
Application is not getting opened after installing it with the installer created by "Visual studio installer"
I have an InstallShield Basic MSI project which builds both 32-bit and 64-bit installers using Release Flags mechanism to build the different packages with the correct Template Summary, etc. One of my Components is an explorer.exe shell extension, so in order for this to work it needs to be registered in the 64-bit node in the registry when installed on windows 64-bit, NOT in the Wow6432Node. However, because this is a 32-bit Component to Windows Installer it will get registered as such and go down the Wow6432Node. I am told by InstallShield that this is native Windows Installer behavior and there is really no way around this other than Custom Actions (which I have already resorted to).
Do I have to resort to running regasm? This is what I currently do however I would rather not use Custom Actions for something like this. Also, it appears that other products have the same pattern: a 64-bit shell extension, however installed down program files (x86). I see TFS Power Tools and WinZip doing this for example. For these products, I do NOT see regasm.exe running so I assume they have some other mechanism for this.
Any ideas?
Did you try to set msidbComponentAttributesDisableRegistryReflection (Component table) attribute for that component?
I created a WiX-based installer back in the WiX 3.5 days. The documentation then was even worse than it is now. To make matters worse, it was my first installer—so I didn't do everything right.
Some background: the installer installed two applications and a driver (each of these were a separate feature consisting of one or more components). One of the applications in question is a vendor-proprietary device configuration application written in VB6. Since it's a VB6 application, it uses the libraries comctl32.ocx and tabctl32.ocx.
The crux of the problem is that I didn't see these two libraries in the %windir%\System32 folder on Windows Vista (and/or Windows XP? I don't remember, it's been years since I first wrote this installer). So I thought I needed to install these two libraries along with all of their requisite COM registry entries. (I ended up installing the COM libraries in my application's folder—as you would for a private assembly, but registered them globally in HKLM.) As much as I read about things when creating the first installer, I never once came across the fact that, as of Windows XP, COM components could be installed side-by-side. (And even so, why didn't I use the MSI tables Clsid, ProgId, etc.—which granted, today, is frowned upon, but it would at least have been more correct than what I did? But I digress; what's done is done in MSI land.) Anyway, when creating the original installer, I used the following WiX markup for creating the COM registry values:
<RegistryValue ... Action="write" />
I also should mention that at the time, I had not come across any sort of 'Component Rules 101' kind of documentation as I have this time around. So, this MSI does not follow the component rules. The MSI contained one component for each COM library and its associated registry values with the COM library being the KeyPath of its component.
The question is, if the registry keys/values existed prior to my original MSI running and installing the first version of my product, will uninstallation cause these keys/values to be removed from the system? (I assume these keys/values were created during Windows setup—so are they already reference counted?) I don't want to possibly break other applications on a users' system that relies on those libraries.
If the answer to the above is yes, then my current plan to rectify the situation is:
Author a new MSI as a <MajorUpgrade />—afterall, I am performing an upgrade.
Provide the COM registry entries that were in the original installer for the comctl32.ocx and tabctl32.ocx COM libraries—I'm guessing that I would need to do this with a CA (or multiple CA's) so that they don't get removed again on the next upgrade. I see one of two ways of accomplishing this:
Directly create the registry entries taking care to ensure the values match those of a fresh windows installation (appropriate to the version of OS on which the installer is executing)
Dynamically add the registry entries to be created to the MSI Registry table (which if I understand correctly, isn't tracked by windows installer in terms of uninstallation?)
If previously existing registry keys overwritten by MSI are removed on uninstallation, then:
Is my proposed solution acceptable?
Which of the two options for replacing the removed registry entries is best?
If neither of those two options are acceptable, does anyone have any other suggestions on how I might rectify the situation so as not to break other applications that (may) rely on the libraries in question?
It was a long read but I think this is what you are looking for:
ICE09
To quote the beer commercials.... I don't always install files in the SystemFolder but when I do, I make them permanent.
First, thanks to Christopher Painter above for responding to my question; though, it's not really an answer in the sense that I'm looking for—fixing an existing installer that's "out in the wild". Though, in his last comment about a minor upgrade, that might work for some people.
Next, thanks to Aaron Stebner who responded to my e-mail requesting guidance on this same issue. His advice is to author a MSI component which has no ID. By authoring such a component into a MSI, the component is not tracked by MSI; essentially, it becomes a permanent, uninstallable component. This might work in this situation, if it were completely necessary.
However, after doing some research, I believe that there isn't much risk to damaging a user's system by removing the registry entries I outlined above.
I loaded a fresh copy of Windows XP SP3 and Windows Vista SP1 into a virtual machine. Out of the box, neither of these versions of Windows have the COM components in question registered in anyway in the Windows registry. This makes sense, since from Windows XP onward, there has been registry-free COM registration. This also continues to be the case for Windows 8.1—again, this was expected.
The worst that could happen if these registry keys are uninstalled is that some other older piece of software on a machine that relied on such registry entries could end up broken (e.g. this software is from the late-90's to early 2000's era and used a non-MSI installer and/or installed the COM libraries globally—which they shouldn't have done in the first place—just like I shouldn't have done in the first place ;) ). At that point, the user can either re-register the COM libraries using regsvr32.exe or repair/reinstall the application in question. The likelihood of such applications existing are slim to none in this day and age.
I developped a vb6 program then I build an installation wizard with visual studio interdev.
I used "dependency walker" and "process explorer" to find out the missing DLLs but there is always a problem with :
IESHIMS.DLL
WER.DLL
MPR.DLL
These dlls shown by dependency walker.
And when installing the program on another machine I have these error messages :
uxtheme.dll failed to register
msdatsrc.tlb failed to register etc..
PS : no problem on a machine where visual studio is installed.
Any Idea to fix this issue?
Thanks
Dependency Walker is not an appropriate tool to troubleshoot VB6 dependencies. It works well enough for DLLs written in C or C++ that use implicit dependencies. Although it hasn't kept up with the times and has trouble with DLLs that are stored in the Windows side-by-side cache or are delay loaded. Delay loading is what generates the warnings on ieshims.dll et al.
VB6 uses COM, which loads DLLs dynamically with LoadLibrary(). You'll never see such a dependency back in Depends unless you use the Profile option. Such DLLs are found back through the registry, the reason you needed to write an installer and tinker with regsvr32.exe.
You have to be pretty careful when writing installers like that, VB6 is old and can depend on operating system components that have been updated many times since 1998. Like uxtheme.dll, an important operating system DLL that implements visual styles. Having your installer overwrite the existing one on the user's machine is, well, disastrous. Although it is probably protected by Windows through its File System Protection feature, something that got added as a counter-measure against broken installers.
Giving proper advice is here difficult beyond "do no harm". A commercial installer like InstallShield or Wise (which I liked back then) is the best way to avoid shooting off the customer's leg. Fairly sure they still support VB6 installs. Microsoft makes a pre-cooked installer available for VB6 that installs all the core vb6 runtime components. You can download it here.
You should ALWAYS double check and verify any dependancies that you think your application needs.
All the files you mentioned are system DLLs and MUST NOT be distributed.
For a VB6 application you need the basic runtimes, and any DLLs you explicitly reference/use if and only if you have permission from the authors of those DLLs and instructions on the correct procedure and location for installing them.
For the standard Microsoft provided OCX files, these normally just need to be copied to the system32 folder and registered.
See redist.txt in the root of your Visual Studio installation for more details.
How can I log only the changes causing a MSI file made by Installshield 2008 to reinstall via "self-repair"?
What is the reason behind self-repair?
How do I disable self-repairing of MSI using Installshield 2008?
Self-Repair, Simple & Short Explanation: Why does the MSI installer reconfigure if I delete a file?
Alternative Answer Available
UPDATE:
There is a shorter, more "solution focused" answer available, perhaps try it first. This answer focuses on "understanding self-repair" rather than explaining the steps to take to eliminate the problem. You might want to read the first section of this answer as well.
Unexpected Windows Installer self-repair issues - Quick Fix?
This "article" has gotten large and somewhat unreadable. Here is a newly written preamble - the short "workaround version" for fixing unexpected self-repair (often found in VB6, Visual Studio, MS Office, MS Outlook, AutoCAD, etc...)
If you experience unexpected self-repair, the first thing you can try is to manually create a desktop shortcut directly to the application executable you are launching when the problem occurs. This bypasses the most common trigger of self-repair, "the advertised shortcut". If this works your problem is "solved" (or avoided). Here is a quick, fleshed-out explanation
If the problem still occurs, or your problem is related to the loading of an MS Office, MS Outlook add-in or similar (that you can't launch via a shortcut), then you most likely have a COM registration conflict on your system, and the fix is much more involved. The easiest to try is to disable any addins you don't need in the addins dialog of the application in question and see if this makes the problem go away
If you still see problems, then you most often need to debug a genuine COM registration conflict (or conflicting file/MIME associations, or command verbs). This normally involves (at least) two conflicting applications on your system that "fight it out" updating the registry on each launch after the other application has run (always launching one of the apps will not trigger the self-repair - the conflict surfaces when you alternate between applications). It is also possible that permission problems cause the same application to fail to update the system and it keeps trying endlessly by repeatedly running self-repair. And there are further possibilities, more details below
The "real fix" is to contact both application vendors and ask them for a fix for the problem (since a fix often requires a fix of both vendor MSIs), but in my experience this is rarely successful. Do try it out though - since this is the way to help everyone with a long-standing annoyance! I have personally provided a setup with fixes for a bank deployment and was very happy to have the problem solved in my package
To debug yourself, you need to get hold of a tool to open cached MSI files on the system and you need to "hack" the database - a very involved task requiring expert skills, you would be advised to seek an installation expert for help if the problem is very serious for your desktop environment. It can work, but don't expect miracles.
Please see the section below called "Finding the trigger or culprit for the self-repair" for more details on obtaining a tool to view and modify MSI files
The rest of the "article" describes self-repair problems in depth. There are many other potential causes of self-repair than what is described in this "short" section.
Overall Problem: Developer debugging and self-repair
Windows Installer is a deployment technology, its job is to install the specified files and registry settings and keep them in the specified install locations and to ensure they are the right versions - self-repair or resiliency is a mechanism to that end. Its operation conflicts with a developers need to exchange files on the fly for debugging, development and testing.
Accordingly, many self-repairs (resiliency) are triggered simply by developers trying to debug their installed application and hot-swapping files on the fly. See section 2 in "Some typical self-repair problem scenarios" below for how to handle this. In other cases there are genuine design errors in the MSI that must be corrected or system administration pitfalls that lead into self-repair - and at times the error source can be hard to find.
I have written about the issue of self-repair in an answer on serverfault.com. Slightly different words intended for system administrators, and reading it now it might be a more accessible explanation than this long one (intended for developers). There is also another, shorter answer here on stackoverflow: Why does the MSI installer reconfigure if I delete a file? (this is probably the shortest one and easiest to understand). And finally I found a very nice article on self-repair by Vadim Rapp: How to fix Windows Installer Efforts to Self-Repair. This article is well worth a read.
No self-repair will occur if Windows Installer determines that the product being launched is properly installed. When self-repair occurs something needs to be changed on the system for the application to run properly.
The Primary Causes of Self-Repair
The details are presented below in the section "Some typical self-repair problem scenarios", but as a quick, foreshadowing list - the primary causes are:
1. Badly packaged corporate MSI files or MSI design flaws from the vendor (the MSI package itself is badly designed and triggers self-repair unexpectedly for a variety of reasons)
Excessive or erroneous use of per-user files or per-user registry keys often with erroneous key paths set into the user profile (instead of HKCU). See section 5 below for more details (and a color illustration of such a situation)
Package interference from erroneous COM server registration (particularly VB6 COM files or VBA files and libraries from products such as AutoCAD from Autodesk, and similar products).
Two MSI packages register the same COM file (ActiveX/OCX) from two different locations and "self-repair fight" on each application launch to keep their version correctly registered.
The last application to launch puts the registry right for itself, and it lasts until the other application is launched and does the same. Once you alternate between applications the problem occurs. See section 7 below for a lot more VB / COM self-repair detail
A component key path is set to an empty folder that Windows installer removes on self-repair (triggering an endless loop of removal and subsequent self-repair)
ACL lockdown permission problems (logged on user can not access key file and Windows Installer triggers repair repeatedly). This can also be caused by ACL changes done externally, but is often done by the MSI itself
Here is a serverfault.com work-in-progress describing common MSI design flaws
2. Files or registry keys are deleted by interference from external causes ranging from (logon) scripts to standard OS features, viruses, security software, etc...
Temporary files are deleted automatically by Windows after being erroneously installed to the temp folder by an MSI package
Interference from bad logon- and trigger happy cleanup scripts and cleanup applications
Antivirus applications blocking or deleting files or registry keys so that Windows Installer can no longer detect or access them
Computer viruses changing or deleting files and registry settings
Overactive computer tinkerers and users delete files and settings they don't understand
3. Windows design changes, flaws or restrictions that causes flawed or problematic deployment
An AD-advertised MSI package fails to install (might be cancelled since it takes too long to install) and keeps bugging people. This is strictly speaking not self-repair but an advertised install that is aborted, but the result is the same: endless reinstall
Terminal server complications. Self-repair is generally disabled altogether on terminal servers. This does not normally cause self-repair problems, but application installs without the required per-user files or registry keys that can be added via benign use of self-repair (read below). The user files and user registry keys are then just missing and problems result
UAC interference, certificate validation failure and other problems resulting from Windows design changes. For every version of Windows security features like these are added and normally end up adding new obstacles for reliable deployment
Even certain Windows Updates (updates, security updates, hotfixes, etc...) can make drastic changes to how security is enforced for MSI packages, and hence cause extremely problematic behavior
Though this relates to MSI creation, and not primarily their end-user use, the Windows Update KB3004394 which updates the way Windows checks for revoked root certificates, breaks older version of Installshield's command line build (for setups that were digitally signed). Largely a resolved issue by now, but an illustration of how Microsoft keeps changing core MSI functionality
In a similar manner Installshield crashed for many users after installing Microsoft update MS14-037 “Security update for Internet Explorer versions 6, 7, 8, 9, 10, and 11” (KB2962872)
An extremely problematic change in Windows Installer base functionality occurred after installing kb2918614 (Vista). Suddenly administrator credentials were required for a simple MSI repair operation. This defeated a core benefit of MSI altogether: the ability of regular users to run approved installs with temporary admin rights. There were also other reported MSI problems after installing that fix. It appears another Windows update fixed the issues: kb3008627 (later replaced by kb3072630)
About Self-Repair
Windows Installer is designed to install your application's binaries, settings- and data files and keep them installed and ensure they are the right versions. Self-repair is a mechanism to that end. The overall concept is called resiliency - i.e. a broken installation triggers a self-repair before the application is launched.
Resiliency, or self-repair, is a built-in primary concept of Windows Installer and can not be turned off in any way that is safe. People do the most incredible things sometimes, such as disabling the whole Windows Installer engine to stop their self-repair. This must obviously never be done. The cause of the repair must be identified, and the problem resolved rather than creating new ones, or hacking the system.
Every time you launch an advertised shortcut (essentially a special shortcut that points to a Windows Installer feature and not directly to a file), Windows Installer will verify the installation by checking the "component key paths" for your product. If a discrepancy is found, a repair is triggered to correct the incomplete installation. The "component key paths" are the "key files" specified for the components inside your MSI - there is one per component. Self-repair can also be initiated by someone instantiating a COM server (or attempting to), someone activating a file via its file extension or MIME registration, and a few other ways. Here is a comprehensive article from Symantec on the subject of "self-repair entry points": Initiating Self-Repair and Advertising Features with Entry Point.
If files are deleted, moved or simply overwritten (manually by a user or somehow automatically), self-repair may result (if the file or registry setting isn't set as a key path self-repair is not triggered).
Finding the trigger or culprit for the self-repair
The trigger for the self-repair is generally possible to find in your event viewer on the system where the self-repair took place. Follow these steps to open the event viewer:
Right click "My Computer"
Click Manage
Click continue if you get an UAC prompt
Go to the Event Viewer section, and check the Windows Logs
Alternatively you can do: Start => Run... => eventvwr.exe for just the event viewer. If you don't see run in the start menu, press WINKEY + R.
Look in the "Application section" of the event log and you should find warnings from the event source "MsiInstaller" with IDs 1001 and 1004
In the sample screen shot above the product code is shown inside the red box
In order to determine what product the product code is for, you can look up the product name via the procedure explained here: How can I find the product GUID of an installed MSI setup?
If you actually want to go in deep and check the actual content of the MSI file, you must get hold of a tool capable of viewing a MSI file (such as Orca, Installshield, Advanced Installer or similar). You then open the package listed in the "LocalPackage" path listing as illustrated in the screen shot found in the answer linked to in the previous bullet point.
The actual modification of the system-cached MSI file and/or the registry to remove advertised entry points such as (advertised) shortcuts, COM registration, file associations, MIME associations or command verbs is a specialists job. It is very involved and not good practice, but it is the only "last resort" that I know about.
Finally it is possible for an application to explicitly call Windows Installer itself to trigger self-repair for shared components - for example a spell checker. I believe a few versions of Microsoft Access did this, and this behavior can not be changed or worked around as far as I know.
MSI-expert and MVP Stefan Krüger has an article about the same self-repair issue. And he crucially discusses the actual event log entries and what they mean. Please read about the actual debugging procedure there.
Some typical self-repair problem scenarios:
This is the "verbose explanation" of several self-repair problem scenarios already outlined in the overview above.
A component key path is set to an empty folder that Windows installer removes on self-repair (triggering an endless loop of removal and subsequent self-repair). This is solved by adding the folder to the CreateFolder table instead (Wix equivalent). In my experience this is the most common scenario for unwanted self-repair. Very common.
Many self-repair problems are actually caused by developers trying to debug their applications by replacing files on the fly, deleting files or renaming them. Or they may use cleanup registry scripts and / or batch scripts to unregister and register COM files, COM-Interop, GAC files, file associations, or other common developer debug and development tasks.
This hot-swapping can triggering self-repair when the application is launched via an advertised shortcut.
A top tip for developers struggling with self-repair during application debugging is to not launch the application from an advertised shortcut, but to launch the main EXE directly from Windows Explorer or from a manually created shortcut. This will bypass the most common "self-repair entry point" - the advertised shortcut. Self-repair may still result from broken COM data, advertised file associations and a few other special cases (read this Symantec article for entry point information).
Other applications or rather other MSI packages can break your installation and cause self-repair by interfering with registry data - typically COM settings, but also with other settings and files. These can be some of the hardest cases to solve, since the applications are basically fighting it out and the last one to run will update the registry each time. Typically both MSI files must be redesigned for the applications to operate on the same machine. Or, as is the order of the day, the whole application may be virtualized (for example: Microsoft App-V virtual packages) and run in its own sandbox which seems to be what is done more and more in companies these days. This error scenario is often seen with a suite of badly repackaged applications in a corporate environment. COM fragments from different packages overwrite the COM server's disk path from another package, and self-repair fighting ensues on each application launch via an advertised shortcut. The same file name with different file versions can also be registered from different file locations and share some registry settings that interfere. As far as I recall at least 7 variables or settings in the file system and registry must be in sync for a COM server to be properly instantiable. See section 7 below for a more specialized description of COM interference in the context of VB6 and VBA COM applications.
A component key path is pointing to a temporary file that has been deleted by the application or it will be deleted by the system eventually via some sort of cleanup mechanism (can also be a cleanup tool such as ccleaner). This is common for files in the temp folder itself. This is solved by not installing the temp file, or putting the file somewhere else and making it permanent. I have seen this error most often in the world of corporate application repackaging where a faulty cleanup of the captured image leads to the install of a temporary file that should not have been included in the package at all. Often they may be temporary files waiting for a reboot to be installed to their intended, perhaps protected location, and the reboot was never performed - a common application packaging error. To a lesser degree I have seen it in auto-generated packages coming out of automated build systems.
Permission problems: if a key file for a component is installed to a location that is not accessible for the user who invokes the application. Windows Installer might not "see" the installed file / key path, or be unable to add the file to the folder. These issues can be more exotic to debug, and may not happen that often. There are several variations on this issue:
An example of this is when you install a file to a %USERPROFILE% path and then forget to set a HKCU registry keypath, and instead set the keypath to point to the %USERPROFILE% folder/file. This generally yields an inaccessible hard coded key path that is user-specific: C:\Documents and settings\user1\Desktop. This path will not be found for another user logging on, and self-repair runs in circles. Here is a color illustration.
Another example is key paths set to folders that are not writeable for the System account. This may seem exotic but can result from the MSI's faulty modification of system ACL entries, or from a strange system administrator security setup, or any other non-standard ACL / Security Descriptor.
Another class of self-repair problems emerges in relation to terminal servers and Citrix. The whole windows installer service could be locked down so any self-repair invoked to add per user data could fail and consequently self-repair may fail or more likely not run at all. This is reason enough to not rely on self-repair as a way to add user data like some MSI files do, and such constructs must be replaced with application deployment of user files copied from per-machine locations or the less effective ActiveSetup feature from Microsoft that runs once per user.
VB6 applications and VBA applications, which are heavily COM based with massive potential for COM interference (COM settings overwriting each other and becoming inconsistent), have been known to trigger several mysterious self-repair problems, most of which have not been properly explained. This can also happen on launch of Visual Basic 6 (VB6) or Visual Studio (and many other applications). The common denominator is that some error in the current installation state triggered the self-repair, and you can track down the culprit product and component by following the steps outlined in the section above called "Finding the trigger or culprit for the self-repair". Be sure to report your findings here (I never use VB6 or VBA anymore - your detailed findings could help others with a long-standing annoyance).
Though I have never debugged such VB6 issues in great detail, it would seem that the problems result from applications that install common controls, VB6 COM files, templates and VBA files and libraries that conflict with existing files and registry settings and registrations on the box, or some per-user registry key or userprofile file may need to be added once per user (allow the self-repair to complete once and see if the problem goes away). In particular I have heard of these mysterious self-repair problems when launching AutoCAD (from Autodesk), Visual Basic 6, and several other products (often with VBA automation available in the tool).
Some applications even erroneously install bits and pieces from the VB6 runtime on their own causing these settings to be "ripped out" on uninstall of those applications. This can certainly cause self-repair to be triggered to fix the now (partially?) broken VB6 runtime. There are several variants of this problem, and the "catch all" solution is probably a complete uninstall and reinstall of the VB6 runtime. Here is a description of a very common "specific" problem involving a few COM registry keys. It nicely illustrates what happens in this scenario.
If you experience unexpected self-repair when launching VB6, AutoCAD, Visual Studio or other products, you can first try a workaround to prevent these unexpected self-repairs from happening in the first place (this doesn't solve the problem, but may bypass its symptoms): why does windows installer start up everytime i start up visual basic 6
See my comment to the question in this topic for one of the most typical VB6 style self-repairs: Why does my application triggers the Installer of another application? (ActiveX control registered twice from two different locations on disk).
In my opinion the "general fix" - that should always work - for VB-COM self-repair issues, is to get the vendor to update their project in question to use the latest official and properly installed and shared ActiveX control / OCX available, and not to rely on their own version installed redundantly and registered in the wrong location.
A special case of Windows Installer repair or self-repair that is worth mentioning for completeness, was the issue with Microsoft Office several years ago where a self-repair would be triggered, and you would be asked to insert the Microsoft Office installation media (in those days CD-ROMs or DVDs - today maybe thumb drives). As far as I recall this was related to an erroneous call to the built in Windows Installer standard action "ResolveSource" which unexpectedly (and unnecessarily) triggered the prompt for the installation media. A very common support call back in the day and mentioned here for completeness. It is important to note that this problem can still occur whenever MS Office is installed from any removable media (rather than the better option of a network share). This happens when MS Office detects that it needs to install further, optional (and usually shared) components of the product that were not installed originally. For example unusual spell-checkers, various templates or specific and rarely used tools. It is possible to install these components to "install on first use" (advertised features is the proper Windows Installer term).
There are many other possible scenarios. To mention a few:
a bad logon script may delete things on the system and trigger self-repair
an AD advertised package may fail to install and keep bugging people
two applications may start fighting for the same file associations
computer tinkerers and hackers can manually delete data that trigger self-repair
anti-virus can quarantine files and registry settings that trigger repair
a virus can change or delete things and trigger self-repair
a disk and registry cleanup tool such as ccleaner can delete files and trigger self-repair
and no doubt numerous other scenarios...
Benign uses for self-repair
Finally there are benign uses for self-repair that happen once and do not constitute errors. This is the legal and proper use of self-repair though it may be just as annoying as the design errors, and with user intervention they can pop up again and again:
Self-repair is sometimes used to add per-user data to HKCU and the user profile. This design mostly works, but gets worse for every version of Windows as new obstacles are put in place for deployment. For one thing self-repair typically does not work at all on terminal servers rendering the setup incomplete. Though it is besides the point for this discussion, it is better to have the application copy files to per-user locations. Another issue is UAC. Other problems show up with each new Windows version and even with some Windows Updates as described above (virtual folder redirects, certificate prompts, previously non-existing target path restrictions etc...).
When self-repair is needed to set up user data, it may take so long that the user aborts it and keeps doing so. This causes the self-repair to reappear all the time until it is allowed to finish. A common support call.
It is also possible to install a product with "advertised features" that are designed to be installed "on demand" triggered during application use. Few applications use this, but when it is used a lengthy "self-repair style" installer may run - pulling down the required files and settings. If this process is cancelled the installation of the feature is rolled back and it can be triggered again. This install can be slow for several reasons:
If the installer used large, compressed CAB files that are first downloaded and then extracted locally on a slow disk where the anti virus starts scanning the whole cab and then each extracted file the operation can take a long time.
The operation can also be slow if the network connection is wireless and there are lots of small files to download (high latency), and again the anti virus could slow down things.
If installed from removable media, you could get prompts to insert the source media to allow files to be copied. A very common support call if removable media is used in an office environment (it shouldn't be - use an admin install on a network share)
Etc...