cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
andrewcflex
Level 4

Windows installer starts a "reconfiguration" every time a file is opened from explorer.

Jump to solution

I have built a Windows .MSI installer using IS 2018 for a desktop application.  It is quite a complex installer now with many components.

After running our installer , the program appears to be properly installed and no errors are reported. I can start it from the "Start" menu with no issues.

However, and this is something new, whenever a file (with our extension) is double/clicked/opened from Windows Explorer,  the installer starts again,  and the MSI log file reports at the end....

"MSI (s) (D8:B8) [17:09:48:401]: Windows Installer reconfigured the product...."

This happens repeatedly. That is , even after this "reconfiguration" runs once, it will continue to run every time a file is opened from Windows 10 Explorer.

I must admit to be struggling to understand "what" Windows thinks needs " reconfiguring".  Can someone direct me to perhaps something in the log that would help me debug this?

 

 

Labels (1)
0 Kudos
(1) Solution
Jenifer
Flexera Alumni

Hi @andrewcflex ,

 

It looks like Windows installer's feature-self-repair can cause product reconfiguration issue.Since it is specific to shortcut there might be some specific shortcut linked component missing/deleted.Below blog/detailed explanation gives more insights about cause and possibles fixes.

Comprehensive explanation of self-repair


Windows Installer features "self repair" for installed applications. In essence this means that it will keep checking whether the files on disk and settings in the registry match what the respective package originally installed. These checks are generally not performed for everything that the package installed, but for what is referred to as "key paths".

In situations where you see self repair running in cycles, it generally means that some process on the system or another MSI has changed settings on the system that the package that subsequently self-repairs also changed. Like the guy said, it's like a humidifier and a dehumidifier fighting it out in the same room - or a dog chasing its own tail. You don't get anywhere till the conflict is found and eliminated. The MSI file will keep going "this is my resource, I am changing it back" over and over.

What is needed is to identify the conflict that the MSI files or system processes are quarreling about: http://www.installsite.org/pages/en/msifaq/a/1037.htm .

There are also other design errors in MSI files that can trigger the same problem such as key paths set to hard coded, user-specific paths: C:\Documents and settings\user1\Desktop. This path will not be found for another user logging on, and self repair results. Another example is key paths set to folders that are not writeable for the System account. Still another example is a key path set to a temporary file (which the system will delete eventually).

As you see, there are many scenarios but always the same problem: an MSI file is checking that the current installation is correct, and finds a discrepancy that it then tries to fix.

View solution in original post

(3) Replies
Jenifer
Flexera Alumni

Hi @andrewcflex ,

 

It looks like Windows installer's feature-self-repair can cause product reconfiguration issue.Since it is specific to shortcut there might be some specific shortcut linked component missing/deleted.Below blog/detailed explanation gives more insights about cause and possibles fixes.

Comprehensive explanation of self-repair


Windows Installer features "self repair" for installed applications. In essence this means that it will keep checking whether the files on disk and settings in the registry match what the respective package originally installed. These checks are generally not performed for everything that the package installed, but for what is referred to as "key paths".

In situations where you see self repair running in cycles, it generally means that some process on the system or another MSI has changed settings on the system that the package that subsequently self-repairs also changed. Like the guy said, it's like a humidifier and a dehumidifier fighting it out in the same room - or a dog chasing its own tail. You don't get anywhere till the conflict is found and eliminated. The MSI file will keep going "this is my resource, I am changing it back" over and over.

What is needed is to identify the conflict that the MSI files or system processes are quarreling about: http://www.installsite.org/pages/en/msifaq/a/1037.htm .

There are also other design errors in MSI files that can trigger the same problem such as key paths set to hard coded, user-specific paths: C:\Documents and settings\user1\Desktop. This path will not be found for another user logging on, and self repair results. Another example is key paths set to folders that are not writeable for the System account. Still another example is a key path set to a temporary file (which the system will delete eventually).

As you see, there are many scenarios but always the same problem: an MSI file is checking that the current installation is correct, and finds a discrepancy that it then tries to fix.

Thanks for the tips!.

I eventually found the problem by rolling back installer changes. I had renamed a component without generating a new GUID for it. Clearly this upset something somewhere....

0 Kudos
GeorgeK
Flexera Alumni

There is also a blog on Flexera's InstallTalk page. Reference:  You Again: Understanding Windows Installer (MSI) Self-Repair

https://blogs.flexera.com/installtalk/2011/02/you-again-understanding-windows-installer-msi-self-repair/

0 Kudos