Patch Applicability

Patch Applicability

  • Comments 12

When installing a patch package, Windows Installer first determines if the patch is applicable. Depending on how the patch is installed, this happens a little differently. Windows Installer can determine the list of applicable products, or it can be told to which products the patch should be applied.

Possible products

To have Windows Installer determine to which products the patch applies, you can execute msiexec.exe with /update or /p as shown in the following example.

msiexec.exe /update patch.msp

Windows Installer will enumerate the list of ProductCodes in the patch’s Template summary property. The same behavior is true when calling the MsiApplyPatch() function or the MsiApplyMultiplePatches() function when the second parameter is null.

You can also tell Windows Installer to which product the patch should applied using /package or /i as shown in the following example.

msiexec.exe /package {ProductCode} /update patch.msp

For the specified ProductCode or product package, Windows Installer will build the PATCH property and pass that in the command line similar to executing msiexec.exe as shown in the following example. When using the PATCH property, the full paths to each patch must be supplied.

msiexec.exe /package {ProductCode} PATCH=full\path\patch.msp

Windows Installer will evaluate each patch against the specified product. However, if installing the patch or patches using MsiApplyMultiplePatches() with a specific ProductCode, Windows Installer will modify the PATCH property to list only the patch packages with the specified ProdutCode in their Template summary property. If you’re not sure which patches apply to a product, this may be desirable behavior. If you pass in the PATCH property yourself and even one patch does not apply to the specified ProductCode, Windows Installer will terminate and return ERROR_PATCH_TARGET_NOT_FOUND (1642).

Verifying applicability

Once the list of patches has been passed into the installation session, Windows Installer will enumerate the transforms in each patch being applied. If a minor upgrade patch is being installed, Windows Installer will also enumerate the transforms in patches that have already been applied because minor upgrade may change which patches are applicable.

