|
There are isolated problems with current patches, but they are well-known and documented on this site. |
When Microsoft has issues with updates, it normally takes until Fridayish before they identify a root cause and then it’s Mondayish of the following w
[See the full post at: Various out of band updates out to fix January patch issues]
Susan Bradley Patch Lady
“Windows 11, version 21H1 (original release): KB5010795
Windows Server 2022: KB5010796
Windows 10, version 21H2: KB5010793
Windows 10, version 21H1: KB5010793
Windows 10, version 20H2, Windows Server, version 20H2: KB5010793
Windows 10, version 20H1, Windows Server, version 20H1: KB5010793
Windows 10, version 1909, Windows Server, version 1909: KB5010792
Windows 10, version 1607, Windows Server 2016: KB5010790
Windows 10, version 1507: KB5010789
Windows 7 SP1: KB5010798
Windows Server 2008 SP2: KB5010799”
I just got KB5009194 update to .NET 5.0.13
KB5010793 Cumulative Update for Windows 10 Version 21H2 for x64-based Systems
was waiting to be downloaded and installed when I signed in on the Windows 10 side of my dual boot daily driver.
No hiccups.
No you’ll have to manually import them.
Susan Bradley Patch Lady
Which patch?
Windows 10/11 patches (and related Server OS) are cumulative updates. Server 2012 R2 however is not. If you do the monthly rollup, later on this one (don’t reboot inbetween). When I raise the MS-DEFCON on 1/25 I’ll explain how to install updates on 2012 R2. If you HAVE to patch, you’ll need to do both the main patch for January -AND- this out of band on the 2012 R2 platform.
If you are patching any of the Windows 10ish era stuff (and later) they are cumulative so you only need to install the later patch.
Susan Bradley Patch Lady
Thank You Susan. I don’t plan to update Server 2012 R2 until you provide an all clear with instructions. Thank you for your reply. 🙂
Regarding Server2012R2 and the new Out of Band patch.
Once this KB5010794 fix (out of band patch) was released for Windows Server 2012R2 I waited a day or so to see if any reports of problems surfaced. Then I did the cumulative update KB5009624 for January, stopped the VMs, restarted the host but did not restart the VMs, then I did the OOB patch, restarted, and then restarted the VMs. ~12hours later it’s all working as it should. Phew!
Thanks to everyone, particularly Susan, for supplying relevant and timely information. I hope your experience is as good as mine was. (Note that I did not have the boot loop problem… Host was not a DC )
Basic research is what I am doing when I don't know what I am doing - Werner Von Braun
No for several reasons. Reason one the patches are not deemed new security releases and thus it’s just bug fixes. Reason two is that the underlying bug has been deemed “won’t fix” by Microsoft (see https://www.sentinelone.com/labs/relaying-potatoes-another-unexpected-privilege-escalation-vulnerability-in-windows-rpc-protocol/)
I’ll include my take in the next MS-DEFCON alert that goes out.
Susan Bradley Patch Lady
OoB WIN8.1 UPDATE:
kb5010794 is also available via WU (MSFT have now added it)
Checked WU on our Win8.1 Pro x64 earlier to find kb5010794
sitting in the ‘Optional’ section of WU.
As this device is already fully (everything) up-to-date, I downloaded and installed, instant restart required.
SFC scan all good, Event viewer no errors and system working good here.
NOTE: This is not my test device, it’s our Haswell system, imaged prior to January patchmess.
Update: no affects on this Haswell system 22/01/22
While managing a fully patched and fully functioning (as of Dec 31, 2021) Win8.1 Pro x64 system, after the January 2022 updates (KB5009624 monthly roll-up, KB5009721 .NET Framework roll-up) suddenly “something” got broken: pieces of software and core parts of the O.S. itself (e.g. Computer Management) began throwing an error complaining about the (now) missing ‘vcruntime140_1.dll’ library.
Rolling back to a previous backup image (as of Dec 31, 2021) restored the system stability (got the missing library back and everything else working normally, again). Can’t tell for sure if the culprit is either KB5009624, KB5009721 or an unexpected interaction between the two (haven’t had time to try uninstalling only one of them in turns, to be sure) but uninstalling both updates also worked (same as restoring back the system to the Dec 31, 2021 backup image).
I am guessing here that Redmond messed up (again) while packaging the updates and used the wrong versions of the Visual C++ Runtime libraries, because another option that also worked out well was to keep both updates (KB5009624 and KB5009721) installed and simply update the Visual C++ 2015 runtime libraries (as of Dec 31, 2021 that Win8.1 system had v14.0.24212 installed) to v14.30.30704, which were the latest available redistributable packages (signed October 5, 2021) here (“Visual Studio 2015, 2017, 2019, and 2022” section):
https://docs.microsoft.com/en-us/cpp/windows/latest-supported-vc-redist?view=msvc-170
For now I am not installing the optional KB5010794 update yet (I’ll just wait for the February updates) but I am assuming that this optional update will do exactly that (update the Visual C++ 2015 runtime libraries) because as I am writing this (Jan 20, 2022) the above webpage is now offering v14.30.30708 (signed January 6, 2022) of the Visual C++ 2015 runtime libraries… 😉
Just my 2 cents,
No, we have 14.0.24215 and 14.0.23026
@abbodi86, you’re absolutely right. Thank you!
Last week was a busy one and I didn’t pay enough attention… my bad. I went back to that system over this weekend to figure out what happened and the culprit seem to have been (might have been?) a hardware driver update (indeed, uninstalling KB5009624 and KB5009721 was not the same as restoring back the Dec 31, 2021 image: they were both installed on Jan 6, 2022 but that driver had been automatically installed on patch Tuesday [Jan 4, 2022] but went unnoticed and that’s probably what caused the unexpected interaction that lead to the missing runtime library situation).
Updating the C++ runtime libraries “fixed” the situation, yes, but the situation itself wasn’t caused neither by the KB5009624 or the KB5009721 roll-up updates. My bad, sorry.
I’m not seeing major issues for home users. Stay tuned for the alert/MS Defcon to change early next week.
Susan Bradley Patch Lady
I decided to try patching my 2012R2 test server this morning. It’s a Hyper-V guest, not host; domain-joined but not a DC.
This article says that OOB KB5010794 is only available on Windows Catalog:
My server, though, offered to install 0794 as an optional update at the same time it installed other January updates:
After checking the optional 0794 update, I clicked install now. It said it was downloading 4 updates of 81MB (it had already downloaded the other 3). Then it confirmed it was installing 3 updates (not 4):
After the reboot, it tells me KB5009624 was installed and that 0794 is still available:
Installing it fails immediately:
Rather than try to diagnose corrupt update stores etc., I just downloaded 0794 from the Windows Catalog and installed it without incident. After the reboot:
So, got the updates, survived a reboot without the OOB patch, but still nervous about doing this on a remote customer’s DC server.
“But what if you install 9624 but can’t get 0794 installed?”
You would need uninstall it in safe mode without networking or boot normally and stop the net logon service immediately after login and then uninstall. Some say the boot loop only happens if you have two domain controllers.
Note: I have not tested any of these procedures.
This is why I will probably just skip the January nonsense and wait for February updates.
Donations from Plus members keep this site going. You can identify the people who support AskWoody by the Plus badge on their avatars.
AskWoody Plus members not only get access to all of the contents of this site -- including Susan Bradley's frequently updated Patch Watch listing -- they also receive weekly AskWoody Plus Newsletters (formerly Windows Secrets Newsletter) and AskWoody Plus Alerts, emails when there are important breaking developments.
