How Patching Works

Previously I blogged about what is in a patch, but how do patches work? To put it imply, patches transform a view of the product or products that the patch targets.

Patches (.msp files) contain a set of transforms: one transform changes the target product into the upgraded product, and one transform adds information specific to the patch. This latter transform is not applied when patching an administrative image since the patch is baked into the administrative image permanently. If the transform applies the view of the patch is modified and the product is reinstalled with the transformed view.

What exactly is the view? A view of the product begins with the release of the product, what is commonly called the RTM (Release to Manufacturing) or other variants like RTW (Release to Web), RTO (Release To Operations), etc. When a patch is applied to a product, the data in the RTM installation package plus the new data of the patch create a view. When another patch in a separate install transaction is applied, the view is now the RTM, the first patch, and now the current patch being installed.

In a simple scenario, a small update may update a file. The file size is mostly likely to change. For a versioned file the Version column value should also be changed in the File table. For a non-versioned file, the file hash in the MsiFileHash table should be updated; otherwise, a prompt for the target's source may be necessary. (For more information about default file versioning, see the Windows Installer SDK.) A transform would then contain instructions for updating the File and, if applicable, the MsiFileHash table. When that patch is applied, a view is created from the existing installed state and then modified with the applicable transform in the patch file. The product is then reinstalled according to the REINSTALLMODE property.

If you look in a Windows Installer log after installing a patch, you would see something similar to the following:

MSI (c) (8C:C4) [14:27:53:309]: SequencePatches starts. Product code: {7A1ADD0C-17F3-47B8-B033-A06E189C835D}, Product version: 2.0.50721, Upgrade code: {09288E14-AE35-4AEF-B88E-23D915B7F1DE}, Product language 0
MSI (c) (8C:C4) [14:27:53:319]: 3.0 patch PatchA.msp is of type QFE
MSI (c) (8C:C4) [14:27:53:319]: PATCH SEQUENCER: verifying the applicability of QFE patch PatchA.msp against product code: {7A1ADD0C-17F3-47B8-B033-A06E189C835D}, product version: 2.0.50721, product language 0 and upgrade code: {09288E14-AE35-4AEF-B88E-23D915B7F1DE}
MSI (c) (8C:C4) [14:27:53:319]: Validating transform 'T1ToU1' with validation bits 0xa23
MSI (c) (8C:C4) [14:27:53:319]: Transform 'T1ToU1' is valid.
MSI (c) (8C:C4) [14:27:53:319]: PATCH SEQUENCER: QFE patch PatchA.msp is applicable.
MSI (c) (8C:C4) [14:27:53:319]: SequencePatches returns success.
MSI (c) (8C:C4) [14:27:53:319]: Final Patch Application Order:
MSI (c) (8C:C4) [14:27:53:319]: {533B31C4-4E71-4947-8151-521655102EFD} — PatchA.msp

For a 3.0-style patch installed under Windows Installer 3.0 — that is, a patch where the .msp file itself defines a non-empty MsiPatchSequence table — the patch sequencer builds a view and determines what transforms are applicable and in what order they should be applied. This takes into account both installed and installing patches. To summarize Sequencing Patches:

1. Installed patches without the MsiPatchSequence table are applied to the view.
2. New patches without the MsiPatchSequence table are applied to the view.
3. Obsoleted patches are eliminated from the view.
4. All applicable patches are determined that target the RTM or preceding patches.
5. Minor updates are applied to the view in order based on their upgraded ProductVersion property.
6. Small updates that target any minor update from step 5 are applied to the view.
7. Any remaining small updates are applied to the view after the RTM and existing 2.0-style patches, and before the minor update from step 5. This is to cache packages for when superseding patches are uninstalled and those patches then become applicable.
8. All superseded patches are removed from the view.
9. Small updates are ordered for each target ProductVersion.

Under Windows Installer 2.0, obsoleted patches are removed from view according to the order installed and the single patch being installed.

After the view is created, the product is repaired. Superseded or obsoleted patch transforms are simply removed from the view. Files are updated based on their final changed file versions, registry keys installed, and so on. The second transform in a set of transforms within the .msp file contains information about how to locate those files by modifying the Media table.

Starting with Windows Installer 3.0, patches can now also be uninstalled. When a patch is uninstalled, the patch transforms are removed from the view. This means that when the product is repaired against the possibly patched view, information about the uninstalled patch is gone. This is what lead to several problems as mentioned in The Dangers of ARPSYSTEMCOMPONENT, as did the fact that superseded and obsoleted patches are also removed from the view.

The important thing to remember is that superseded, obsoleted, or uninstalled patches are simply removed from the view. Any data provided in those patches — if not also provided in obsolescing or superseding patches — is gone and cannot be used. Custom actions defined by the removed patch are not run because they are also gone from the view. In order to run custom actions during patch uninstall, you must define a patch uninstall custom action in the original product installation package or in a patch that is not removable and will always be installed.