Legolash2o

What are GDR, LDR and QFE Updates?

16 posts in this topic

Source

Basic Description

General Distribution Release

GDR packages contain only security and critical stability issue fixes. These are usually released via Windows Update.

Limited Distribution Release

LDR packages contain "other" fixes that have not undergone as extensive testing, and resolve issues that only a fraction of the millions of Windows users might ever encounter. You usually request these from the Microsoft website but they're mostly found in SoLoR Updates.

Quick Fix Engineering

QFE is the old name for LDR (above).

How are they installed differently?

  • At the end of the day, if you have LDR/QFE Mode enabled it will install LDR Mode if the update has that option regardless if its cab or an msu file.

MSU Files

*.msu files will get installed normally using the command below.


pkgmgr.exe/norestart /ip /o:"C:\W7T\Mount;C:\W7T\Mount\Windows" /m:"UpdateLocation\update.msu" /quiet

If you have LDR/QFE Mode enabled then the *.cab file is extracted and the below (CAB Files) method is then applied to the newly extract cab file.

CAB Files

Normally *.cab updates have a file called 'update.mum' but LDR updates also have a file called 'update-bf.mum', if the 'update-bf.mum' is not detected W7T will install cab files normally. Cab files are usually extract from the msu file or when a user has used 'MSU to CAB Converter'


pkgmgr.exe/norestart /ip /o:"C:\W7T\Mount;C:\W7T\Mount\Windows" /m:"CABLocation" /quiet

If, however the update-bf.mum has been located it will extract the cab to a temp folder and install both *.mum files like so:


pkgmgr.exe/norestart /ip /o:"C:\W7T\Mount;C:\W7T\Mount\Windows" /m:"ExtractCABTemp\\Update.mum" /quiet
pkgmgr.exe/norestart /ip /o:"C:\W7T\Mount;C:\W7T\Mount\Windows" /m:"ExtractCABTemp\\Update-bf.mum" /quiet

That's it.

Full Description

Out of the box, all of the files in Windows are on what we refer to as the "General Distribution Release" (GDR) branch.

If updates are only delivered from Windows (or Microsoft) Update (including via WSUS), then all the files remain on the GDR branch.

Some KB articles have packages to address specific issues that are not delivered by Windows Update - "Limited Distribution Release" (LDR) branch packages.

Previously we used the term "Quick Fix Engineering" (QFE), but LDR has taken over – expect to see these terms used synonymously.

GDR packages contain only security and critical stability issue fixes.

LDR packages contain "other" fixes that have not undergone as extensive testing, and resolve issues that only a fraction of the millions of Windows users might ever encounter.

It is not the entire OS that is considered GDR or LDR - it is down to the individual file level.

A package delivered by Windows Update contains both GDR and LDR versions of the files it updates, so that it is able to replace the files on the system regardless of which branch they are currently on.

A package acquired outside of Windows Update contains only LDR versions of the files it updates, and this will "move" the files onto the LDR branch where they will remain until the next Service Pack.

A Service Pack (SP) contains only GDR branch versions of the files which have been updated by ANY package since the previous Service Pack (or RTM).

So installing the latest Service Pack at, or shortly after release will likely put all of your files (back) onto the GDR branch.

One other thing that Service Packs imply is that hotfix packages need to have versions of the files to replace for the most current SP level and the previous one (dubbed "N and N-1 support").

So for every single file updated by a Windows Update hotfix package after the first SP, there are 4 versions of the file present:

"N-1" GDR

"N-1" LDR

"N" GDR

"N" LDR

Taking a ficticious example, where we have the following files straight out of the box:

A.EXE RTMGDR 1.0

B.DLL RTMGDR 1.0

C.SYS RTMGDR 1.0

1) Hotfix package KB000001 is installed through windows Update, and contains an update to B.DLL - this pacakge contains:

B.DLL SP1GDR 1.1

B.DLL SP1LDR 1.1

> The SP1GDR version is installed by default, and there are only 2 (identical) versions of this file in the package as we're not yet at SP1.

