Windows Hotfixes and Updates – How do they work?

Today I would like to talk about some of the work the Windows Serviceability (WinSE) team does regarding servicing Windows and releasing updates.

The operating system is divided into multiple components. Each component can consist of one or more files, registry keys, configuration settings, etc.  WinSE releases updates based on components rather than the entire operating system. This reduces a lot of overhead with having to install updates to components that have not changed. Depending on the severity and applicability of the problem, there are different kinds of release mechanisms. Keep in mind, though, the actual fix still remains the same.

1.       Updates and Security Updates

These Updates are typically available on Windows Update. They frequently contain security fixes, and from time to time also contain reliability rollup packages. These updates are thoroughly tested and Microsoft highly recommends that you update your computer with these releases. In fact, most are automatically downloaded to your machine if you have Windows Update turned on. In most cases, Update releases are also available as standalone downloads from the download center.


2.       Hotfixes

When an individual customer reports a bug to Microsoft for a specific scenario, the WinSE team releases Hotfixes to address these problems. Hotfixes are not meant to be widely distributed and go through a limited amount of testing due to the customer's need for an urgent fix.  Hotfixes are developed in a separate environment than the regular Updates.  This allows Microsoft to release Updates that do not include the Hotfix files, thereby minimizing risk for the customer.

Once the Hotfix is ready and packaged by WinSE, a KB article is written describing the problem, with instructions on how to obtain the Hotfix.  Microsoft recommends that only customers experiencing the particular problem install the Hotfix for that problem.

Note: Hotfixes are also sometimes referred to as LDRs, or QFE's (Quick Fix Engineering). The term QFE is an old term that is mostly no longer used in reference to current versions of Windows.


3.       SP  - Service Pack

The service pack is a major update in the life of an OS. It contains a wide variety of fixes as well as all the GDR and LDR fixes that were released since the previous service pack was shipped. This is a thoroughly tested release and highly recommended by Microsoft for installation. This is usually available as a standalone release, and is then released through Windows Update as well.



GDR vs. LDR branches

Now that we have described the different kinds of updates, let's take a deeper look into how these fixes are built. When a new OS or service pack is released, 2 branches are created from the release code tree -a GDR (general distribution release) branch and a LDR (limited distribution release) branch. Hotfixes are built solely from the LDR branch, while Updates for broad release are built from the GDR branch.

Service Packs are built from a third branch that contains all Updates , Hotfixes and additional fixes.  This way the new service pack is shipped with all the fixes from both branches.

Note – Once the new service pack is shipped, the code branches from the previous release are still active and serviced as necessary.

Installing a Hotfix

By default, all components on Windows systems start on the GDR branch following each major release. When you install updates from Windows Update for a GDR component, it gets upgraded with the GDR version.

When you install a specific Hotfix, the files and components in the Hotfix package are migrated to the LDR branch. At this point, that particular component is marked as a LDR component. If you install a newer Update over this component, the Windows servicing technology will automatically install the appropriate latest version from the LDR branch for you. This is possible because each Update package ships with both the GDR and LDR versions of the component.

Once a component is marked as a LDR component, the only way to move back to the GDR branch is to uninstall all Hotfixes for that component, or move to the next available service pack.


What would happen if a user installed a Hotfix, and then sometime later installed the next service pack? Well, in that case it depends on the Hotfix and when it was built.

1.       If the Hotfix was built before the service pack, then the component will be moved to the GDR version contained in the service pack.

2.       If the Hotfix was built after the service pack, the component will be migrated to the post-service pack version of the component, and will stay on the same branch that it was originally on.


In order to make this work, these packages contain both the RTM GDR version, the RTM Hotfix branch, and the SP1 Hotfix and GDR version of each binary.


All fixes built for Windows are cumulative in nature by branch, i.e. a new update will contain the new fix, as well as all the previous fixes for that branch. Referencing the chart above, installing fix #4 can get you fixes #2 and #4 on the GDR branch. If the component is on the LDR branch, then the user would get fixes #1-4.


