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 to create cumulative service packs easily to apply with Windows Installer 3.1 and newer.

  • After installing Security Update KB928365 for the Microsoft .NET Framework 2.0 to fix MS07-040 , some

  • Hello All,

    Here is my scenario:

    Base product has a version of  1.0

    -I have a small update(QFE) which has a sequence number of 1.0.6.0

    The small update contains a file named PatchCustomActions.dll with a version of 1.0.3.0

    Patch code: {2BA41362-74A7-427D-A219-93CBFF4C5844}

    The small update also contains a text file name Sample.txt which has the text : Hotfix 3

    -I have another minor upgrade msp package which has a sequence number of  1.0.4.0

    The minor upgrade  contains the same  file named PatchCustomActions.dll with a version of 1.0.0.0

    Patch code:{7E832DAB-2AD8-440F-A3B5-2558237E53D7}

    The minor upgrade also contains the same  text file name Sample.txt which has the text : Hotfix Rollup Pack 1

    Few other facts about the packages:

    -Both the small update and minor upgrade target the base product v1.0.

    -The minor upgrade also has the supersedence bit set(i.e it supersedes all preceding hotfixes which belong to the same family and has a lower sequence number).

    -The minor upgrade transforms the product version to 1.1

    -The small update has a higher sequence number than the minor upgrade package as i dont want the small update to be superseded.

    Scenario:

    I install small update followed by the minor upgrade package.

    The windows installer log states that the logical order of application of the patches is the small update followed by the minor upgrade.

    However, at the end of the installation, i observe that the  version of PatchCustomActions.dll  is still 1.0.0.0(i.e the version contained in  the minor upgrade, even though the small update contains v1.0.3.0 of the dll).

    Could someone explain to me as to why this is happening?

    The windows installer log file can be found here:

    windows-installer-xml-wix-toolset.687559.n2.nabble.com/Patch-sequencing-problem-Small-update-a-supseding-hotfix-td7598304.html

    Any help woudl be very much appreciated.

  • @Kiran, the MSI log already showed you (and as explained in this blog post): the minor upgrade was sequenced after the small update, which means it takes precedence. The stack in an MSI log for patch sequencing grows down with the most significant patch at the bottom.

    Patch sequence numbers don't matter except between small updates in the same bucket. You'll need a small update that targets your minor upgrade patch.

  • Thanks Heath.

    So as i understand,  a superseding hotfix  can downgrade files. Is that a correct understanding?

    In another scenario,

    Base Product

    -Version 1.0

    -Has a file named PatchCustomActions.dll with a version of 1.0.0.0

    -Has a text file with text: RTM

    QFE

    -Has a file named PatchCustomActions.dll with a version of 1.0.3.0

    -Has a text file with the text: Hotfix 3

    -Has a sequence number of 1.0.3.0

    -Patch code is: {2BA41362-74A7-427D-A219-93CBFF4C5844}

    Minor upgrade

    -Has a file named PatchCustomActions.dll with a version of 1.0.0.0(***Same as the base product***)

    -Has a text file with the text: Hotfix Rollup Pack 1

    -Has a sequence number of 1.0.4.0

    -Has the supsersedence bit set  ie it supersedes QFE

    -Patch code is:{7E832DAB-2AD8-440F-A3B5-2558237E53D7}

    Installation scenario:

    1)Base Product + QFE + Minor upgrade

    Result:

    -Log file of  Minor upgrade states that QFE is superseded.

    Final patch application order is : {7E832DAB-2AD8-440F-A3B5-2558237E53D7} (Minor upgrade)

    - PatchCustomActions.dll has a version of 1.0.3.0, even though the superseding minor upgrade contains 1.0.0.0  of the dll. The dll was not downgraded.

    -The text file however is updated with the  one contained in the minor upgrade.

    My question is:

    -Why isn't the file PatchCustomActions.dll downgraded?

    2)Base Product +  Minor upgrade + QFE

    -Log file of  Minor upgrade states that QFE is superseded.

    Final patch application order is : {7E832DAB-2AD8-440F-A3B5-2558237E53D7} (Minor upgrade)

    - PatchCustomActions.dll has a version of 1.0.0.0, which is what i was expecting.

    -The text file is updated with the  one contained in the minor upgrade, which is what i was expecting.

    In the second scenario, the superseding patch wins.

    My question is:

    Shouldn't the first scenario behave the same as the second scenario with Patch sequencing , since the logical order of patch application does not matter?

    Regards,

    Kiran Hegde

Page 3 of 3 (36 items) 123