Unusual behaviour after post-Windows Update reboot

6,804

Solution 1

This is by design. It's common for the OS to install updates before the reboot, and then after. You will see this screen when you have updates with huge files. The updates are queued up, then installed. We tend to see it more when installing Language Packs, Service Packs, large updates, etc. If your concern you can always check out the server event logs, and the windowsupdate.log. (C:\Windows\windowsupdate.log)

Solution 2

Happened to me also. Not a virus (thats what I thought too). Here's the explanation:

On occasion, when rebooting Windows, you might see a black scren, with a Windows logo in center, and white text below rapidly counting the application of thousands of "update operations," like this:

enter image description here Component-based servicing is a multi-step process, some steps of which you normally don't see:

  1. Download digitally-signed updates
  2. Verify signatures
  3. Unpack into a staging area
  4. Perform staging operation
  5. Begin reboot
  6. Validate correctness of staged updates
  7. Migrate staged updates into WinSxs and the registry
  8. Validate correctness of merge
  9. Finalize reboot
  10. Display logon screen

Step 4 is the pre-reboot "Do not interrupt or power down" message while you see a count from 0% to 100%. Step 7 is the post-reboot version. Ordinarily, there is no visible indication of steps 6 and 8. But if something causes the validation to fail, updates are re-staged. In this case, the validation steps become visible, and that's the image you see above. This does not mean Windows is applying thousands of updates. Instead, the batch of updates being installed contain thousands of distinct update operations, and you're experiencing the rare opportunity to witness a status message as each operation proceeds.

In the case of a major OS components like, say, the .NET framework, applying the update package requires processing possibly thousands of steps: each existing registry entry has to be read, modified, and validated. Each DLL has to be extracted, verfied, copied, and validated. Installing one update involves applying many many update operations.

Source: https://www.kubuntuforums.net/showthread.php?60550-Windows-quot-update-operations-quot-explained

Share:
6,804

Related videos on Youtube

Kev
Author by

Kev

###Actively looking for freelance work ###About Me: I'm a professional software developer and have spent my time building provisioning and web based self-service systems for IIS, Apache and Citrix XenServer, amongst other things. My Curriculum Vitae can be viewed on Stack Overflow Careers (might be a bit out of date). Stuff I like to listen to at last.fm You can get in touch here: kevin.e.kenny #@# gmail.com (you know what to do with the # and spaces). No Survey Emails Please. Also not ashamed to admit I like trains, mostly diesels, late Era 8 (BR Sectorisation) and Era 9 onwards :) I'm also interested in signalling if anyone from Network Rail is looking this far down ;)

Updated on September 18, 2022

Comments

  • Kev
    Kev almost 2 years

    One of our Windows 2008 R2 SP1 servers hung during a shutdown whilst performing a Windows Update - I elected to "Shutdown and apply updates" - which with hindsight may not have been an optimal choice.

    The server hung on the regular grey "Shutting Down Windows" screen, not the one where it tells you it's installing updates and not to pull the plug.

    I waited around an hour before deciding to force a reboot. When the server re-started it's now displaying a black screen with the following:

    Applying update operation nnnn of 16703 (\Registry\....)

    The value of nnnn is incrementing steadily and the value in the brackets has changed variously from system files to registry keys.

    Can anyone tell me what might have happened here to trigger this behaviour? I've never seen this before.

    I have googled around and found various solutions to errors that may occur during this process, but none of them explain why my server is doing this in the first place.

  • Kev
    Kev over 8 years
    Having done further reading of my own since I posted the question, that's a pretty good explanation. I've edited your answer so it's not "link only" which is frowned upon here.