Partilhar via

Why does Windows Installer start installing some other product when I try to install or use a different MSI-based product?

  • Artigo

I received a question in response to my blog entry about reverse engineering setup - basically the .NET Framework setup is being triggered while trying to install an unrelated product (in this case Drive Image 7). The details of this particular interation may not be interesting to everyone, but I think the underlying issue of why Windows Installer would start installing some other product when you try to install or use an unrelated product would make an interesting topic for discussion. I'm going to try to explain the underlying issue and also touch on some specific points related to the .NET Framework setup and how to fix it in particular.

Background

This is a feature of Windows Installer called resiliency. Basically, what happens is that in various type of install or product usage scenarios, Windows Installer will query some or all of the products installed on the machine to determine if the features are correctly installed. If these queries return any kind of error code, Windows Installer will try to trigger a repair for the feature and product in question. This will appear as a small installation dialog with the name of the product in the title bar, and normally the text of the dialog will say something like "Configuring <product name>. Please wait...." and it will contain a progress bar and a cancel button.

In some resiliency repair scenarios, you will never be prompted for a source location. Windows Installer caches the original location that a product is installed from, and if it can be accessed during a repair it will seamlessly connect to that location and use the files from there. However, when this type of repair is triggered for the .NET Framework, another dialog will appear stating that Windows Installer could not find the original installation location and asks you to browse to the location of netfx.msi. This is because it is an IExpress setup package (explained further here), the original source location is no longer valid because IExpress creates a temporary folder in the %temp% folder on a machine, installs from there, and then deletes that folder. When any repair is triggered by Windows Installer, you will be prompted for the source location of the .NET Framework installation package (netfx.msi).

Locating Netfx.MSI

If you are prompted for the location of netfx.msi, you can extract it from dotnetfx.exe and then browse to that location. To do this, download dotnetfx.exe or locate it on your local hard drive or a CD. Then, from a cmd prompt run the following: dotnetfx.exe /t:c:\temp /c. You can substitute any folder you want for the "c:\temp" parameter. Once the extraction is complete, browse to the folder you provided for the /t argument and .NET Framework repair should complete with no further issues.

Identifying the Root Cause

Locating netfx.msi can help get you past the browse dialog that appears, but it does not really help answer the more important question - why is the repair being triggered in the first place? I have seen many cases where an incorrectly authored MSI setup package has inadvertantly triggered a repair for a product already installed on the machine. In order to diagnose the root cause of the repair request, I usually do the following:

  1. Go to the Start menu and run eventvwr.exe
  2. Locate the Application event log and click on it to list the events
  3. For each repair that was triggered, there will be an entry in this log with a source named MsiInstaller
  4. Using the GUID of the component or feature that is being repaired, it is usually possible to look at the MSI for the product in question using Orca and determine why Windows Installer thinks it needs to perform a repair

In most cases, you will need to have a pretty solid level of Windows Installer expertise to track down a root cause based on the application event log entries. It is also possible to export the application event log and send it to someone else (such as a Product Support specialist) for help diagnosing the problem. To do this, simply right-click on the application event log and choose Save Log File As... in the menu that appears. Then you can save the file as *.evt, and someone else can import it and view it using eventvwr.exe

Hope this helps explain things a little bit. Let me know if I got any of the above wrong or if you have any specific questions/comments....

Comments

  • Anonymous
    August 24, 2004
    I would say the number one manifestation of this is to install the Windows Journal Viewer with WindowsUpdate and install Acrobat Reader. At some point, I can just about guarantee that starting Acrobat Reader (oddly only as a plugin) triggers reinstallation of Windows Journal Viewer. The problem here is that Windows gets rid of the installation file for the Journal Viewer and it is virtually impossible to exit out of the installation dialogs.

  • Anonymous
    August 24, 2004
    IMHO this is one of the most frequently seen problem with Windows Installer, so thanks for this article.
    Some information to help diagnose such problems (basically similar to this blog entry) and a tool that helps to find the affected product can be found at http://www.msifaq.com/a/1037.htm

  • Anonymous
    August 24, 2004
    That is a very useful link, I'm going to also post it on my main blog site, thank you for sending it along!

  • Anonymous
    September 17, 2004
    Great Post.. I made the mistake of allowing the 1.1 Framework SP1 For Windows Server 2003 to complete before doing 1.0 Framework SP3..

    The 1.0 Framework SP3 FAILS when doing it from the Windows update site..

    I downloaded it separately, ran the install, encounter then error you described here, used your fix and solved it.

    Thanks

  • Anonymous
    September 20, 2004
    dotnetfx.exe /t:c:temp /c

    Bless your heart, dude.

  • Anonymous
    May 14, 2005
    RePost:
    http://www.yeyan.cn/SoftwareEngineering/WindowsInstaller.aspx

  • Anonymous
    January 18, 2006
    I went to the event viewer as per your suggestion. The MsiInstaller intries mentioned 2 GUIDS. I opened up regedit, found them, then deleted the entries. This fixed the problem of the windows installer firing up frequently on apps launching.

    cheers

  • Anonymous
    August 17, 2007
    Recently, I helped investigate this Visual Studio 2005 issue reported on the Microsoft Connect site that

  • Anonymous
    August 17, 2007
    Recently, I helped investigate this Visual Studio 2005 issue reported on the Microsoft Connect site that

  • Anonymous
    August 17, 2007
    PingBack from http://msdnrss.thecoderblogs.com/2007/08/17/how-to-workaround-issue-where-launching-outlook-triggers-a-repair-of-vs-2005/

  • Anonymous
    April 16, 2008
    The comment has been removed

  • Anonymous
    June 10, 2010
    Thanks. This advice solved my problem.I installed "dotnetfx" (it wouldn't self-extract without installing, and didn't feel like making life more complicated), then installed the.NET 1.1 sp1 (kb979906).  The original failure msg requested "MS .NET Framework 1.1 (Disk 1)).

  • Anonymous
    March 19, 2012
    Thanks so much for this suggestion!!!  It solved my problem (failure to install security patch KB2656353).  I really appreciate it.  Your instructions were super clear. I also liked all the additional info; e.g., background, identifying the root cause etc.