How Patching Works

How Patching Works

  • Comments 36

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 3 and 6 and type the answer here:
  • Post
  • How to determine which files are being patched with a custom action.
  • How file sequences identify the file source for installation, and how patches resolve source for new files.
  • Package codes should always be unique - even for different processor architectures.
  • Type 35 custom actions have some serious ramifications to servicing and warrant enough concern to be careful when using them or even avoid using them completely. There is another way.
  • How to create cumulative service packs easily to apply with Windows Installer 3.1 and newer.
  • How to find the ProductCode or the product package in the local cache given a product name.
  • Firstly great blog, nitty-gritty on msi is hard to find.

    Once a patch is applied is there anywhere on the client I can "see" the changes to the .msi? Is there a cached .msi knocking about with tranform changes applied that I can look at with ORCA?

    After applying a small update in \windows\installer, I can see my original .msi, I can see my .msp, but I cant see an .msi with the .msp applied.

    I am changing a condition on a feature with a small update.  Patchview shows the condition chnage in the msp file but the change does not seem to be occurring.

    Any help greatly appreciated.
  • In Orca open the MSI, the click Transform->View Patch in the menu or just drag-and-drop the MSP right into the window. Orca picks the appropriate transform and you'll see the changes in green.

    Keep in mind that the MSI is never actual transforms and persisted (except for administrative installation, which are installation points administrators might use to deploy applications - it's not an installation in the tradition sense). See for details.
  • Brilliant.  

    I thought I don't have a transform menu in my ORCA....checked the aboutbox and version 1.1!

    Downloaded ORCA 3.0 from your link and how much better is that.  And I never knew that the .msp never actually modified the .msi.  

    Thanks again.

  • I am confused by "patch uninstall custom action."

    I want a custom action to execute when the patch will be uninstalled could you expand details on how to do this.

    The custom action is not in the orignal image, the log correctly indicates that the action is skipped during patch install but it is no where to be found in the patch uninstall log.

    Presumably this is the problem "There is no method for marking a custom action within a patch package to be run when the patch is uninstalled because the installer does not apply the patch packages being uninstalled.
    But how does the MsiPatchRemovalList of patch GUIDs help me run the custom action?

    Maybe I am missing something obvious, please enlighten me.
  • DaveI, when a patch is uninstalled, it is simply removed and the product is repaired based on other properties, most typically repairing only the features that were changed.

    Since the patch isn't available, any custom actions added by the patch wouldn't exist. Instead, you have to have hooks in the original MSI that use - for example - the patch codes in the MsiPatchRemovalList to find DLLs (perhaps the patch code is part of a directory path) and run custom actions from the DLLs.

    That said, avoid this situation. You can use the file installation tables and standard actions of Windows Installer to do this, but it requires you sequence your uninstall custom actions accordingly and that might be too restrictive. Rather, design your custom actions from the start to be data-driven so that when the patch is removed and the data gone or updated, the existing custom actions can modify the machine state accordingly as deferred custom actions.
  • Ahh. I see there is no patch uninstall "sequence" as such.

    Sadly, the product is long gone out of the door. I will have to piggy-back a custom action already in the original install.

    One final question I promise ;)

    Should it be possible to add a condition to a feature in a small update?

    ORCA is showing that the condition correctly gets added to the condition table, but the feature is still being installed. (If you dont know I appreciate that this is project specific query.)

  • If the feature was installed before, it will be reinstalled if patched or if it is included in the REINSTALL property (or if ALL is specified).
  • I have question on patch sequencing....

    I have an accumulative small update patch (targeting say 3 previous small updates) how can I determine and/or define the order in which the transforms are applied?

    For a small update is it possible to specify an order, maybe with the MsiPatchSequence\Sequence column? Are transforms applied in order of their sequence number low to high?  

    Thanks in advance.
  • Dave I, he MsiPatchSequence table is used to sequence patches (rather, patch transforms) in addition to superseding patches. Supersedence is not required. See for a larger example of patch sequencing in action.

    Also, due to a bug in Community Server, your comment starting "Furthermore" was deleted. Please repost if you remember your question and I'd be happy to answer it.
Page 1 of 3 (36 items) 123