Freigeben über

How does Windows choose which version of a file to install?

  • Artikel

An engineer on my team, Jim Collins, worked on this blog entry and I know its something that we see a lot of questions on here internally.  Enjoy, and thanks Jim!

I'd like to talk about Multi branching support for Windows component based servicing.  To start let's define some terms that I will be using extensively during this blog.

General Distribution Release (GDR) - GDR updates can be found on Windows update and come in the form of Security Updates, Feature Packs, Update roll-ups, Drivers, and Critical updates.  These are released on Windows update so that they are available to a wide audience and go through extensive testing.

Limited Distribution Release (LDR) - LDR updates are created for specific issues that only a fraction of users may encounter.  Because of this they do not go through as extensive testing as GDR updates. 

Quick Fix Engineering (QFE) - QFE's are synonymous to LDR updates.  In previous version of Windows, we used the term QFE to describe these types of updates. In current versions of Windows, we use the term LDR. Expect to hear both terms used interchangeably. 

Branching

When you install Windows all the files on the system are on the GDR branch.  If patching is done via Windows update, Microsoft Update and/or WSUS, then you will always remain on the GDR branch.  Some KB articles have hotfixes that are not distributed via Windows update and are only packaged with LDR versions of the files to be updated.   When an LDR version of a fix is installed, it will move the files updated to the LDR branch and these files will remain on the LDR branch until the next Service Pack is installed.

Note: When talking about the GDR and LDR branches we are speaking on the file level, not the OS level. 

Note:   All patches distributed via Windows update are considered dual branch updates; they contain both the GDR and LDR versions of the files.

Note:   Service Packs contain only GDR branch versions of files.  So installing a Service Pack will put all your files back on the GDR branch.

I hope that that clears up what branching is.  Now let's talk about how to tell what branch you are on for a specific file.

File Versioning

If you pull up the listing of files for a Windows Update available for Windows 7 and Windows Server 2008 R2, you may see a listing that looks like the following:

Version

Product

Milestone

Service Branch

6.1.7600.16xxx

Windows7 and Windows Server 2008 R2

RTM

GDR

6.1.7600.20xxx

Windows7 and Windows Server 2008 R2

RTM

LDR

6.1.7601.17xxx

Windows7 and Windows Server 2008 R2

SP1

GDR

6.1.7601.21xxx

Windows7 and Windows Server 2008 R2

SP1

LDR

For Windows Vista and Windows Server 2008 installations, the KB file listing might look like this:

Version

Product

Milestone

Service Branch

6.0.6000.16xxx

Windows Vista

RTM

GDR

6.0.6000.20xxx

Windows Vista

RTM

LDR

6.0.6001.18xxx

Windows Vista SP1 and Windows Server 2008 SP1

SP1

GDR

6.0.6001.22xxx

Windows Vista SP1 and Windows Server 2008 SP1

SP1

LDR

6.0.6002.18xxx

Windows Vista SP2 and Windows Server 2008 SP2

SP2

GDR

6.0.6002.22xxx

Windows Vista SP2 and Windows Server 2008 SP2

SP2

LDR

In both cases, the first two numbers represent the product version.  Therefore, for the top chart 6.1 refers to Windows 7 or Windows Server 2008 R2 installations. The next four numbers represent the milestone for the version, once again, for the first chart, 7600 represents RTM and 7601 represents SP1.   The last group of numbers indicates whether the file is on the GDR or LDR branch.  The rule of thumb is if the last group starts with the number 1, you are on GDR branch and if the last group starts with the number 2, you are on the LDR branch.

When a Service Pack is released for Windows, it needs to contain all update packages due to multiple versions of files.  One would be for the most current Service Pack level (N) and one for the previous version (N-1).   With this in mind, all post Service Pack Windows Updates will contain four versions of the files, when the update applies to both RTM and Service Pack levels.

GDR N-1

LDR N-1

GDR N

LDR N

From here, three attributes determine how a file is updated when applying updates. These are:

· Existence Holder - This attribute gets set when the file is installed and only changes when a milestone update is applied.  In the diagram below, the existence holder for an RTM system would be RTMGDR1.0.

· Branch Holder - This attributes determines which branch of an update is applicable.   There will always be a winner for this attribute.  If a component contributes to this attribute, it will become the holder.  In the diagram below, the branch holder for an RTM system would be RTMGDR or RTMLDR.

