Packed GUID's

All the Windows Installer registry keys and settings are held under these locations:

[HKEY_CLASSES_ROOT\Installer]
[HKEY_CURRENT_USER\SOFTWARE\Microsoft\Installer]
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer] a Per-User / Per-Machine installation affects the content that is written under these keys.

Under these keys, you will find details of all the Windows Installer products and components that have been installed onto the workstation. These Product Codes and Component IDs are stored as packed GUIDS, the packing is done as it takes up less space and allows faster access. The curly braces and hyphens are discarded, saving 6 bytes per GUID, and then related back to original data in the following way:

Original Product Code:
{12345678-ABCD-WXYZ-1234-ABCDEFGHIJKL}

String manipulation steps:

Recombine characters without any curly braces or hyphens to see your packed GUID:
87654321DCBAZYXW2134BADCFEHGJILK

In summary:

To use Microsoft's term on the different "globally unique identifier (GUID)" the following would apply:
Uncompressed GUID (standard): {12345678-ABCD-WXYZ-1234-ABCDEFGHIJKL}
Compressed GUID: 87654321DCBAZYXW2134BADCFEHGJILK

Reference Counting

Often when I refer to reference counting I have noticed that a number of people confuse Windows Installer reference counting with Windows reference counting (more commonly referred to as Shared DLL reference counting by application packagers). So here make the distinction we are talking about "Windows Installer reference counts".  

Another common item I hear is that reference counting is a count of the number of times a component is installed, however I think it is more appropriate to refer to it as the number of products which have installed a particular component.

The information is written to the registry by the ProcessComponents action. Under the components subkey (HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Components) you will find a list of Per-Machine Windows Installer components. The components will be identified by another subkey which is the Compressed Guid of the respective component. (HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Components\<CompressedComponentGuid>. Per-User entries are written to HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\<UserSID>\Components\<CompressedComponentGuid>).

Under each of these <CompressedComponentGuid> subkey's will be an undetermined list of REG_SZ registry strings. These REG_SZ strings are actually packed GUID's of the ProductCode of the application which installed the component. Such as:

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Components\<CompressedComponentGuid>\<CompressedProductGuid> = <ComponentKeypath>

For those of you who are interested the <ComponentKeyPath> entry is enumerated by a function call to MsiGetComponentPath.

Based on this installing two applications which share the same Component you will find something similar to the following in the registry.

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Components\<CompressedComponentGuidA>\<CompressedProductGuidA> = <ComponentKeypathA>

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Components\<CompressedComponentGuidA>\<CompressedProductGuidB> = <ComponentKeypathA>

If you find a REG_SZ string which is all 0's. Then the respective component is set not to be uninstalled during uninstall. This means that the component attribute contains a binary bitmask value of 16 or msidbComponentAttributesPermanent.

Some of you may at this point be asking so what does all this mean ? Well to make a very long story short it allows multiple applications to play nicely together particularly during uninstall. At some point I am sure many of you have tried to uninstall an older style application and been prompted with the infamous "This application is using shared DLL's do you want to uninstall these files" or you have uninstalled an application only to realise your machine is now completely non functional. Well reference counting is an attempt to make this a thing of the past. Enter Conflict Management (I will cover this in another blog)

Darwin Descriptors

I'm sure most of you have heard the tales not to repackage an MSI, well these little babies are one of the main reasons why NOT to repackage an MSI. "Darwin Descriptor" is actually an encrypted representation of a specific product, component, and feature. If these values exist, Windows Installer will decrypt the data, and use it to perform checks against the respective product and component. Refer to the previous blog on self healing for more detail about this action.

The problem encountered when capturing an MSI is this. When you install PRODUCT-A on your capture machine you write 'x' number of Darwin descriptors to the registry. Your snapshot tool will capture these darwin descriptors as registry information and incorporate them into PRODUCT-B. Remember these captured "darwin's" will have the PRODUCTCODE of PRODUCT-A encrypted into them.

As such if we install the captured PRODUCT-B onto a fresh machine you will still have "darwin's" pointing at PRODUCT-A which is no longer installed. It doesn't take a brain surgeon to work out the issue here.

If you want to get into the registry to see where all of this is stored go check out this location.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Products\<CompressedProductCode>\Features

Well that about wraps it up for another blog, as I am a little new to this if you guys see any room for improvement feel free to speak up. I may take the whole "darwin descriptor" feature even deeper in a future blog. 

One of the main features of Microsoft's Windows Installer technology is self healing. Self healing leverages the windows installer database to allow a full or partial reinstallation of a managed product under certain conditions.

For example lets assume you install a custom MSI of Winzip, and then proceeded to delete the files that made up Winzip. You could then run an advertised Windows Installer shortcut which acts as a proxy back to the Installer database and while you watch Winzip would be reinstalled. This feature is known as self healing, not to be confused with Self repair.

So in order to understand self healing you need to get a grasp on a few basics of Windows Installer.

The activation of the self healing process is triggered by the user accessing an advertised entry point when attempting to start an application. It is very important to understand that an application can consist of multiple entry points, as such it is vital to know the location of the entry point within the MSI feature structure. For example if there is 3 features in your application called FEATURE1 FEATURE2 and FEATURE3 if your entry point is located in FEATURE1 then self healing will start in FEATURE1. If your entry point is located in FEATURE3 then healing will start respectively in FEATURE3.

