Posted 03 March 2006 - 16:58
I am working with Windows installer for quite a long time. But now I got a very basic question, trying to find out the answer but not able to get exactly.
How the self heal works exactly.
I know the stuffs like, each component will be having a keypath, and when we launch the shortcut, it actually looks for the keypath for all the components in the same feature where that shortcut is present. If it finds any keypath is missing then it installs the whole feautre.
But my question now is how exactly it happens.
When we launch a shortcut, where it will search to find out the installed components and it's keypath, and then how it find the feature associated with that components.
I tried looking for this in the net, but of no use. Haven't satisfied with the answers.
My guess, it should be some where in registry. If yes, then can any one give me the exact registry hive. If not, then can any one help me out how exactly it happens.
Thanks in advance.
Posted 03 March 2006 - 18:59
Active Desktop gets the call (in your example by Explorer, where you launch a shortcut), looks it up and passes control to the Windows Installer. Windows Installer determines which package is capable of installing that particular component, then calls either MsiInstallMissingComponent() or MsiConfigureFeature(), depending on the situation.
Posted 06 March 2006 - 17:05
Posted 06 March 2006 - 17:23
As you write, an advertised shortcut points to a feature name which then further resolves to an executable inside that feature. All component keypaths in that feature and all parent features of that features are then checked. If any broken keypaths are found then a repair will occur of that feature (the idea behind this probably being that for a feature to work all its parent features must be installed too).
Posted 06 March 2006 - 17:48
But still not clear. How the windows Installer know that some files are missing which is keypath files for a component.
Yah Stefan, you said properly an advertised shortcut is having the info about feature.
But I would like to know that registry hive in which these components and key path are stored. I tried to get this by searching whole registry using component GUID, but of no use.
Even I belive that these info should be present in the registry, but where it is stored, not getting.
I dont want to change these registry entry. But to know how exactly selfheal works, I feel knowing this registry entry is must.
Guys..... any info on this will be great.
Posted 06 March 2006 - 18:29
The MSI database is stored here as far as I know:
Please note that you will not find GUIDs here, rather you will find the GUIDs converted into "packed GUIDs". To convert a GUID to a packed GUID you can use a VBScript:
Broken link removed, please search google for scripts to convert GUIDs from packed to normal format.
The windows installer components should be found as sub-keys under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18 (S-1-5-18 being the LocalSystem account).
Edited by Glytzhkof, 15 June 2018 - 12:41.
Link broken, now redirecting to some spam page.
Posted 06 March 2006 - 18:30
Posted 10 March 2006 - 17:53
Firstly you can find some very useful information about self heal of COM Servers in the Phil Wilson article from his book:
It is clearly a very complex bit of stuff!
And then follows the further questions:
Developers are using my msi installer to install the application being developed. They then make some changes to a component and build it with Visual Studio .NET. When the component is copied into the installed location Windows Installer automatically initiates a self repair of the component as it thinks it has been corrupted and puts it back to the state it was on installation. I cannot see any way to switch off this behaviour so..
How does one develop software in this environmnent? I cannot see any way to switch off this self repair. Any ideas?
Posted 11 March 2006 - 11:06
The overall idea of MSI is that it keeps a complete inventory of all files and registry settings installed. As such it is a deployment technology, not really a development solution. Hence the scenario where you manually upgrade files in the installation folder is not really accounted for. MSI is designed to install the files you want to install, keep them installed and keep them in the same version as the last install (all to ensure proper application operation). Hence the problem you are experiencing is really due to the fact that you are using MSI in a scenario it is not really designed for.
However, despite all the above, it is possible to prevent the specific problem you experience. Self repair only kicks in from "advertised entry points". There are only a few such entry points: advertised COM data, advertised shortcuts, advertised file associations etc... if you launch the EXE file directly from the installation folder no self repair will take place no matter if you replaced the file. To list the possible methods you can use in your case:
1: Se the shortcut that lauches the application to be non-advertised. If there are no other self repair entry points self repair will not kick in. I believe there is a property that can be added to the property table to disable self repair for advertised shortcuts. I believe it is: DISABLEADVTSHORTCUTS
2: You can set the component GUID for the component that installs the file to be blank. This will install the component, but then leave the component alone (not sure if this will uninstall the file on uninstall - probably not).
3: You can remove the key path for the component installing the file. This would make the parent directory the keypath and self repair should not replace the new file.
Posted 04 May 2006 - 12:01
The REG_MULTI_SZ value: InprocServer32 has the encrypted WI info to locate the COM server which looks something like "cCRUXXUFI99g!E,g90![Core>+?tG,trmf(6a?ef)qcK4"
If this value is deleted, WI is not involved in COM location and therefore cannot heal the COM server.
The path to the development COM server dll has to be in the above KEY default value for normal COM to work on the development version of the DLL.
I just manually create a .reg file to delete this value for each of my COM DLLs