Within a patch package are sets of transforms: there is an authoring transform that describes the changes to the product, and a patch transform that describes how to install the patch and which files are updated. These transforms have the same name except the patch transform name begins with a hash (#).

Windows Installer will enumerate each authoring transform, using the following applicability information from their summary information stream.

The transform validation bits in the Character Count summary property determine which other summary properties are relevant. The typical validation bits of 0x0922 specify that the target ProductCode and UpgadeCode are equal to those specified in the Revision Number summary property of the transform, and that the full ProductVersion is equal to the value also in the Revision Number summary property. It’s also important to note that Windows Installer only validates up to the first three fields of the ProductVersion. The fourth field can be changed freely in a small update as a means of tracking and diagnosing updates.

If the ProductLanguage was validated, the ProductLanguage of the target product must match the value in the Template summary property.

When an authoring transform has been validated as applicable to the current product, the related patch transform is assumed to be applicable (validation bits are ignored). The remaining transforms in a patch are ignored, though Windows Installer will still log verbose validation information for each remaining transform.

If a valid transform is found within a patch, the patch is applicable to the product. That still doesn’t mean the patch will be applied, however, since the patch must still be sequenced and supersedence determined. But if a patch is applicable, it will at least be registered to the product. This means that it may be applied in the future if other patches are installed or removed from the product, and that it will be uninstalled with the product. However, since a single patch package is cached for all applicable products, the patch package itself is not deleted from the system until all products to which it’s registered are uninstalled or the patch is uninstalled from all applicable products.

Once all applicable patched are determined, a verbose log will display applicable, obsolesced, superseded, and invalid patches as shown in the following log example.

MSI (c) (88:38) [21:17:01:707]: Final Patch Application Order:
MSI (c) (88:38) [21:17:01:707]: {C26A5DDB-E2C5-4D2E-BC6E-449CBA57184E} -
MSI (c) (88:38) [21:17:01:707]: {A4AC638D-2C4F-4C9E-8962-9A674E782259} -
MSI (c) (88:38) [21:17:01:707]: {C697D8F7-E77A-4DA1-9CED-3F3E5115400D} - c:\Users\Test\AppData\Local\Temp\patch1.msp
MSI (c) (88:38) [21:17:01:707]: {73F7C9E3-08EC-4910-8D5B-3BF90C07EC1C} -
MSI (c) (88:38) [21:17:01:707]: Other Patches:
MSI (c) (88:38) [21:17:01:707]: Superseded: {B45F8725-6450-44D0-9284-01F321026767} -
MSI (c) (88:38) [21:17:01:707]: Superseded: {B0BB7DD1-D63A-4B73-8E73-6F055CB541AC} -
MSI (c) (88:38) [21:17:01:707]: Unknown\Absent: {402ADF4A-1B3D-4824-AE69-3606DDC2CE70} - c:\Users\Test\AppData\Local\Temp\patch2.msp

The names of the valid transforms are also registered to the product to save time by not re-evaluating applicable patches and transforms again during repair operations. The names of the valid transforms can be retrieved using the MsiGetProductInfo() or MsiGetProductInfoEx() functions with the INSTALLPROPERTY_TRANSFORMS property.

Transforming the database

Windows Installer will not actually modify the target database unless applying the patch to an administrative installation, which is created by using msiexec.exe /a. The vast majority of time, you will install a patch on a client machine.

Windows Installer will create views on the product database transformed by each applied transform. When Windows Installer queries the package for information, typically the transforms will add to, update, or remove data and tables. However, the transform error condition flags will fail the installation if not satisfied. With the typical transform error condition flags of 0x001f, Windows Installer will only err if the transforms attempt to change the database code page.

Order of events

Determining patch applicability and validating transforms always occurs before installation execution begins. Any code that needs to modify the list of patches must execute before installing or updating a product. This includes calling APIs like the MsiInstallProduct() function. Custom actions scheduled to execute during installation cannot modify the list of patches, and returning an error from any custom action added by a patch will terminate the entire installation session.

Leave a Comment
  • Please add 8 and 3 and type the answer here:
  • Post
  • Hi Heath

    How is the final Patch Application Order generated by the msi? Does it use MsiEnumPatches()?

  • @Syama, no it's based on bucketing and sequencing data. Please see blogs.msdn.com/.../how-patching-works.aspx.

  • Hi Heath,

    After applying successfully my first patch, I get the following error when applying my second patch :

    The installed product does not match the

    installation source. Until a matching source

    is provided.............

    Please help...

    Thanks

  • @HD, that is not much to go on. Are you sure you're referencing the same MSI you installed originally? Did your patch change the ProductVersion, ProductCode, or UpgradeCode of the original target product?

  • Hello,

    When I am applying a patch, should I always close to main program?

    I am testing it and I apply a patch (.msp)  while the main program running and the return of the installation is Success. Is it sure that the patch applied successfully?

    Thank you

  • @Vasileious, it depends on whether the patch updates any files that are in use. Closing the main application is a good way to avoid a required reboot (though this may not always help if, for example, a running service related to the program has a file replaced).

  • I have released couple of patches for our product.

    But in the latest patch is not getting applied on our last patch.

    I see following entry in log

    MSI (s) (08:F8) [05:31:27:516]: SequencePatches returns success.

    MSI (s) (08:F8) [05:31:27:516]: Final Patch Application Order:

    MSI (s) (08:F8) [05:31:27:516]: {7A2507F3-D954-487F-B545-1EBE46A33D34} -  1st Patch

    MSI (s) (08:F8) [05:31:27:516]: {7AFD866C-6A51-4BE9-BD5A-010F60851159} -  3rd Patch (Latest) c:\c1d40aa328e172a89f1a\DataProtectionManager2012SP1-KB999990.msp

    MSI (s) (08:F8) [05:31:27:516]: {E0359AAC-5CA3-4569-BC3D-26D64F624C3E} - 2nd Patch

    I can see in log that

    Product:  installed successfully.

    Installation success or error status: 0.

    But if i see files or ARP it is of version of 2nd patch.

  • @Vipin, make sure the patches have at least 1 patch family in common, or Windows Installer cannot sequence them properly and consistently.

  • @Vipin, we had the same scenario as you and the issue was due to the Sequence not being set in the PCP file. Every patch had the same Sequence number. See this link for more details: social.msdn.microsoft.com/.../patch-not-installing-on-a-particular-previous-patch

    If you are using WiX then set the Version in PatchFamily to the Patch Version number

    <PatchFamily Id="VLPatchFamily" Version="1.0.0.1" Supersede="no"/>

    For your 3 patches, say,

    Patch 1 = 1.0.0.1

    Patch 2 = 1.0.0.2

    Patch 3 = 1.0.0.3

    Then they will be sequenced in the order of Patch 1 then Patch 2 then Patch 3.

  • @vipin When the Final Patch Application Order is in the wrong order its the Sequence in the MSIPatchSequence table not being set correctly. The Sequence attribute should be set to the Patch Version number. It should increment for each successive patch. There are other more complex ways of using the MsiPatchSequence table, but in the simple case, just set it to the Patch Version number.

    See here for more details: social.msdn.microsoft.com/.../patch-not-installing-on-a-particular-previous-patch

  • We do not use PatchFamily for our PatchCreation XML

    We are using SequenceStart attribute from Family Element.

    Sequence start is different for all patches. and all are incremental.

    Still our patch is not working.  When i apply it in logs i can see following sequence.

    Final Patch Application Order:

    {E0359AAC-5CA3-4569-BC3D-26D64F624C3E} -

    {8842293D-852D-488F-9F78-54BEAB90E387} -

    {AB3D0AC2-C5CE-4012-A2D3-C4A03EA95064} -

    {7AFD866C-6A51-4BE9-BD5A-010F60851159} - c:\b3288c98f561052861001284\DataProtectionManager2012SP1-KB999990.msp

    {79F0A82B-1483-459D-B9F8-1D7D6329C927} -

    If i open my patches in ORCA. Did not find any issue.

  • @Vipin, the SequenceStart has nothing to do with patch ordering. In fact, if you don't use patch families for MSI 3.0-style patches, there is no guaranteed order. Patch sequencing prior to the MsiPatchSequence table added in MSI 3.0 was based solely on order installed.

    SequenceStart has to do with your file sequences that wind up in the patch.

Page 1 of 1 (12 items)