- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- Re: Windows installer starts a "reconfiguration" every time a file is opened from explorer
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
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?
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.
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....
There is also a blog on Flexera's InstallTalk page. Reference: You Again: Understanding Windows Installer (MSI) Self-Repair