Finally, the servicing technology has to handle the case where you need the functionality of an older Hotfix (e.g. “Fix #1” in the diagram above) but you may already have installed “Fix #4” which might be a critical security update.  What happens is that when the GDR branch of a fix is installed, it also places a copy of the Hotfix version of the same fix on the system.  When you run the installer for Hotfix #1, it detects that a newer version of the file is already installed, but it also detects that it needs to migrate it to the Hotfix version of the binary that was previously stored on the system. The result is that you end up with the Hotfix binary for Fix #4, which has both the Hotfix you need plus the cumulative set of security fixes.


Stay tuned for more, in the next blog entry, I will talk about the staging mechanism that Windows uses to install Updates and Hotfixes as well as the uninstall process. Also, I will talk about how to determine the branch a file is built from.


- Omer 


More Information

Description of the standard terminology that is used to describe Microsoft software updates

Description of the contents of Windows XP Service Pack 2 and Windows Server 2003 software update packages


Comments (13)
  1. Anonymuos says:

    Does this mean the GDR branch is more stable than the LDR/QFE branch? Also, there is one /B:<cardinalpoint>QFE switch that forces update.exe to install the LDR branch. What’s the benefit of installing the LDR branch if “the fix” is contained in either branch?

    [The GDR branch only contains security and high impact hotfixes.
    The LDR branch contains standard break/fix fixes and fixes from the GDR branch.

    The GDR Branch has less likelihood of a regression due to the lower number of changes so by extension is considered more stable.

    The /B switch allows you to specify which branch to install. There are instances where you if have a GDR installed (which doesn’t contain a break fix) and we need to get the LDR fix installed to resolve a problem.

    Think about it this way, binary foo.dll with two fixes, a security update (MS01-01) and a crashing bug.

    FOO_GDR_BRANCH —————-MS01-01
    FOO_LDR_BRANCH –CrashFix——MS01-01

    When you download and install MS01-01 you by default get the GDR branch which does not contain the CrashFix. The /B branch allows you to specify the installer install the LDR branch fix so that you get the CrashFix and MS01-01

    – tony]

  2. Wow, great post!

    I’d be interested in knowing how the coding and testing of fixes for multiple branches is handled. Is code written for each branch (LDR, GDR, LDR for SP, GDR for SP) or written for the most recent and backported? If that is the case, how are dependencies handled?

    Also, is the eventual goal of Windows Servicing to follow the model that Exchange and SQL Server has adopted (SPs with Update Rollups/Cumulative Updates and only interim fixes when needed)?

    [ Testing is usually based on the nature of the component, the risk of the fix, complexity, etc. Based on this information, a group of PMs, developers and test engineers all get together to discuss the appropriate level of testing needed before release.

    There isn’t a hard and fast rule as to which branch the fix is always made in. Usually the test engineer and developer get together to decide where it should go initially. Depending on the fix that needs to be made, code is written for a particular branch, and then moved around. If there are dependencies, then they are addressed on a per branch basis.

    There is work being done to move to a more predictable model of shipping Update Rollups like the other Serviceability teams. However, we are being careful because sometimes customers cannot wait for Updates to be shipped in a cyclic model. Once we have the right process in place, it will definitely help the Serviceability team to be more predictable, increase test coverage and reduce regressions.

    Hope that answers your query!]

  3. George Luiz Bittencourt says:


    I have a question. Imagine the following situation:

    If an article says that a hotfix contains the file Ntkrnlmp.exe with the version 5.2.3790.4173 and the version that I have installed is 5.2.3790.5000. Can I assume that I already have this fix?



    [All fixes are cumulative per branch. A new build will always contain all the previous Updates that were made in that branch. Therefore, to answer your question, the version number is not enough to make that determination. You need to find out what branch of the component you are on, as well as the branch the fix was made on. Take a look at the diagram in the post, and you will see what I mean. Also, note that all fixes made in the GDR branch are in the LDR branch, but not the other way around.

    To find out the branch of a installed component, in XP/2003, you could get the branch information by right-clicking a file -> Properties -> Version tab ->File version. If you are installing an Update or Hotfix, you can get the branch information from the corresponding KB. You can also use filever.exe /v to get this information.]

  4. Anonymuos says:

    Thanks. Also, where have all the switches gone in Vista and why have they been taken away? Especially "/nobackup"?

  5. Mankow says:

    I was once offered a “Buddy” fix for an Exchange issue in 2003.  Does the Exchange product group have different terminology, or do you know how that relates to windows development?

    [The Exchange SE team has a slightly different terminology than the platforms group. In Exchange 2003 and prior, Buddy fixes referred to private fixes given to customers. These buddy fixes contained the fix for the current issue, as well as all prior fixes since the last rollup.

    In Exchange 2007, the SE team now gives out “Interim” fixes, which contains only the fix for the current issue. These too are private, and the final fix is then shipped in the next rollup.]

  6. schoedl says:

    Is there a way to determine from the 64-bit version number of a file whether it is an LDR or GDR file? If not, are these version numbers at least unique, so no LDR file has the same version number as an GDR file? How are the version numbers generated/interleaved between the two branches?

    [Version numbers are not the preferred way to determine the branch. The branch information is part of the File Version of the binary just not the number part.

    In XP & Server 2003 you can bring up Explorer properties of the binary and go to the Details tab. Notice the GDR in the (srv03_sp2_gdr.080813-1204) output below.

    I haven’t been able to find this version information in the Vista/2008 UI. So I always use the the resource kit tool FileVer.exe

    filever /v windowssystem32ntoskrnl.exe
    –a– W32x64 APP ENU 5.2.3790.4354 shp 4,587,520 08/14/2008 ntoskrnl.exe
        Language 0x0409 (English (United States))
        CharSet 0x04b0 Unicode
        OleSelfRegister Disabled
        CompanyName Microsoft Corporation
        FileDescription NT Kernel & System
        InternalName ntkrnlmp.exe
        OriginalFilename ntkrnlmp.exe
        ProductName Microsoft« Windows« Operating System
        ProductVersion 5.2.3790.4354
        FileVersion 5.2.3790.4354 (srv03_sp2_gdr.080813-1204) <<<— Note the GDR in the fileversion field.
        LegalCopyright ⌐ Microsoft Corporation. All rights reserved.

    – Tony]

  7. schoedl says:

    Are Office patches organized the same way?

  8. Daniel says:

    First off, thanks for this great article.

    So I have a machine that has a problem that we cannot reproduce anywhere else.  In looking into it deeper it looks like all of their IE7 dll’s are from the LDR branch (as well as several others).  The LDR branch all seem to have slightly higher version numbers than the GDR.  Since the LDR branch has code that does not exist, it is possible that the LDR branch contains a bug that is causing the problem we are seeing.  Also how would they have gotten onto the LDR branch of IE7?  Would the manual download an installation of the IE& (instead of using windows update) put them on that branch?

    We are also seeing file difference where one says (longhorn(wmbla)) and the other says (winmain(wmbla)).  How do these differ?  Also we see Winfxred vs SP as well as REDBITS vs netfxsp.


    Thanks for your question.

    It is possible that the Internet Explorer LDR branch has some change that is causing you to see different behavior than IE7 running with GDR files.  There are three ways that you could have gotten the LDR files installed on the machine:

    1. A registry entry that tells the cumulative update package setup to install the LDR branch
    2. Executing the package installer with a switch to force install of the LDR branch
    3. Applying an IE hotfix to the machine. When a hotfix has been applied, the setup program for the IE cumulative updates will always install the LDR branch.

    This Internet Explorer  KB article describes 1 and 2 above

    REDBITS are .NET 2.0 and some other assemblies included with Vista. REDBITS are intended to have SP level testing and compatibility. 
    Winfxred is used by the Visual Studio group; I was unable to determine the difference between the Winfxred and SP designators.

    Longhorn and winmain could be referring to different build labs. You should just look at build numbers in that case.


    Jim Truchon]

  9. Alexander Sklar - MSFT says:

    Hi Omer,

    Great article! I’m a WinSE developer for the Windows Client Platform and many people outside of msft don’t know a lot about what we do 🙂

    Thanks for taking the time to write it !

    Alexander Sklar – Software Development Engineer

    Windows Serviceability – Client Team

    Microsoft Corp.

  10. Cengiz Kuskaya says:

    Thanks for the detailled information !

    Cengiz Kuskaya

  11. No "…in the next blog entry, I will talk about the staging mechanism"…

    [You're right, that next article never did appear.  The author has since moved on to a new role, so he won't be writing a follow-up.]

  12. Billy Bob says:

    this was not helpful at all!!!!!!!!!!!!!!

    [We are sorry to hear this.  The article was accurate at the time it was written 5 years ago.  As software engineering is constantly evolving, some of the concepts presented here may have changed during this time.]

Comments are closed.

Skip to main content