wixwindows-installervirtualizationcomaddin

What do I do when launching an application triggers repeating, endless Windows Installer self-repair?


Windows Installer self-repair can cause problems for both developers, system administrators and end users. Finding the solution can be difficult if you have limited MSI experience.

This is a Q&A-style answer intended as a check list for solving self-repair problems. Here are a few common problem scenarios:


Keywords: Windows Installer launches unexpectedly. MSI displays unexpectedly. Windows Installer appears every time. Opening Application Starts Windows Installer. Windows Installer self healing. How does a package self-heal. MSI self-heal best practice. Windows Installer repair. Self-Repair. Disable Windows Installer. Windows Installer repeatedly runs. Application Shortcut launches installer instead. Windows Installer appears unexpectedly.


Solution

  • Self-Repair, Simple & Short Explanation: Why does the MSI installer reconfigure if I delete a file?


    Concrete Design Advice for your WiX / MSI File

    I keep trying to write about repeating MSI self-repair for developers, but end up with too much detail. Here is my last attempt: concrete design advice for what not to do in your WiX / MSI file.

    The answer below provides a checklist for solving any self-repair scenarios - from any vendor or source, not just your own. Check the answer linked above for your own MSI package design concerns.

    The "Short Version" - Self-Repair Checklist

    To permanently and reliably fix self-repair problems for everyone, developers and setup developers must be involved since the real fix must happen at the vendor level.

    If you are in a corporate environment, poor-quality application re-packaging can also cause self-repair problems, and you should involve your application packagers to determine if the problem is from the vendor or not.

    System administrators must know what they are looking at, and when no fix is available, use various workarounds to deal with the problem in the wild. Even end users can try some easy workarounds themselves (see section 5).

    The essence of self-repair problems:

    Quick Options For Dealing With Problem Applications

    Perhaps jump straight to section 5 for the list of suggested fixes and workarounds if you are sure the self-repair you see is caused by MSI alone (and not by other, external causes as described in the first few sections below).

    Most of these proposed "solutions" in section 5 are really mostly system administrator tricks that don't fix the underlying problem - as stated above the real fix has to come from the vendor. The exception is "5.4: registration-less COM", which can actually help developers "shield" their applications from self-repair problems.

    If you don't have admin rights on your box you are advised to try "solutions" 5.2, 5.3 or 5.1 (5.1 will generally require admin rights to try, but it is non-complicated). These are "quick workarounds", the others are more involved. If these workarounds don't work, please ask your admin to read the other suggestions.

    Understanding Windows Installer Self-Repair

    I have written at length about this issue before, but it focused too much on understanding the problem rather than actually finding an acceptable fix for it. You can read the full explanation of self-repair problems here: How can I determine what causes repeated Windows Installer self-repair?.

    Fixing Windows Installer Self-Repair Issues

    To actually fix repeated and endless self-repair, you can try the suggestions below in section 5 - in increasing order of complexity and difficulty. Before doing so, you should verify what the real source of the self-repair problem really is. It might not be caused by MSI files, but by other, external causes (such as scripts or users deleting files or anti-virus blocking files).

    If the problem is indeed MSI-related, you can try to disable advertised shortcuts and COM addins, use registration-less COM, get help from the application vendor, uninstall offending applications, virtualize packages or full on hack the cached MSI database and registry (not recommended, and only really possible with expert help). It all depends on your scenario. If external causes such as scripts are at fault, you must eliminate this interference. See details below - just follow the check-list.

    The first steps for problem solving are to identify that the problem really exists in the wild on your platform, and then to determine what application(s) trigger the self-repair in the first place:

    1. Verify that the problem really exists in your environment.

    2. Identify the culprit(s) for the self-repair.

    3. Verify that external non-MSI causes are not causing the problem

    4. Contact the vendor(s) (or your own packaging department).

    5. Select a "workaround" or fix to deal with the conflict situation.

    6. Summary & conclusion