The machine now has:

A.EXE RTMGDR 1.0

B.DLL SP1GDR 1.1

C.SYS RTMGDR 1.0

2) Hotfix package KB000002 is installed, NOT through Windows Update, and contains an update for A.EXE - this package contains:

A.EXE SP1LDR 1.02

> No options here, the version that ends up on disk is now the LDR version

The machine now has:

A.EXE SP1LDR 1.02

B.DLL SP1GDR 1.1

C.SYS RTMGDR 1.0

3) Hotfix package KB000003 is installed through Windows Update and contains an update to A.EXE and C.SYS - this package contains:

A.EXE SP1GDR 1.11

A.EXE SP1LDR 1.11

C.SYS SP1GDR 1.11

C.SYS SP1LDR 1.11

> A.EXE is on the LDR branch because of KB000002, while C.SYS is still on the GDR branch

The machine now has:

A.EXE SP1LDR 1.11

B.DLL SP1GDR 1.1

C.SYS SP1GDR 1.11

4) Hotfix package KB000100 is installed through Windows Update, and contains an update for C.SYS for the RTM and SP1 versions of the OS - this package contains:

C.SYS SP1GDR 1.5

C.SYS SP1LDR 1.5

C.SYS SP2GDR 2.5

C.SYS SP2LDR 2.5

> OS level is still RTM, the current file is on the GDR branch, so we remain on the GDR branch

The machine now has:

A.EXE SP1LDR 1.11

B.DLL SP1GDR 1.1

C.SYS SP1GDR 1.5

5) SP1 is now installed on the system, which contains only GDR version 2.0 of every file:

A.EXE SP1GDR 2.0

B.DLL SP1GDR 2.0

C.SYS SP1GDR 2.0

> OS level is now raised to SP1 and we push all files on the GDR branch... but look what happens to C.SYS...

The machine now has:

A.EXE SP1GDR 2.0

B.DLL SP1GDR 2.0

C.SYS SP2GDR 2.5

> The SP1 package does not contain anything other then the GDR 2.0 versions of the files… so where did the GDR 2.5 version come from?

The hidden, compressed folders named $NtUninstallKBxxxxxx$ in the %systemroot% folder contain the backup of the version(s) of the replaced file(s) when the hotfix was applied, plus the executable to uninstall the package (in the spuninst sub-folder).

The hidden $hf_mig$ folder in the %systemroot% folder contains all the files extracted from the hotfix packages in sub-folders KBxxxxxx- these are necessary to ‘migrate’ the hotfix in the event that a switch of branches occurs or an earlier hotfix package is later installed.

In the example above at step 5, the post-SP1 hotfix package was used to migrate the updated version of C.SYS during the installation of SP1.

If this was not done, or if the folder had been deleted, then the file would have been regressed from 1.5 to 2.0.

What? A regression from a lower version to a higher version? Is that a typo?

Think of 1.5 as "RTM with KB000100" and 2.0 as "SP1 without KB000100" and it makes a bit more sense.

The migration of hotfixes to avoid regression is done from hotfix to hotfix as well as with SPs.

Imagine we have module X.DLL which has a dependency on module Y.DLL, and they both start at GDR 1.0.

Now a GDR hotfix KB000123 is applied which updates Y.DLL to 1.3.

Now an LDR hotfix KB000075 is applied which updates X.DLL to 1.1 and Y.DLL to 1.1.

The resultant files on the system would be:

X.DLL SP1LDR 1.1

Y.DLL SP1LDR 1.3

If we took Y.DLL 1.1 from the second hotfix then we regress in the security fixes, and if we left Y.DLL 1.3 from the GDR branch then we might miss a dependency that X.DLL LDR 1.1 may have which could lead to instability.

By switching to the LDR branch for the higher version of the file Y.DLL, we remain at the correct level in terms of security & stability fixes (changes in the GDR branch) but also add the fix for the issue mentioned in KB article KB000075.