It is common with self healing to use the shortcut as an entry point, this is not a hard and fast rule, it simply stands to reason that the user is likely to run a shortcut to activate an application. Therefore a shortcut is a likely place to initiate the healing process. Shortcuts can be both advertised and non advertised. The target column of the shortcut table dictates whether a shortcut is advertised or not. If you wish to utilise self healing then the use of advertised shortcuts is advised.

Once an entry point has been accessed the installer services queries the entry point to find which feature it belongs to. Once obtained it then queries that feature for all of the components it contains. There are a number of important component attributes which are gathered during this process. These items are: Component Name, Component Install State, Component code and Component Keypath. Most of this information can be viewed via the Component Table of any Windows Installer MSI.

The Keypath being one of the more important attributes will reference one of the items contained within component (note a component can contain multiple items only one of which can be a keypath); The keypath will represent a file or registry key which should be present on the machine if the Component State is set to be installed. If Component state is set to be installed a check will be made on the target machine to determine if that file or registry key is present on the target. Where a keypath is not present the installer service initiates self repair in one of the two modes explained in the next paragraph.

There are two types of healing modes "Feature Level healing" and "Component Level healing". Feature level healing is performed when the broken keypath is located in the same feature as the entry point. A feature level heal will heal all items contained within a feature, this means that when a single component is broken in a feature which contains multiple components all components are healed regardless of whether they are broken or not whilst taking into consideration each components install state. A component level heal will only heal an individual component other components within that feature will not be affected.

Now something which always catches people out when this is explained is what happens after checking the first feature. This is probably the most misunderstood part of self healing. So bear with me, please make a distinction between checking and healing in the next paragraph. (added for you Bruce.)

If the feature containing the accessed entry point does not have any broken components identified by missing keypath references, then a check will be made for any parent features of that initial feature. If a parent feature is found the healing mode is switched from Feature level healing to Component level healing and process begins again on the new feature. If there are no parents then self healing stops the checking functionality at that point. (Note: Child or sibling features are NOT checked.)

Now if the entry point feature did have broken components identified by missing keypath references that feature would be healed at Feature level and the remaining MSI feature set would then be enumerated and subsequently checked. Where a feature did have a parent feature and that parent contained broken components all remaining features would be checked regardless of location within the MSI feature structure. (Note: this means all features are checked regardless of location when any broken component is found)

Another common misconception is when attempting to disable self healing within a component, as self healing is triggered when Keypath are missing assumptions are made to delete the keypath to stop self healing. In actual fact if you wish to stop self healing on a single component the correct method is to remove the components component GUID from the component table. (this will be explained in more detail in the section on packed GUID's)

It is also useful to note that when running add/remove programs and selecting the repair option a full heal is performed on the application in a similar manner to that of the initial installation.

Taking this a step further a feature commonly referred to as "user profile fixup" leverages the self healing functionality to repair items deployed into a users profile. An example being when you install applications logged in as USERA then log off and log back in as USERB items that were deployed to the user profile of USERA may not be accessible for USERB. By marking items within the users profile as a keypath each user will get the profile specific data deployed when launching the advertised shortcut (entry point) of the application through standard self healing techniques. I have written a post on how to exploit this functionality a few years back on http://www.myitforum.com labelled as:

Current User healing and Current User healing II.

Both documents are very old and need to be rewritten as they contain a few minor errors (I will endeavour to do this ASAP), however the technique is still very valid and widely practiced around the world.

Windows Installer Caching

Each time a Windows Installer MSI is installed a partial copy of the Windows Installer MSI is copied to the target machine usually in this location %windir%\installer. Binary files are included within the cache, however embedded cabinets are removed (from the _Streams table) before the package is cached. Generally they are smaller than the original source MSI.

When a broken application is found and self healing occurs a determination is made where the corresponding item will be repaired from. If it is just registry or ini file data then this can be done by the locally cached MSI. If the item is a file it will not be contained within the cache and as such an attempt will be made to access the original install media. I'm sure many of you have seen office prompting for a CD on a few occasions.

(Note: For this reason it is not considered smart to install an MSI from a CD, as attempts will be made to access that media for the remainder of the time the application is installed on the target)

As described above a way to counter this is to populate the SOURCELIST property prior to installation. A semi colon delimited list of servers can be added to the sourcelist to allow alternate heal points. Such as:

\\MySourceServer\Apps;\\%AppServer%Apps;x:\apps;\\DFS\Apps

If however you have made the mistake of deploying from CD and need to change a SOURCELIST after deployment. Darwin Sanoy of www.desktopengineer.com has written a script to change the sourcelist of pre Windows Installer 3.0 systems. When 3.0 is installed this can be used.

Dim objInstaller

Set objInstaller = CreateObject("WindowsInstaller.Installer")

objInstaller.AddSource "{00000ABC-ABE1-11D2-B60F-006097C998E7}", "", "\\MySourceServer\apps"

The next few topics of Darwin Descriptors and Packed Guids will cover this in even more detail.