· Revision Holder - This attribute determines which revision of an update is applicable.  This will always be the newest revision of the update on the branch that is the branch holder.  In the diagram below, the Revision holder would be the 1.x for RTM updates and 1.x or 2.x for post Service Pack 1 updates.

clip_image002

Note:   LDR 5 represents a fix created after SP1, which includes RTM and SP1 files for the fix.

.

Let's look at the progression of a file when updated with GDR and LDR updates. 

clip_image004

For this scenario, three updates are applied to a system (RTMGDR1.1, RTMLDR1.2 and RTMGDR1.4). The order in which the updates are installed is irrelevant.  The updates are:

· RTMGDR1.1 - This update was installed and became the Branch holder and Revision holder.

· RTMGDR1.4 - The branch holder remains RTMGDR and since the revision is higher, this becomes the revision holder.  Therefore, this is the update that will be present on the machine.

· RTMLDR1.2 - Since this is LDR, it becomes the Branch holder and since the revision of the previous update is higher it keeps that revision, so the update that will be present on the machine is RTMLDR1.4

In this scenario, the file will be RTMLDR1.4.

For the next scenario, let's add RTMLDR1.5 as diagramed below.

Recall, this update was created after Service Pack 1 was released, but it was installed before the Service Pack was installed on the system.  In this case, the file would be at RTMLDR1.5.  That is straight forward, but what if we install Service Pack 1 after this update is installed?

This is where the GDR N-1, LDR N-1, GDR N, LDR N mentioned earlier comes into play.  All windows updates released after a Service Pack will have both RTM files for the update as well as Service Pack 1 files for the update.  So the GDR N would be the Service Pack version of the update and the GDR N-1 would be the RTM version of the update.

clip_image006

This would be the only scenario, where a Service Pack install would not change a file back to the GDR branch.  Since this fix was released after the Service Pack was released, it will stay on the LDR branch, but update to the Service Pack 1 version of the file.  Therefore, in this case, the file will be SP1LDR2.5

I hope this clears up some of the grey areas around branching.

--Joseph

Comments

  • Anonymous
    January 01, 2003
    The comment has been removed

  • Anonymous
    January 01, 2003
    @chan; To be honest, I've never really noticed because we don't use date as a measure of whats installed.  The best way to determine what is installed is the version of the binary, not the date.  But to answer the other question, no, I haven't requested something like DISM be changed to act like that. BTW, PKGMGR was deprecated, so I wouldn't use it for anything.  I would use DISM. --Joseph

  • Anonymous
    January 01, 2003
    The comment has been removed

  • Anonymous
    January 01, 2003
    The comment has been removed

  • Anonymous
    January 01, 2003
    xpclient, if you really, really want to force LDR branch, please read social.technet.microsoft.com/.../how-to-forcibly-install-the-ldr-branch-from-a-particular-hotfix-package.aspx (don't do this at home. Er, I meant in production).

  • Anonymous
    January 01, 2003
    @chan I saw this too in Vista/7 and in Win8 it seems to be fixed.

  • Anonymous
    January 01, 2003
    So /b:spxqfe switch present in Hotfix Installer is gone now. :( What was the use and advantage of that switch on legacy Windows?

  • Anonymous
    January 01, 2003
    @xpclient:  On legacy operating systems we would sometimes need to force the branching of a file/fix to ensure that it was running the right code.  We dont need to do this in current operating environments because of the servicing stack, it knows which branch to be on based on the transaction.

  • Anonymous
    December 03, 2011
    Thanks Joseph for Sharing & Jim for writing!! Could you please increase the size of the images and re-post.

  • Anonymous
    December 16, 2011
    The comment has been removed

  • Anonymous
    December 20, 2011
    I notice when installing hotfixes via WUSA, the installed files have the dates when microsoft created them.  However when using DISM or PkgMgr the installed files have 'todays' date. Was this behavior on purpose? Have there been requests for DISM or PkgMgr to behave like WUSA with regards to the timestamp on the installed files?  It is quite handy to have the timestamps to be 'when they were created at Microsoft'.  Thanks.

  • Anonymous
    January 03, 2012
    @Pronichkin, thanks but I meant an easy way. That method is too complex, time consuming and involving too many steps, just like most servicing related operations are post-Vista. Anyways, it's clear that forcing a branch isn't needed any more.