How Patching Works

How Patching Works

  • Comments 33

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.

Leave a Comment
  • Please add 1 and 7 and type the answer here:
  • Post
  • Thanks Heath. Great post that confirmed my suspicions and set me on the right track.

    I hate to swear but my problem was "InstallShield 10.5."  In a nutshell the patchview just does not appear to be serialised correctly to the project file!!
    The patch view consists of a set of tree nodes that appear to dictate how MsiPatchSequence is authored, obviously completely undocumented.

    The order appears to be randomised based on the tree node name...honestly I think InstallShield give the Windows Installer technology a bad reputation...





     
  • One of the most-reported feedback issues with Visual Studio 2005 Service Pack 1 Beta is about how long

  • How to install multiple patches at once to save time.

  • Because some of the custom actions in Visual Studio 2005 are authored to impersonate the non-privileged

  • During some operations upgrades internally, a problem arose on some machines where a patch for the Microsoft

  • A common problem with installations is user-editable files and registry keys. Configuration of this nature

  • A common problem with installations is user-editable files and registry keys. Configuration of this nature

  • Visual Studio 2005 Service Pack 1 can take a long time to install and may apply to multiple products

  • When you install a patch using Windows Installer, the .msp file is cached in the %WINDIR%\Installer directory.

  • Generally, small updates target a specific ProductVersion , and with Windows Installer 3.0 and newer

  • Generally, small updates target a specific ProductVersion , and with Windows Installer 3.0 and newer

  • Rob Mensching, father of Windows Installer XML (WiX), blogs about why managed custom actions are a bad

  • Peter Marcu has begun talking about new functionality added into WiX 3.0 that he's been working on a

  • Removing a component even through obsolescence or supersedence will cause patched features to appear advertised instead of installed, which causes them to not be patched.

  • Rob Mensching, father of Windows Installer XML (WiX), blogs about why managed custom actions are a bad

Page 2 of 3 (33 items) 123