Hasn’t the problem of updates being partially installed until the next reboot already been solved by changes in Windows?


Last week, I discussed how A question about how to detect whether Windows Update needs the system to be restarted turns out to be the wrong question. One of the issues I noted was the risk of the partially-installed updated. A number of commenters wanted to know if that problem was still true. My colleague Mark Phaedrus discussed the matter in comments, but I'm going to promote his responses to a full posting, thereby extending his Internet fame from 15 minutes to 30 minutes.

Let me answer a question that several folks have raised (both in the comments and offline): Hasn't the problem of updates being partially installed until the next reboot already been solved by changes in Windows?

This is, to a large extent, true. Modern versions of Windows use Component-Based Servicing (CBS). This technology makes sure that new Windows components, and new versions of existing components, are installed atomically. In other words, if it is possible to install or update a component without a reboot, CBS does so. If it is not possible (because one or more files are in use, or because the component requires more complicated setup), then the entire installation of the component is automatically suspended until the next reboot.

So this means that the problem described in this blog post is gone, right? Absolutely not, for at least two reasons.

First, not all updates distributed through Windows Update/Microsoft Update are purely CBS-based. There are a variety of different types of updates (drivers, Office updates, etc.), each of which may have different installation behaviors. For example, there are still a few troublesome drivers that do not behave normally until the next reboot. And from the Windows Update perspective, there is a class of updates called "command-line updates" -- updates that have unusual needs, and so cannot be published in the usual standardized formats. Command-line updates can still work in whatever way they want, just like the good old days of UPDATE.EXE. And that means that command-line updates may still be subject to the problem.

To summarize: Most updates no longer create an unusual machine state that requires a reboot to resolve. There are still a few that do. In an ordinary consumer environment, the remaining problem is small enough to be ignored (or at least small enough that there are lots of other things to concentrate on fixing first). But in an environment where The Machine Simply Must Work, it's still an unacceptable risk. And so the best practice for these environments is still assuming that any update that requires a reboot to complete should have that reboot performed as soon as possible.

Second, even setting the "Does the update do the right thing before the reboot?" problem aside, CBS itself creates another problem in this scenario. Since many Windows updates wind up getting their processing delayed until the reboot, that reboot itself can take longer (since all those pending operations then get performed). And in an environment where The Machine Simply Must Work, this means that the consequences of an accidental/unplanned reboot can be even worse. So again, in this environment, it's important to ensure that Windows Update never initiates a reboot on its own. And since Windows Update will sometimes initiate reboots on its own when it's set to install updates automatically, this means that the best practice for these environments is still the practice described in the blog: Set Automatic Updates to not install updates automatically, and use your own code to install updates and reboot at the correct times and with the proper user notification.

To reiterate earlier caveats, when I talk about situations where The Machine Simply Must Work, I naturally presume you're not talking about life-critical medical applications, because Windows is not for life-critical applications, as the esteemed attorneys who hand-crafted the Windows EULA from artisanal Unicode characters will happily point out.

To give my own favorite example of a non-medical situation where The Machine Simply Must Work, as well as one of the more uncomfortable moments of my Microsoft career: There was an internal developer conference going on at the Microsoft Executive Briefing Center, a very nice building filled with conference rooms normally used by the grand poohbahs of the Microsoft organization, and occasionally used for gatherings like this one. Throughout the building there are large displays helpfully pointing out which meetings are going on in which rooms at which times. And on this occasion, with numerous grand poohbahs on hand as well as large portions of the Windows Update team, all those displays were showing the old "Your machine needs to reboot" prompt we all knew and loved from Windows 7, with the pre-reboot countdown timer inexorably rolling down towards zero.

If the role of an internal developer conference is to encourage discussions among teams, then that one certainly succeeded. Because discussions most definitely ensued.

