A side effect of Windows Installer Entry-Points can cause the Windows Installer to repair an application that was not even target to be run from the launched process.
If the event log shows a warning about an application that has not been launched then this article could bring some light into the dark.
A ghost repair will be started by a process that in general uses a com object like an activex object.
The binary file of this object has been installed by a windows installer based setup (MSI).
In this article I did decide to show a ghost repair based on the following windows scripting host file:
The following diagram explains in short the ghost repair in a simple way:
1. A process will call a com object in this case it’s a windows scripting host file
2. cscript.exe is executing an activex object
3. The Dll-Loader will now handle the registry read request to inizialize the ocx or dll file
4. In the registry the HotInstaller.HotCom Programmatic Identifier will be read in order to get it’s CLASS ID
5. In the registry the InprocServer32 will be read from the related CLASS ID
6. The Dll-Loader process is detecting an InprocServer32 value in InprocServer32 Key that holds a DarwinDescriptor
7. The DarwinDescriptor holds Windows Installer Details: ProductID, Feature that Installed this file, ComponentCode
8. Enumerates all related Windows Installer Features (Feature in DarwinDescriptor and all it’s parent Features) and checks all compontents key-pahts of the enumerated features for it’s existance
9. If a key path is missing, the ghost repair will repair the product that was hold in the DarwinDescriptor.
10. If everything is fine, the Key-Path of the component found in the DarwinDescriptor will be loaded into the memory
11 and 12. cscript.exe is using the activex object that is now available in the memory
Some technical details
Point 6. where the DLL-Loader detects the darwin descriptor – this value will be genereated by using the Class table:
After running the setup, the class entry will show an additional key with the name InprocServer32 and it’s value will hold ProductCode, Feature and ComponentCode from the Windows Installer based setup.
Point 8 – checks component key paths for it existence – this is the point where the Setup Design of the installed product will cause the ghost repair. In most cases it’s the combination of Current User Registry Keys and a shared component based on COM technology. Installations where ressources in a flat feature structure are installed will cause a ghost repair because all key paths of the target feature and parent features will be checked for its existance. If one key path is missing, the windows installer will start a self repair process.
This is a simple flat feature setup desing that is able to cause a ghost repair.
How to fix the ghost repair issue:
There are muliple ways to fix this issue.
The most common way to fix this issue is to enhance the setup design with shared component awareness. Separate the shared components into a new root feature.
Another way would be to delete the darwin descriptor from each operating system that is target of the issue.
1. Deleting the InprocServer32 key with the darwin descriptor value will 2. fallback the DLL-Loader to the standard initialisation way without windows installer technology
This may only be a workaround, as a repair or reinstallation of the product will recreate the darwin descriptor.