Moving to the LDR branch for a specific KB article number will not just give you the security changes up to that point plus the 1 non-security issue mentioned in the KB article - it will also contain every non-security update to the files in the hotfix package.

For this reason you will see the all-too-familiar disclaimer:

"A supported hotfix is available from Microsoft. However, this hotfix is intended to correct only the problem that is described in this article. Apply this hotfix only to systems that are experiencing this specific problem. This hotfix might receive additional testing. Therefore, if you are not severely affected by this problem, we recommend that you wait for the next software update that contains this hotfix."

If you followed the above then you will also understand why you should never manually delete the$NtUninstallKBxxxxxx$ folders – you will be unable to remove these hotfix packages yet they will be listed in Add/Remove Programs (and you will gain very little disk space by doing this as the contents are compressed on disk).

If you were to delete the $hf_mig$ folder then you would break migration and may prevent the installation of future hotfixes or introduce unexpected regressions when installing service packs.

As if that wasn’t enough… you then have separate packages for the same hotfixes (where appropriate) x86 (i386/IA32), x64 (amd64) and IA64.

x86 is “only 32-bit” and IA64 is “only 64-bit”… but x64-based Windows has the concept of WOW (Windows-On-Windows) so these packages can have an even bigger list of files for the native 64-bit versions and the WOW6432 versions to support 32-bit apps.

Now you can see the value in the file lists documented in the KB articles, showing not just the file versionnumber, but the different branches which have fixes, and this has de-mystified the versioning system a little.

The above is correct for Windows versions up to and including 5.2 (Server 2003 & XP x64 Edition) – when we moved to 6.0 (Vista) we changed how it works.

Edited by Legolash2o
esieee and alfreire like this

Share this post


Link to post
Share on other sites

Very good description, although there is one question left : What happens if I use MSU>CAB Convert prior to integrating the converted hotfixes with AIO Tool? Will it still integrate the LDR branches (if the option is checked, of course)?

Edited by ulysse

Share this post


Link to post
Share on other sites

Check the first post, in your case it would get treated as a cab file.

Share this post


Link to post
Share on other sites

OK thanks, but I am still not sure I understand...

Does this mean that people who want the LDR branches to be integrated should not convert to MSU to CAB any longer?

I always used to convert the MSU files to CAB because I read that it would save time when running the integration.

Share this post


Link to post
Share on other sites

Well MSU to CAB Converter extracts the cab file from the msu, so the 'CAB Files' part of the first post still applies. And yes, i recommend using cab files if you want faster integration.

At the end of the day, if you have LDR/QFE Mode enabled it will install LDR Mode if the update has that option regardless if its cab or an msu file.

Edited by Legolash2o

Share this post


Link to post
Share on other sites

So, if I read it correctly, the Solor updates aren't the critical updates, just the "other" types of update? I just assumed that the Solor updates *were* the critical ones, so I downloaded the SP1 iso via WinKit, integrated the Solor updates and found I had 68 or something updates to still install... I really should read through these forums more :)

What resources do people here use to download a complete hotfix pack of all the critical updates? I might be simplifying things far too much, but all I want to do is download the iso, integrate a whole bunch of patches and when I check Windows Update it will say "No updates"! If such a complete pack is indeed out there could Winkit link to it, just as it does the Solor ones?

Graybags

Share this post


Link to post
Share on other sites

which will be the best to integrate if your concerned of image size?

Share this post


Link to post
Share on other sites

which will be the best to integrate if your concerned of image size?

 

GDR

Share this post


Link to post
Share on other sites

 

which will be the best to integrate if your concerned of image size?

 

GDR

 

sorry i think i was not clear of my question... i was asking between cab and msu

Share this post


Link to post
Share on other sites

I wouldn't think there would be any difference at all to image size, only in time to build it as Lego stated.

 

Cheers and Regards

Share this post


Link to post
Share on other sites

Oh yeah, the image size would be the same but using LDR mode would make the image bigger than using default GDR mode.

sigbin likes this

Share this post


Link to post
Share on other sites

Quite true since there are more LDR updates than GDR ones.

 