Comments (28)
  1. Hey Raymond, I’m almost afraid to ask but did the migration of the blog platform software to the new version impact your backlog of posts at all?

    1. The blog is on manual mode until I upgrade my scripts, but the backlog is intact.

      1. acq says:

        It seems that the links to comments still don’t work, as the id numbers aren’t the same.

        https://blogs.msdn.microsoft.com/oldnewthing/20151208-00/?p=92342#comment-1217843

      2. Brian_EE says:

        That explains why yesterday’s post was delayed almost an hour from the normal 10am EST time. That’s my normal “take a mental break from work” time when I read the freshly posted article.

        I know others have asked over the past few days, but I haven’t seen a reply… are you planning to change the stylesheet for your blog or stay with what I assume this is – the default?

        1. I might change it a little, but not much. Back in the early days, I changed the colors every three months! I’m too old for that stuff now.

          1. Mark Y says:

            I like the old colors. They were cozy.

          2. JanH says:

            I’ve done some further tweaking to my user style (so if you’ve already installed it, check for updates) and I think I’ve now recreated most of the old style: https://userstyles.org/styles/121616/the-old-new-thing-classic-style

            Apart from that, I’ve noticed two problems with the new layout in mobile mode (i.e. screen width < 768px):
            1. In the desktop style, clicking on the blog title at the top of the page takes you back to the overview with the most recent posts. In the mobile layout, the link points to "#" and nothing much happens.
            2. Especially in portrait mode, the nested comments don't work really well. Anything more than one level of indentation is either squished up against the page border or even spills over into the background. I my user style, I've reduced the amount of indentation in mobile mode, which improves the situation somewhat, although it doesn't solve it completely for deep levels of nesting.

            I've sort of fixed both issues in my user style, but as they affect all MSDN blogs using the new software though, they should probably best be fixed globally and not by using some custom CSS.

  2. The MAZZTer says:

    I actually had an issue with cygwin git that I THINK was caused by a Windows Update waiting for reboot. git pull (other git actions worked fine) would not start and I had to work a bit to figure out the Windows error code it was spitting out since cygwin was hiding it. A stackoverflow post (http://stackoverflow.com/questions/28822442/the-application-was-unable-to-start-correctly-0xc0000056-click-ok-to-close-th) lead me to the solution (a reboot was needed). I had a pending Windows Update waiting for reboot, so I assumed that was it. Who knows though, especially given this post it could have been some other installer I had run.

  3. Brian says:

    Thanks. This is good information to know. Since I’m ex-MSFT support, people (colleagues, friends, etc.) all expect me to know a little something about how this all fits together. However, after four years away from the mother ship, my knowledge is getting a little stale and needs to be refreshed occasionally (like I was by this blog post). For what it’s worth, I was one of those “customer representatives” that would occasionally pester Raymond by posting carefully crafted questions to the appropriate internal mailing list.

  4. Anon says:

    @Raymond

    I don’t think I’ve ever had a single round of Windows Updates succeed without a reboot, except when the only update was a Security Essentials definition. There was recently a *Flash Player* update for IE11 on Win10 that required a reboot — that’s not a part of the operating system, and isn’t even supposed to be part of the browser!

    1. Darran Rowe says:

      Well, Windows 10’s updates have started to be more cumulative. So there may have been another patch included in there which required a restart.
      Although if there is one problem about Windows 10 updates that I have is that the associated KB articles are lacking in details as to what the updates actually fix. For the cumulative updates, this could get quite long, so I would at the very least be happier with a list of changes that the update fixes which is new compared to the last update, and a link to the replaced update.

  5. VZ says:

    My favourite recent example showing how well this problem is solved is MSVS 2015: all of the initial installation, the CTP and the final Update 1 installation have helpfully asked to close all the existing VS instances before continuing to avoid a subsequent reboot. Needless to say, all of them have gleefully continued to rebooting nevertheless after the end of the installation.

    1. Darran Rowe says:

      The thing is, Visual Studio is a huge collection of things, so any one of them could be responsible. Normally I find that it is the .NET framework that gets installed along with it that is the cause.

  6. John Doe says:

    Another blog-related comment, right now it’s quite hard to scavenge through the archive before 2015 (or the current year, it seems), as all blog posts are put in the same bag.

    Before the transition, posts were grouped by month, no matter how old or how big the archive index turned out to be.

    We can mitigate by editing the URL and appending /{two-digit month number starting from 01}.

  7. smf says:

    One of the recent windows 10 TH2 updates appeared to leave me without tcp ip protocols until I rebooted. At least they disappeared and I needed to reboot. I have it set to manual reboot because I sometimes leave things running overnight and I like to know if they complete succesfully or not.

  8. Bob Bobson says:

    > To reiterate earlier caveats, when I talk about situations where The Machine Simply Must Work, I naturally presume you’re not talking about life-critical medical applications, because Windows is not for life-critical applications, as the esteemed attorneys who hand-crafted the Windows EULA from artisanal Unicode characters will happily point out.

    Hmm, I checked a couple of different EULAs and could not find any such mention. I looked for “medical”, “critical”, “life”, and “machine”. Nothing. ಠ_ఠ

    1. Erkin Alp Güney says:

      Limited warranty, you know. Medical hard real-time equipment too critical to use a closed source software without full warranty. If it were open source, where you could fix your bugs, lack of warranty would be less of a problem.

  9. 640k says:

    “use your own code to install updates and reboot at the correct times and with the proper user notification”

    Why can’t UpdateServices that is included as an OS feature be used?

  10. 640k says:

    A fresh windows OS usually needs multiple reboots to install all patches. This has been a pain since windows update was invented, and is still a pain.

    Why can’t windows update, in year 2015, install patches and reboot repeated times until all patches are installed? How hard could it be?

  11. — “I naturally presume you’re not talking about life-critical medical applications, because Windows is not for life-critical applications”

    So, which operating system is for life-critical applications? Sorry, but I only know OS X and Linux.

    1. I believe there are specialist niche OSs for safety and life critical systems, like LynxOS.

    2. Cesar says:

      @Fleet Command: for life-critical applications, one usually wants a real-time OS (RTOS), because they often are timing-sensitive too. Therefore, most operating systems for life-critical applications will also be a RTOS. And Wikipedia has a list of them: https://en.wikipedia.org/wiki/Comparison_of_real-time_operating_systems

      1. So, Windows Embedded. Which looks like and works like Windows NT.

    3. Sam says:

      Green Hills INTEGRITY is one of the more popular high reliability platforms.
      http://www.ghs.com/products/medical_platform.html

  12. Destroyer says:

    Thanks Raymond/Mark for more info on this. Really interesting to know and all very logical too.

    PS obligatory comment about new blog theme. I did prefer the older one on the eyes, hopefully the style can be chaneged a bit to make text easier to read (as well as your responses to comments etc)

  13. Medinoc says:

    Wasn’t there a thing about the “download but don’t install” setting not being respected for some security updates?
    I remember someone posted something like that (on the update against the “blaster” worm, I think) and concluding that for critical computers, only the “notify but don’t do anything else” setting was safe.

  14. DWalker says:

    “If it were open source, where you could fix your bugs, lack of warranty would be less of a problem.”

    No! If “it” were open source (meaning your operating system for life-critical systems) then you would have to study all of the source code to make sure it met your requirements, and that it had no bugs — which are really, really hard to find in a large system.

    Using an open-source system does not magically guarantee quality, especially if there are millions of lines of code in that system.

  15. aaron says:

    I think its hilarious that you think “life-critical medical applications” are written to some higher standard.

    What I wouldn’t give at my current job, in a life-critical field, for a handful of my old Microsoft co-workers.
    Instead, I’m staring at a mountain of 20 year old code that has serious flaws every 5 lines.

    (just one example: http://www.reuters.com/article/us-hospira-fda-cybersecurity-idUSKCN0Q52GJ20150731)

Comments are closed.

Skip to main content