Jump to content


This is a ready-only archive of the InstallSite Forum. You cannot post any new content here. / Dies ist ein Archiv des InstallSite Forums. Hier können keine neuen Beiträge veröffentlicht werden.
Photo

Self heal


10 replies to this topic

Vijay_k

Vijay_k
  • Full Members
  • 34 posts

Posted 03 March 2006 - 16:58

Hi all,

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.

-------- Vijay


Zweitze

Zweitze
  • Full Members
  • 522 posts

Posted 03 March 2006 - 18:59

Autorepair and Install-on-demand are usually initiated by Active Desktop, a technology for catching references to shortcuts and registry values.
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.

Stefan Krueger

Stefan Krueger

    InstallSite.org

  • Administrators
  • 13,269 posts

Posted 06 March 2006 - 17:05

The link to the product is stored in the shortcut itself. The information about components and keypaths in somewhere in registry (obscured and undocumented)

Glytzhkof

Glytzhkof
  • Moderators
  • 1,447 posts

Posted 06 March 2006 - 17:23

You should definitely not change anything in the registry to tweak how self repair works (if that's what you want to do).

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).
Regards
-Stein Åsmul

Vijay_k

Vijay_k
  • Full Members
  • 34 posts

Posted 06 March 2006 - 17:48

Thanks guys for the reply.

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.



Glytzhkof

Glytzhkof
  • Moderators
  • 1,447 posts

Posted 06 March 2006 - 18:29

The MSI database is stored here as far as I know:
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer

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.

Regards
-Stein Åsmul

Glytzhkof

Glytzhkof
  • Moderators
  • 1,447 posts

Posted 06 March 2006 - 18:30

There is more to windows installer btw, there is also a super hidden folder under: C:\WINDOWS\Installer. It contains the cached MSI files (without the actual files, just the database itself). These MSI files are then used for repair, modify and uninstall operations.
Regards
-Stein Åsmul

TonyLowrey

TonyLowrey
  • Members
  • 15 posts

Posted 10 March 2006 - 17:53

Answers and more questions.

Firstly you can find some very useful information about self heal of COM Servers in the Phil Wilson article from his book:
http://www.aspfree.c...nstaller-World/

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?



Glytzhkof

Glytzhkof
  • Moderators
  • 1,447 posts

Posted 11 March 2006 - 11:06

Hi Tony, there are several ways to do this, but first a little background:

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.
Regards
-Stein Åsmul

TonyLowrey

TonyLowrey
  • Members
  • 15 posts

Posted 04 May 2006 - 12:01

I fixed the COM server self-heal problem for software development of the MSI-installed application be deleting the WI registry setting used to 'advertise' the COM server.

For example:
CODE
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{99FF4677-FFC3-11D0-BD02-00C04FC2FB86}\InprocServer32\

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

antyagi

antyagi
  • Full Members
  • 121 posts

Posted 09 May 2007 - 06:02

QUOTE (Glytzhkof @ 2006-03-06 18:29)
To convert a GUID to a packed GUID you can use a VBScript: http://www.codecomme...-10-658988.html

VBScript at referred link is not correct. You may refer to small C++ code in this post
  ankur tyagi