A question about how to detect whether Windows Update needs the system to be restarted turns out to be the wrong question

A customer wanted to know whether there was a way to detect that Windows Update has recently installed an update that requires a reboot. They explained that their computers are running dedicated software, and the customers are not technically-savvy, so they want to display the "You need to reboot" message more prominently, and let the user choose the best time to reboot. "We have been checking a variety of registry keys, and we have found that the set of keys to check is quite extensive and varies depending on the nature of the update that was installed."

There is a fairly straightforward way to check whether Windows Update is waiting for the system to reboot, but we asked for more information about the customer's scenario. Fortunately, the customer was willing to share.

These computers are in a hospital running critical medical software. The software runs 24/7 and must not reboot without user consent.

If these are critical machines, then asking whether Windows Update is requesting a reboot is the wrong question. By the time you get the answer "Yes", you are already in trouble: If you reboot the computer as soon as a reboot is required, you interrupt the machine's critical functioning. If you postpone the reboot, then you leave the computer in a nonstandard configuration wherein an update is partially-installed, and that nonstandard configuration may compromise the machine's critical function.

In this specific case, the idea would be to change the design from "Install the update, and then postpone the reboot until a convenient time" to "Wait for a convenient time, then install the update and reboot immediately." Here's a sketch of how it could work. (Note: This is a sketch, not a fully-analyzed scenario. Do not implement this design on your critical medical systems before independently validating its efficacy to your satisfaction. In fact, as a general rule, you should not use blog posts as the sole basis for software design decisions for critical medical systems.)

  • Set Automatic Updates so it does not install updates immediately. Either disable it, or set it to download updates without installing them.
  • Ensure that users do not have permission to alter these settings or to initiate the installation of updates independently.
  • Periodically check whether there are new updates available. The Searching, Downloading, and Installing Updates script on MSDN is an example of how you can use the Windows Update Agent API to answer questions like this.
  • If there are updates available that do not require a reboot, you may choose to install them without interrupting service. You can use the Installation­Behavior.Reboot­Behavior property to determine whether a particular update guarantees that it can be installed without a reboot.
  • If there are updates available that may require a reboot, inform the user that the computer will be unavailable while the updates are installed and let the user choose when to install those updates.
  • When installing the updates, display a message indicating that the computer is unavailable.
  • When installation is complete, reboot immediately.

The important things are that (1) you treat the installation of the update and the reboot as a unit, and (2) you don't start the install+reboot process until the user confirms that they are okay with the system being temporarily unavailable.

Thanks to my colleague Mark Phaedrus for providing the raw materials from which this article was constructed.