Cheers and Regards

Share this post


Link to post
Share on other sites

i see... the difference between them in integrating to image is the speed... i thought when you convert the msu updates file to cab the image size will shrink to a few percent... i was making an updated AiO image that will be able to fit in a 4.7gb dvd... 

Share this post


Link to post
Share on other sites

The "source" file for the update will be different sizes depending on whether it is .cab, .msu, or whatever.  The "source" files are just a distribution container, the files inside that container are the same.  If you were distributing a DVD full of updates, then I think your understanding would be correct.  But if I understand the process correctly, once you have installed/integrated that update into your updated AIO OS build, then those updates are all expanded/stripped out of their containers and either replace existing files or are stored in a "install pending" location.  In either case, I believe that the format used inside the OS to store those files is independent of the format of the "source" file.  I could be wrong, but that is the way I understand it.

 

Cheers and Regards

sigbin likes this

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now

  • Similar Content

    • [Solved] v1.5.3.12 - Cant integrate kb2603229, kb3035126, kb3035132
      By glowdude
      Host OS: Windows 7 Ultimate x64
      Image OS: Windows 7 x64
      Windows ADK for 8.1 installed: Yes (I used this link http://www.microsoft.com/en-us/download/confirmation.aspx?id=39982)
       
      In WinToolkit v1.5.3.12, when I add the kb2603229, kb3035126, kb3035132 they show up and the program says they are integrated.
       
      But when I test the image, Windows updates says they are not integrated.
       
      They are integrated when I use the dism command in cmd.
    • Do I really have to integrate updates to all images? (Win Toolkit + Win 7)
      By Psy-Virus
      Hey there,
      I've just registered, because I haven't found an answer to the following question:
       
      If I integrate updates to an install.wim. with WinToolkit, do I really have to do it for all images "separately" ?
       
      Or can I only integrate them to the "Ultimate" image?
       
      I mean, the files that are used by the setup from the install.wim are the same for every version (home, home prem, usw...) aren't they?
       
      BTW: It's really an awesome tool!
       
      THX
      &
      Greetings
       
      Psy-Virus
    • 30 out of 31 Win8.1 x64 updates integration error! (dism error 0xc0000135)
      By niT3_RiDeR_Pr0
      Hi Lego,
      I am trying to integrate the following updates (given in the log file and one more update KB2976978. There are total 30(with the error, specified in the log), + 1 (succefully integrated). all the failed updates show the following dism error: 0xc0000135. Here is the log file: http://pastebin.com/CqHrV1HS
      I had downloaded the updates from WHDownloader (Windows8.1-Update3-x64 update list), for my windows 8.1 enterprise (non-eval) x64 iso with update (en_windows_8.1_enterprise_with_update_x64_dvd_6054382.iso)
      Wintoolkit version is 1.5.3.9
       
      So how to fix this? Thanks 
       
      btw, i can't upload a log file as attahcment. why?
       
      thanks in advance.
    • Updates downloader
      By pentium4
      I was downloaded all the updates with both of downloaders and alwys I have one problem.When I integrate that updates and install win7_x86,there is more about 25 updates to install...how is that possible?
    • Integrating update-bf.mum with PowerShell
      By splinterededge
      I'm a big fan of everything that gets achieved here, however I was running into an issue that I think will start popping up in a few places.
       
      There seems to now be 4 updates for Windows 8.1 that have LDR Updates (update-bf.mum) available; Normally LDR updates can be integrated using DISM by pointing to the extracted update-bf.mum.   However I ran into some trouble attempting to integrate these updates using Add-WindowsPackage PowerShell Module.  Considering PowerShell should provide most of the DISM functions i was curious if LDR Updates are possible with Add-WindowsPackage.  Otherwise I yet to find a powershell equivalent of a couple of other functions, but that could be a discussion for another thread.
       
      I am attempting to integrate the update-bf.mum from the following KB's
      KB2898847KB2898850KB2931358KB2934520I am attempting using the following powershell scripts.
      ######## ------- INTEGRATE UPDATES - GDR -------- ########Get-Content $INI\$EDITION-UPDATES-GDR.INI | ForEach-Object {Invoke-Expression "Write-Host -ForegroundColor Yellow 'Integrating GDR Update: $_'; Add-WindowsPackage -Path $MOUNT -LogLevel Errors -LogPath $LOGS\DISM-UPDATE-GDR.LOG -ScratchDirectory $SCRATCH -NoRestart -Verbose -PackagePath $UPDATES\$_"}######## ------- INTEGRATE UPDATES - LDR - STILL BROKE -------- ########Get-Content $INI\$EDITION-UPDATES-LDR.INI | ForEach-Object {Invoke-Expression "Write-Host -ForegroundColor Yellow 'Integrating LDR Update: $_'; Add-WindowsPackage -Path $MOUNT -LogLevel Errors -LogPath $LOGS\DISM-UPDATE-LDR.LOG -ScratchDirectory $SCRATCH -NoRestart -Verbose -PackagePath $UPDATES\$_\UPDATE-BF.MUM"}I get the following error:
      Integrating LDR Update: KB2898847VERBOSE: Dism PowerShell Cmdlets Version 6.3.0.0VERBOSE: Target Image Version 6.3.9600.17031WARNING: Failed to add package Y:\ADK\UPDATES\WINDOWS-8.1.1-AMD64\KB2898847\UPDATE-BF.MUMWARNING: Add-WindowsPackage failed. Error code = 0x80070057Add-WindowsPackage : The parameter is incorrect.At line:2 char:5+ Add-WindowsPackage -Path C:\ADK\MOUNT -LogLevel Errors -LogPath Y:\ADK\LOGS\ ...+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : NotSpecified: ( [Add-WindowsPackage], PSArgumentException + FullyQualifiedErrorId : Microsoft.Dism.Commands.AddWindowsPackageCommandLooking at the log entries for these four updates, it appears that it is rejecting anything that is not a .cab or .msu file:
      [2764] ImageUnmarshallHandle: Reconstituting wim at Y:\ADK\SOURCES\WINDOWS-8.1.1-AMD64.WIM.[2764] ImageUnmarshallHandle: Reconstituting wim at Y:\ADK\SOURCES\WINDOWS-8.1.1-AMD64.WIM.2014-06-16 13:46:31, Error DISM API: PID=2764 TID=2352 Package path needs to be .cab or .msu file - DismAddPackageInternal(hr:0x80070057)[2764] ImageUnmarshallHandle: Reconstituting wim at Y:\ADK\SOURCES\WINDOWS-8.1.1-AMD64.WIM.[2764] ImageUnmarshallHandle: Reconstituting wim at Y:\ADK\SOURCES\WINDOWS-8.1.1-AMD64.WIM.2014-06-16 13:46:40, Error DISM API: PID=2764 TID=2352 Package path needs to be .cab or .msu file - DismAddPackageInternal(hr:0x80070057)[2764] ImageUnmarshallHandle: Reconstituting wim at Y:\ADK\SOURCES\WINDOWS-8.1.1-AMD64.WIM.[2764] ImageUnmarshallHandle: Reconstituting wim at Y:\ADK\SOURCES\WINDOWS-8.1.1-AMD64.WIM.2014-06-16 13:46:49, Error DISM API: PID=2764 TID=2352 Package path needs to be .cab or .msu file - DismAddPackageInternal(hr:0x80070057)[2764] ImageUnmarshallHandle: Reconstituting wim at Y:\ADK\SOURCES\WINDOWS-8.1.1-AMD64.WIM.[2764] ImageUnmarshallHandle: Reconstituting wim at Y:\ADK\SOURCES\WINDOWS-8.1.1-AMD64.WIM.2014-06-16 13:46:57, Error DISM API: PID=2764 TID=2352 Package path needs to be .cab or .msu file - DismAddPackageInternal(hr:0x80070057)Any idea if its possible to integrate LDR updates with Add-WindowsPackage?