Darwin Descriptors & the Windows Installer Repair Heirachy

Darwin Descriptors

A Darwin Descriptor tells Windows about the package and component key-path it is supposed to check.  We have seen in the preceding sections that the Darwin Descriptor below (found in Advertised Shortcuts and the Registry) is somehow associated with Microsoft Word.

']gAVn-}f(ZXfeAR6.jiWORDFiles>P`os,1@SW=P7v6GPl]Xh

A hint is that the Darwin Descriptor is actually comprised of three parts.

']gAVn-}f(ZXfeAR6.ji        WORDFiles>      P`os,1@SW=P7v6GPl]Xh

We have a ProductCode (left), Feature in black and Component (right).  We have to do a little bit of work to decipher what it is.  Firstly, the GUID strings are base encoded.  Instead of the normal 16 characters that can be used in a GUID (0-9 & A-F) we have access to a extended base of characters to represent the same thing… the result is that we can compress the normal 32 character length of the GUID into 20 characters.  

To translate the string back into a GUID we need to convert the base 85 encoding back to base 16.  To begin with, we will take what we know to be the ProductCode from the Darwin Descriptor above.

Before we dive into geekdom and interpret the Darwin Descriptor any further, we need to understand a little about the repair hierarchy that links components, features and products.

Repair Hierarchy

When a product is launched via an advertised entry point a check, Windows Installer will determine the Component, Feature and Package that the entry point belongs to.

Windows Installer will first check the integrity of all components in the same feature as the entry point.  If any corresponding file or registry based keypath for a component is missing or corrupted, Windows Installer will mark the component as corrupted and will force a repair.

When the check or repair occurs, Windows Installer walks “up the tree” or hierarchy of features, checking each one until it gets to the root.

Imagine a Feature tree as the one shown below:  A mythical application called MyNote is apart of a feature of text applications called MyTXT.  MyTXT is a feature within the “complete” feature of the package.

 

If an advertised shortcut for MyNote.exe forces a validity check or repair of the product key-paths for every component in the feature are checked then every feature preceding that component in the tree will be checked as well.

 

The reason for this selective checking of features (instead of just checking everything) is speed.  Large application suites may hold multiple features for numerous applications.  If you wanted to use a word processing component of that suite, you would want to ensure that all the components of the word processor were verified as being present before you started writing a document.  You wouldn’t really want to wait for all the components of your spreadsheet application to be checked (and possibly healed) if your only intention had been to write a letter.

The Feature Hierarchy makes it possible to constrain the boundaries of what healing will check and fix on the basis of entry points (normally shortcuts) used.  It’s also why most corporate organisations enforce a “single feature” application packaging policy so if any key-paths within an application are found to be missing or corrupted the entire application is verified and repaired.

We can see that for Windows Installer to verify or heal an installed product the system requires:

1. The product code for the package that is being verified
2. The component code (or GUID) for the entry point that is initialising an application (normally a component with n advertised shortcut).
3. Details of the feature the component is part of.

This leads the investigation back to Darwin Descriptors.  As was said earlier, the Darwin Descriptor does contain all three elements required for healing.

‘]gAVn-}f(ZXfeAR6.ji    WORDFiles>   P`os,1@SW=P7v6GPl]Xh

                                                    =

ProductCode GUID + Feature + Component GUID

Decoding Darwin Descriptors

We will work through the first of the GUIDs from the office Example from proceeding sections.

 

']gAVn-}f(ZXfeAR6.ji				The encoded GUID is comprised of four 5 character strings; each one will need to be recoded.
']gAV	n-}f(	ZXfeA	R6.ji

We really need to use a script for base translation.  The four strings from the Darwin Descriptor translate to:

Base85	Base16
']gAV	90401109
n-}f(	00063D11
ZXfeA	C8EF1005
R6.ji	4038389C

 

 

 

 

 

 

The resulting string is known as a Packed GUID

9040110900063D11C8EF10054038389C

Packed GUIDs

The Packed GUID is a useful value to know when troubleshooting registry issues with Windows Installer..  If we can determine a packed GUID, we can directly reference the Registry to identify what the product actually is.  The Packed GUID derived from the previous exercise is identified in the “CLASSES_ROOT\Installer\Products” registry as (surprise surprise) Microsoft Office 2003!

A Packed GUID is very similar to a regular GUID although it contains no braces or dashes.  As a result its length is a standard 32 characters instead of a normal 38 characters.

To translate Packed to regular GUIDs we have to break th string into a series of sets.  Packed GUIDs also have sets of digits in the string reversed in order. 

The “sets” that the string is broken into is always 8x4x4x2x2x2x2x2x2x2x2 this is represented in the string below:

90401109-0006-3D11-C8-EF-10-05-40-38-38-9C

	Packed	Unpacked
Reverse first 8 characters	90401109	90110409
Reverse next 4 characters	0006	6000
Reverse next 4 characters	3D11	11D3
Reverse next 2 characters	C8	8C
Reverse next 2 characters	EF	FE
Reverse next 2 characters	10	01
Reverse next 2 characters	05	50
Reverse next 2 characters	40	04
Reverse next 2 characters	38	83
Reverse next 2 characters	38	83
Reverse next 2 characters	9C	C9

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

All that is now required is the addition of braces and dashes to determine the regular GUID.  We have now derived the GUID from the Darwin Descriptor.

']gAVn-}f(ZXfeAR6.ji = {90110409-6000-11D3-8CFE-0150048383C9}