Comments (50)
  1. Joshua says:

    Incidentally such life critical systems do things like preload all their DLLs so the nonstandard state is less dangerous than usual. All the same they will surely take your advice.

  2. Cesar says:

    I'd expect machines running critical software to be running on an embedded operating system, not on a general-purpose desktop operating system. Is the Windows version they are using certified to be used for such critical software?

  3. Eric says:

    My first question is why such life critical systems are getting updates through Windows Update in the first place.  One would think that a managed solution (e.g., WSUS) would make a lot more sense in that environment.

  4. alegr1 says:

    Another question is why the life critical system has access to Internet. They should be on an isolated network, if they have to be networked at all.

  5. BrianVan says:

    Cesar: Generally, Microsoft believes Windows (or at least certain flavors of it) has the ability to be an embedded operating system for critical functions. And while your mother's friend's nephew's college roommate is probably not the person to put together a system meeting critical specs, a master of the OS has all the tools they need to get Windows to behave accordingly. (You see blue screens of death on airport kiosks and digital billboards because the team who did the work… weren't masters)

    Note, I qualified this all with "generally" and the skepticism is warranted. And I bet even the world's top system experts who work with Microsoft OS products would probably offer, in most cases, a non-MSFT option with a lower overall cost of operation for critical applications. All this talk about reboots & updates… that's a lot of nonsense to include for a package needing to meet a 24/7 requirement.

  6. Ancient_Hacker says:

    Um, I would be a lot more cautious.   Having worked in medical software, I think a LOT more caution is needed, like first testing the software with the system updates.  All it would take is some "improvement" in how something in a system API is done, like making it work more quickly, and we're in Therac-25 territory.  

    Also, does Windows update still have the charming feature of wanting to download updates to the C: or system drive?    Charming.  If this is a medical device, filling up the disk with updates could again be a very serious issue.  

    So I don't think you want medical devices to be downloading anything, ever.  At the medical place releasing new software/system combos involved a whole lot of testing and a careful release process.

  7. M says:

    @alegr1 I suspect (hope) that "life critical" and "critical medical software" are not interchangeable. Life-support machines are life-critical: the receptionists' PCs or some diagnosis-entry machine might also be considered "critical medical software".

  8. Brian_EE says:

    I agree with "M"…. commenters made the leap from the term "critical" to "life critical" with no evidence.

    For all we know, this could be the machine at the nurses' station that monitors and alerts information gathered from the systems in the patient rooms – so it might not be by itself life-critical, but it is critical in the sense that it can't be offline without prior planning. That's just one example I could think of.

  9. Cesar says:

    @BrianVan: the part about displaying the "you need to reboot" message is what makes me think it's a normal desktop version of Windows, not one of these stripped-down embedded versions of Windows.

    And doctors do some very cringe-worthy things, security-wise. One I've witnessed recently: to watch a X-Ray, just put the CD in their desktop and run the viewer (a Windows executable) contained on the CD. By the way, the CD was with the patient, it didn't come directly from the radiography lab to the doctor's hands.

  10. David Ching says:

    One unknown is how long will it take to install the updates and reboot.  On one of my older PC's running Windows 7, sometimes it takes only a few seconds to install the updates, another times it took 40 minutes or so and when rebooted it had to restart twice.  What is needed is some sort of "system impact" of each update to know if the update will need to be performed overnight or can wait for the coffee break.

  11. Mr Cranky says:

    The only question is whether updates are pending.  *All* updates are evidently "important", and *all* updates require a restart.  Latest example is KB3102429: "Update that supports Azerbaijani Manat and Georgian Lari currency symbols in Windows".  This one appeared all by itself.


  12. Eric says:

    Brian EE — You are correct that "life critical" was an erroneous term.  However, the correcting the description of the "critical medical software" that "runs 24/7 and must not reboot without user consent" doesn't change the problem or my view one bit.

  13. HiTechHiTouch says:

    Another gotcha — sometimes M$ Update wants to update M$ Update itself, which is most difficult to see coming, or to stop.  Don't quote me, but I believe one past iteration required me to reboot.

  14. Joshua says:

    @Eric: Nor mine

    @HiTechHiTouch: At least that one doesn't push for the reboot but will happily wait as long as necessary (I've seen it).

  15. KB3102429 says:

    @Mr Cranky: according to the KB article the KB3102429 update is categorized Optional.  Based on the file information in the article, the update apparently contains a rather surprisingly long list of Windows DLLs, which may help explain requiring a reboot.  I can only speculate that it must've affected some shared static lib?


    But yeah, other than Windows Defender definition updates, I can't remember the last time a Windows Update didn't require a reboot on my computer.  Granted, to expect otherwise is kinda like expecting your auto mechanic be able to safely and properly service your car while you're still driving it.

  16. Destroyer says:

    @alegr1 – Just because something is critical doesn't mean it can't have access to the internet, that is a bit blanket.

    @Raymond – I always assumed that the first phase of updates (i.e. installing them before reboot) does NOT leave the machine in a non-standard configuration, which is why since Windows 8 / Server 2012, it will attempt to install the updates in the background and then will happily sit there on the "the system needs to restart" for days/weeks etc until the user allows it. Granted it is in a semi-installed state though and you're still past the point of no return because it is going to take longer to restart than normal, but I thought in terms of the running OS, it is still consistent and unchanged. Could you comment on this?

    [I wouldn't be surprised if the update process was improved to be more atomic. But I'm not the subject matter expert, so my thoughts don't mean much. -Raymond]
  17. Damit says:

    De-lurking to answer Destroyer's question: Since Windows Vista and the move to component-based servicing (CBS), if a file is in use when an update is attempted, the entire operation will be postponed until reboot (hence the "Windows is installing updates…" at shutdown/restart), the files will be updated in a kernel transaction (KTM) – one of its properties is that either all files are updated or or none are – and then the update install will resume after reboot before the login screen. It was much more of a concern on XP where you could have some files updated but others that hadn't been updated yet.

    Joseph Conway's blog (blogs.technet.com/b/joscon) has had several posts in the past on the changes to the servicing model in Vista, Win7, Win8 and Win8.1.

  18. Brian says:

    Unless something has changed in the last several years, once updates (that require an update) have been installed, the system is often in a bit of a "Franken-state" until it is rebooted.  Consider the case where an update changes two DLLs, one of which is loaded in a process (and hence requires the reboot) and one isn't yet loaded into the process, but will be soon.  The reboot-requiring DLL won't be replaced until the update, but the other one may be replaced immediately.  Even if much care was taken by Microsoft to try to make everything atomic, you are very to occasionally get into an untested state.

    @Ancient_Hacker: It's very unlikely that anything Microsoft could do to Windows would ever cause it to enter Therac-25 territory.  If you look into that system, it was pretty much a hack from start to finish (for example, a hand-hewn "real time OS" that provided no way to synchronize updates to memory).  Now, it wouldn't surprise me to see a Microsoft customer write a Therac-25-class bad application on Windows…

    @Everybody:  Consider a system like one that automates/supervises a blood-analysis device.  The device generally operates 24 hours a day in the lab, and its supervisory computer must be actively working unless the device is in a stand-by state.  However, it would not be unreasonable to have a 30-60 minute monthly maintenance period as part of its working schedule.  That is likely similar to what the customer meant by "in a hospital running critical medical software [that] runs 24/7 and must not reboot without user consent"

  19. Joshua Bowman says:

    @David Ching

    In general you can assume that any .Net update will take minutes, and any core OS non-.Net update will take seconds. 40 minutes and multiple reboots would likely indicate that an update failed, was backed out, and reapplied after another reboot, which isn't something you can really predict.


    Of course you always test beforehand. You go through these steps after testing, once you've pushed the update out. There are many organizations with hundreds or thousands of "critical" systems like this set up similarly, they don't all need to be individually walked through the update by IT.

  20. Joshua says:

    @Brian: If somebody wrote the Therac-25 control software in user-mode Windows, it's in a nasty bug territory before even looking at the source code or development model. This is not a general dig at Windows, but there is a specific thing here.

    Windows cannot provide hard realtime CPU and IO no matter what. The last version of Windows that could was Windows 3.1. The fundamental problem is Windows can decide to page your EXE out, and if you block that, it can decide to page out parts of its own internal DLLs, even if swap is completely disabled. Hard realtime + paged out code = bad news.

    Thankfully these kinds of applications are rare.

  21. Brian says:

    @Joshua: I don't doubt that if the guy who wrote the Therac-25 (it was one person, no supervision, no design or code review) had written that system on the NT platform, it still would have been a basket of lethal bugs.  My argument is that this statement is pushing it: "All it would take is some "improvement" in how something in a system API is done, like making it work more quickly, and we're in Therac-25 territory."

    Yeah, in a real system (something like the Therac-25, but one without the lethal after-effects), the manufacturer should be verifying every Windows Update release and letting its customers know when to apply any updates.  However, it's unlikely that a Windows Update fix would result in a severe radiation over-dosing à la Therac.

  22. Wisefaq says:

    Gawd, I hope they're in a managed environment, running Group Policy to manage those settings.  The only time I've ever not been allowed to patch a "health industry" PC is Windows PCs running process control software for a pharmaceutical company.  Those PCs were certified to perform their particular function.  Real PITA, but they were on their own segmented network.

    The only downfall of Raymond's guidance is that you get a class of user who never patches and reboots.  What I've done for those folks is implement an extremely long shutdown timer ("your PC is going to reboot in 30 days").

    For Raymond's customer example, you could quite easily substitute "Executives who run Powerpoint presentations" or "Training PCs only brought out from storage every 30 days".

  23. Harry Johnston says:

    What I want to know is why Windows 10 seems to have gotten rid of the "the system needs to restart" notification altogether.  We've been experimenting with Windows 10 at my workplace, and it doesn't seem to tell you about pending updates unless you explicitly navigate to the WU control panel.  Has anybody gotten this to work as expected?

  24. Darran Rowe says:

    @Harry Johnston:

    Under the advanced options for Windows update, there is the "Choose how updates are installed" option. You can set this to "Notify to schedule restart". This should then prompt you to choose the restart time manually rather than it automatically choosing a time.

  25. ender says:

    @Darran: the notification only works if you happen to be at the computer when it's displayed (it's shown for less than 30 seconds). If you miss it, well, hope you didn't leave any long running task overnight, because hey, 3:30 seems like a good time to kill everything that's running and force a restart.

  26. bv1 says:

    I work at a hospital – embedded PC's and life critical are on their own networked and handle differently.  Imagine a nurses station where the nurse is talking to a doctor they paged about a patient, he is asking questions about notes, meds, readings,  etc. that are in the EHR(Electronic health record) and her PC reboots. Neither the doc on the phone or the nurse is happy and will let the CEO know this is not acceptable.

    To the original question, it is possible with both reviewing patch documentation, using testing machines prior to deploying all updates, that we in IT do not know if a particular PC will reboot or not when patch is applied.  This has to do with the nature of patches that we get from microsoft. In one case, if the PC had silverlight on it or not caused it to reboot. Silverlight was not mandated (or core) as it was a web tech. at first.  All the test machines had silverlight and did not reboot.  The monthly patch came through, machines without silverlight rebooted. We since have added silverlight as a core item and it will be installed on all PC's.

    If we had an ability to know a reboot is going to occur that could be added to the scripts it would help. (Notify user, email IT, etc.)

    The second problem class with reboot updates –  For full fun, have users who poweroff the PC because it was taking longer than normal to reboot.

  27. Anon says:


    Agreed wholeheartedly. I'm all for forcing end-users to restart once running applications are properly shut down, but I don't want my machine terminating Visual Studio with unsaved code open. Which has happened. Repeatedly.

  28. Entegy says:

    @Ender Do you guys not look at the action centre for missed notifications?

  29. DWalker says:

    It seems, from a pure "computer science" standpoint, that an operating system "could" apply updates without rebooting.

    Consider the state of the system, including the layouts of DLLs in memory, process memory, and files on disk (including the pagefile), etc. before applying the updates.

    Now consider the state of the system after applying the updates and rebooting.

    Now consider an algorithm that could map the first state to the second state — things in memory need to be moved around, and things on disk need to be moved around.  This movement could happen all at once (with a slight delay to all other processes which are suspended, to let the update service move everything around atomically) but it could take less time than rebooting.

    Surely this is *doable* without a reboot; such an algorithm should be create-able.  Although the complexity might be overwhelming.

    [You underestimate the complexity of this. Suppose a structure grows by 4 bytes. Every instance of this structure needs to be identified, and possibly relocated if the four bytes immediately after the structure are being used for something else. Now you need to update all references to the relocated structure. Some of those references may be in other processes (hiding behind an RPC connection); other references may be in encoded pointers (so a straight memory scan won't find them); you have false positives if an integer in memory just happens to be equal to the old address by coincidence. To do this properly, you need cooperation from the compiler so it can tell you at any time "Please tell me where all pointers can be found", which could be quite nonobvious after optimization; plus you need cooperation from RPC, debuggers, anybody who uses ReadProcessMemory… -Raymond]
  30. Richard says:


    Microsoft calls this Hotpatching:  technet.microsoft.com/…/cc787843%28v=ws.10%29.aspx

  31. ch says:


    It's impossble in theory. Some of the relevant state may be unreachable by the update process (e.g. something has switched from using protocol X version N to protocol X version N+1 or to protocol Y and before the update there's a connection open to a remote server).

    Even in cases where it's all local, the change can be impossibly complex. Consider a library which switches from reading a file a chunk at a time to mapping it into memory. If it is partway through the operation there may be a mapping between the states, but it would be overwhelmingly difficult to apply it. What if the file currently open is too big to map? If the updated code had been run maybe the file would have been opened before the address space got to fragmented to have space for it, so to map the state you need to do garbage-collection like operation which can move objects around even though the code was not written to support this. Or maybe the updated code would have rejected the file as being too big, so to reach the mapped state you need to go back in time to pretend the file was never opened, find and modify all the logging servers which currently record that the file open succeeded and change those records to show that it failed.

  32. @DWalker: You could do this inside the kernel itself, sure, as long as device drivers aren't impacted by the update (or alternatively, the affected device drivers are taken offline and then brought back online once the hotpatch is applied).  Basically as long as you can take any affected processes, shut them down, apply the patch, and bring them back online, then you can avoid a full system reboot.  You could even feasibly make this smart enough to identify which update will impact which processes/services/drivers/whatever.  It's of questionable benefit, though, since the odds that you can keep your program running while critical libraries are updated is pretty unlikely.

    I am curious how much of this impacts Linux-land; I know they have kernel-hotpatching, but honestly the kernel's the least interesting piece compared to the servers and daemons that need to be kept up-to-date. If an update only impacts some running services and not any user applications, is Windows Update smart enough to shut down the service and restart it, thus avoiding a reboot?

    [But what if a user application tries to communicate with the service while it is temporarily shut down? "Shortcuts will not track properly for the next 5 minutes while we update the link tracking service. Mahalo." -Raymond]
  33. Joshua says:

    [You underestimate the complexity of this….]

    I only want to do it for security updates. Security updates rarely change data structures. On a high reliability device non-security updates aren't going to be applied at all. A good effort should yield 90-99% patched w/o reboot (the ones that didn't change data structures) and that's good enough.

    @MNGoldenEagle: Most Linux services (X not included) can be restarted while they are running, and all of them can have their backing binaries replaced before they are restarted. If we're willing to use SO_REUSEADDR than we change half of those to "services that can be restarted before they are stopped". So, it's more like "Shortcuts will not track properly for the next 5 milliseconds while we update the link tracking service. Mahalo."

    @Brian: My claim is far stronger. In fact I can only pull off the hard-realtime on a Linux box by accident (because they implemented ramfs for completely unrelated reasons). I can avoid the paging system libraries by static linking, something Windows does not provide. Flash-restart critical processes to apply security updates is hard but not impossible (sysvinit does it). The hard realtime program would have to wait for idle time, safe the hardware, then reset itself.

  34. "If you postpone the reboot, then you leave the computer in a nonstandard configuration wherein an update is partially-installed, and that nonstandard configuration may compromise the machine's critical function."

    That is incorrect on Windows Vista and later.

  35. Erkin Alp Güney says:

    > But what if a user application tries to communicate with the service while it is temporarily shut down? "Shortcuts will not track properly for the next 5 minutes while we update the link tracking service. Mahalo."

    @Raymond: Block on the call if a component is going to be added or replaced, fail immediately if said component or API is removed.

  36. 640k says:

    @Raymond: "You underestimate the complexity of this…"

    It's complicated, but it's not impossible. You have to set restrictions of what can be patched in-memory, not all imaginable software can be patched. Before Chrome, people assumed it was impossible to patch web browsers in-memory. IE/edge still doesn't support it. Why?

    @Raymond: "To do this properly, you need cooperation from the compiler"

    Yes, you need to cooperate with your visual studio coworkers. That might actually be the biggest hurdle. But I assume it would be more easy to patch your customers to death than to solve this.

  37. ender says:

    @Entegy: how can I look at the action centre if I'm not at the machine? Also, in Windows 7, Explorer could fairly reliably detect when I was not at the computer, and left the balloons shown until I returned (specifically, "Updates are ready for your computer" would greet me when I unlocked my workstation, regardless of when it detected new updates – why doesn't this happen any more, or at least why doesn't action centre pop up automatically if there are unread notifications instead of expecting me to click it every time I get back to the machine?).

  38. Viila says:

    @Erkin Alp Güney: "fail immediately if said component or API is removed."

    What if the API can not signal failure? Or explicitly can not fail in ordinary circumstances so no program checks the return value?

  39. Joshua says:

    @Viila: Than the update violates the rules whether it's installed by hotpatch or not.

  40. Max says:

    One thing to keep in mind when talking about updates is the sheer age of the architecture. Windows NT was built in the era before downloading updates from the internet anytime was a commonplace thing. In those days, you bought a service pack on a set of floppy disks, instead of pulling down dozens or hundreds of megabytes of updates every month via your always-connected broadband internet. Windows Update was a sad, sorry show in the 90s. Of course, Linux is old as well, but different architectural decisions made long ago led to an OS that turned out to be much more suited to updating without interruption due to its modularity and such.

    It's not really a matter of smart decisions vs dumb decisions; the Windows model made perfect sense at the time, and I don't think too many programmers of that era could have conceived of the cheap-and-easy update culture modern-day computing has developed. It's just the nature of being hamstrung by decisions that were made twenty years ago – sometimes it turns out well, sometimes it doesn't.

  41. Mark Phaedrus says:

    My thanks to the esteemed Raymond Chen for the brief moment of MSDN fame.

    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, which I'll have to give in a second comment due to space limitations.

  42. Mark Phaedrus says:

    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.

  43. Mark Phaedrus (WU) 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.

    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.

  44. WinUser says:

    It's not just Windows Updates that would require a reboot.

    # The following Test-Path checks assume that only the OS has control over those keys.

    # When all pending operations have been completed after system start, the OS deletes the keys.

    $PendingComponentBasedServicing = Test-Path 'HKLM:SOFTWAREMicrosoftWindowsCurrentVersionComponent Based ServicingRebootPending'

    $PendingWindowsUpdate = Test-Path 'HKLM:SOFTWAREMicrosoftWindowsCurrentVersionWindowsUpdateAuto UpdateRebootRequired'

    $PendingFileRename = (Get-ItemProperty 'HKLM:SYSTEMCurrentControlSetControlSession Manager').PendingFileRenameOperations.Length -gt 0

    # See msdn.microsoft.com/…/dd392286.aspx for details about the use of the SETUPEXECUTE key.

    $PendingSetupExecute = (Get-ItemProperty 'HKLM:SYSTEMCurrentControlSetControlSession Manager').SETUPEXECUTE.Length -gt 0

    # Check if the name of the computer was changed.

    $PendingComputerRename = (Get-ItemProperty 'HKLM:SYSTEMCurrentControlSetControlComputerNameActiveComputerName').ComputerName -ne (Get-ItemProperty 'HKLM:SYSTEMCurrentControlSetControlComputerNameComputerName').ComputerName

    $ResultsTable = @{}

    $ResultsTable.Add("Component Based Servicing", $PendingComponentBasedServicing)

    $ResultsTable.Add("Windows Update", $PendingWindowsUpdate)

    $ResultsTable.Add("Pending File Rename", $PendingFileRename)

    $ResultsTable.Add("Pending Setup Execute", $PendingSetupExecute)

    $ResultsTable.Add("Computer Rename", $PendingComputerRename)

    # Show table


    if ($ResultsTable.ContainsValue($true))


    'Reboot required'




    'No reboot required'


  45. Mark Phaedrus (WU) says:

    Without commenting on any other aspects of the code above, I will say that HKLMSOFTWAREMicrosoftWindowsCurrentVersionWindowsUpdateAutoUpdateRebootRequired is an undocumented registry item. Like other undocumented registry items, its behavior is subject to change without notice. (The keen observer of detail will notice that a number of Windows Update-related undocumented registry values vanished entirely, and others changed their functions, in Windows 10; so this is not merely a theoretical concern.) The correct, documented, supported way of determining whether Windows Update needs to reboot the computer is the ISystemInformation::RebootRequired API documented on MSDN.

  46. DWalker says:

    Interesting!  I thought it was possible in theory, but incredibly complex.  (I don't think I underestimated the complexity; it's huge.)  But per the later comments, it may be impossible in theory.  Thanks for the comments!

  47. @Darran: on my home machine, I have WU configured as you describe. It doesn’t seem to work. At work, we have group policy set to prevent the machines from rebooting automatically. That still seems to work, except that the user never seems to get any notification that the update is pending.

    If the notification is in the Action Center, that might explain it – I’ll check next time I visit the test machine. (It doesn’t solve the problem though, because Action Center notifications are too well hidden.)

  48. WinUser says:


    $PendingWindowsUpdate = (New-Object -ComObject Microsoft.Update.SystemInfo).RebootRequired


  49. “Set Automatic Updates so it does not install updates immediately. Either disable it, or set it to download updates without installing them.”

    With Windows 10, this is no longer possible.

Comments are closed.

Skip to main content