Survey of Windows update formats: The Express update

Raymond Chen

Last time, we learned about the Delta update. We’ll continue with the Express update.

The Express update augments the Full update by including patches that bring each preceding version up to date with the latest version. Each patch set is typically between 150MB to 200MB in size, although the ones that span a longer time frame are larger because the patch is bigger.

For Express updates, every possible way of updating the file is in play:

Update Full file Patch base
M0 M1 M2 M3 M4
M1
M1
M0 to M1
 
 
 
 
M2
M2
M0 to M2 M1 to M2    
 
M3
 
       
 
M4
M4
M0 to M4 M1 to M4 M2 to M4  
 
M5
M5
M0 to M5
M1 to M5
M2 to M5
 
M4 to M5

The breakdown of files for Express updates is as follows:

Express update Contents
M1 M1, M0 to M1
M2 M2, M0 to M2, M1 to M2
M3 M2, M0 to M2, M1 to M2
M4 M4, M0 to M4, M1 to M4, M2 to M4
M5 M5, M0 to M5, M1 to M5, M2 to M5, M4 to M5

Note that the M3 Express update is the same as the M2 Express update since the file F did not change between M2 and M3.

Applying an Express update is more complicated than the Full update or the Delta update.

The client connects to the server, and the server says, “Here’s a list of files. Please tell me what versions you have for those files.”

The client does an inventory of the files on the system and figures out what version they are. (My guess is that it computes a hash.)

The client sends the inventory to the server, and for each file, the server checks whether it has a patch to bring that version to the latest version. If so, then the client downloads the patch. If not, then the client downloads the full file. The download is performed as a range request from the server, requesting a specific range of bytes from the entire Express update.

If you’re lucky and there is a patch for every file in the update, the client winds up downloading between 150MB to 200MB of data from the server. If you’re not lucky and there are no patches for any file in the update, then you’re back to a 1GB Full update.

You are almost always lucky, because the Express update contains patches for every monthly cumulative update. The only legitimate way it would fail is if you had installed a hotfix. (It could also fail for illegitimate reasons, say, if a customer decided to hack the file by patching it with a hex editor.)

The total disk space required on the server is the 1GB for the Full update, plus the 150MB–200MB for each patch set. For example, Express update M5 contains the M5 Full update, as well as four sets of patches, for a total size (back-of-the-envelope) of around 1.7GB.

Feature summary of Express updates:

  • Express updates can successfully update all customers, since it contains a Full update as an emergency fallback.
  • Express updates are larger than a Full update on the server, but require only a seventh to a fifth of the bandwidth to deliver to the client.
  • Express updates require significant negotiation with the server to determine what needs to be transferred, and each customer gets a download tailored to their configuration.
  • Express updates are less cache-friendly, because not every customer downloads the same thing. But hopefully, most of your customers have similarly-configured systems (all running the same monthly cumulative update with the same hotfixes) and end up downloading the same set of patches.
  • Express updates require significant server support because of the complex negotiation, as well as the need to support ranged downloads.

You might ask, “Why even bother with Delta updates? They work only for systems that are one month out of date, and they require a larger download than the corresponding Express update!” And you’d be right. There’s really no scenario where Delta updates are better than Express updates. They exist because Express updates were originally supported only by Windows Server Update Services¹ servers. That restriction was lifted back in January 2017, and the plan was to drop Delta updates in February 2019, but based on customer feedback, the sunset date was extended to April 2019. So I guess there were people out there who needed extra time to transition their custom update delivery system from Delta updates to Express updates.

But the Delta updates sunset date has passed. You can forget everything you learned about them. Use that brain space to remember the names of more Pokémon characters or something.

Next time, we clear out even more brain space for Pokémon characters by introducing Quality updates, which render all previous updates obsolete.

¹ That name is quite a horrible mouthful.

8 comments

Discussion is closed. Login to edit/delete existing comments.

  • Joshua Hudson 0

    If you’re going to hexedit a Windows file, break the link by deleting (or renaming) the file first, so the copy in WinSxS doesn’t get edited. This avoids confusing the servicing stack, and allows it to just overwrite your changes.

  • qbprog 0

    Why it is the client which sends the list of files to the server and not the opposite?Could not the client calculate the changed files by itself?

    Another curiosity : why the disk drive cleaning->windows update takes so long on win10 systems?

    Nice articles indeed!

    • Raymond ChenMicrosoft employee 0

      If the server sent, say, “The current hash of F is H5”, and the client realized, “Oh, I have the wrong F. Server, please send me the new F,” then you’d have basically a Delta Update. Since the server doesn’t know what version of F is on the client, it can’t send a patch. I guess the client could say, “Server, please send me the patch to get from H3 to H5, if you have one.” And then the server says, “Yes, I do. Please do a ranged read from X9 to X42.” That’s a lot of chatter between the client and the server. As opposed to the server saying, “The current hash of F is H5. If you have H1, then do a ranged read from X3 to X5; if you have H2, then do a ranged read from X50 to X72, (etc).” Now the server sends one block of data down, and the next thing that happens is the client starts reading patches. (Second question is on my list.)

  • Yuri Khan 0

    Why does the protocol use ranges for carving a patch out of an Express update? That is, what advantage does this provide against storing each patch as a separate URL named something like explorer.exe/from/{old-hash}? (The server would still need to tell the client a list of {old-hash}es for which it has patches.)

    (Alternatively, I think the standard-compliant way would be to use delta encoding as specified by RFC 3229, but I don’t know of any actual web servers implementing that.)

    • Raymond ChenMicrosoft employee 0

      I assume it’s to make it easier to host the patches on a web server. You just drop one file on the server and you’re done. Your way requires either dropping thousands of little files on the server in a carefully-architected directory structure, or doing file virtualization where each such request turns into (ta da) a range request.

  • 紅樓鍮 0

    Fortunate that we have HTTP/2 and even /3 today, or else who knows how many HTTP connections would it take to complete one Express Update.

    • Em X 0

      HTTP/1.1 pipelining worked fine with a single connection through the whole sequence. It never gained traction for web browsing because 95% support still meant 5% of everything you do will break (although it was amazing when I was on dial-up), but the update services are a much more constrained ecosystem.

      • Raymond ChenMicrosoft employee 0

        The client and server may be constrained, but the intermediate proxy is not, and according to Wikipedia, most proxies don’t support pipelining.

Feedback usabilla icon