Replies

Thanks for the clarification! I was under the impression that a CPU having ID 0xB0671 meant the microcode version would be one of 0x119 or 0x4119, but now I understand this is not the case.

The Intel processor identification utility reports that the “CPU Revision” in the CPUID DATA section is “10E”, so my system does not seem to have one of the affected microcodes. Looks like I don’t need to worry further about the updates for Windows throwing that unsupported CPU BSOD.

Of course it turns out my i5-13600KF has the problematic microcode version 0xB0671… As per my standard practice I never install preview updates, but am I right to assume that the risk of the “Unsupported CPU” BSOD will manifest when I install the regular September CU?

Unfortunately, I can’t think of any helpful suggestion tbh. Looks like something has gone “wrong” with your W10 installation, preventing the updates to successfully install. Assuming you have already tried also using the “Windows Update Health Tools” to see if it can find anything to fix, then if I were in your shoes I’d go for that fresh install and start anew (that is, entirely wipe the SSD and then re-install W10).

I don’t think age of the computer should matter/have anything to do with the problem you are having: a couple years ago I installed W10 on an even older machine than yours: a custom build with an i3-540 CPU running on Vista and that was even before I upgraded RAM from 4 GB to 8 GB and replaced the HDD with an SSD. Despite the computer’s age, W10 installed without problem, albeit I’ll admit that performance was not so good until I increased RAM to 8 GB and updated to an SSD. If the problem you are currently facing has anything to do with hardware, then a defective component might be a more likely explanation than simply the age of the hardware. Still, if the system behaves properly (except for the failure to install updates), i.e. no random errors/reboots/blue screes/weird stuff, it seems unlikely that hardware has anything to do with your problem at all.

Unless anyone else has better ideas, I’d wipe clean the disk, make a new partition and re-install W10 from scratch. Hopefully that will solve the problem for good.

1 user thanked author for this post.

Cybertooth

BTW, just wanted to add that after installing KB5029263 the behavior of the “Print Screen” button was changed to opening the Snipping Tool. Fixed that as soon as I realized that hitting Print Screen did not capture a screenshot as is my preference. So far I did not notice any further change to my settings.

Ok, just updated my Windows 11 Pro 22H2 machine with August updates through WUMgr and the system seems to be behaving correctly as far as I can tell.

Specifically, I installed these updates:
– KB5029263 = 2023-08 Windows 11 22H2 CU
– KB5029650 = 2023-08 .NET Framework CU
– KB890830 = Windows Malicious Software Removal Tool update
– KB5007651 = Update for Windows Security platform (ver 1.0.2306.10002)

No idea why the Windows Security platform update was deemed necessary for my machine, given that I use a different AV/Firewall provider, but went along with it and installed the update.

This month too I had two reboots before the updates finished installing:
– The first reboot was triggered manually by me after the updates were all reported as installed and the system restarted after installation of updates reached 21%;
– Installation of updates resumed shortly after the restart (oddly, it started from 7% rather than 21%) and continued until 30% at which point the second reboot was automatically triggered;
– Installation of updates resumed yet again starting from 30% and all the way up to 100%.

This is exactly the same thing that happened when installing the July updates, but until then the system rebooted only once after reaching the 30% installation point. Anyway, this seems to be a minor hiccup and nothing to worry about (but I thought to share this in case anyone sees the same thing happen).

1 user thanked author for this post.

Perq

[Berserker79]

Well, thankfully I only had one hard drive fail on me and it was many, many years ago, back when we had only mechanical HDDs, SATA didn’t exist yet and SSDs were more sci-fi than reality. I still remember the drive was a Fujitsu IDE drive (an early UDMA33 model and if that sounds unfamiliar to any of you it’s because that’s really old tech by now :)) with a weird 1.7 GB size. Lost everything on that drive back then, today I hope to avoid any kind of disastrous loss like that by creating regular backups should one my SSDs fail.

BTW, regarding “SSDs tend to not warn” about imminent failure, a while back I think it was Will Fastie who posted here about a little freeware tool called “ClearDiskInfo” that can read SMART data and allow a user to see with ease whether there is a risk of an imminent failure. While I guess there is no guarantee that the prediction may be accurate/reliable, it seems better than nothing and I always perform a check once in while to keep on eye on the health of my drives.

• This reply was modified 1 month, 4 weeks ago by Berserker79. Reason: Corrected typo, ooops :)

No idea why KB5028244 failed installation on one of your computers: the 0x8024402c seems to be pretty generic, maybe the download was corrupt and the patch failed to install for that reason. Anyway, like you said, it’s a preview update so no need to worry about it, since the general suggestion is not to install any preview updates.

KB5028937 is the “regular” July .NET Framework update, while KB5028412 is the preview update. Since KB5028412 includes anything in KB5028937, there is no need to install also KB5028937 on the Home Edition computer.

1 user thanked author for this post.

L95

Definitely a head scratcher… Since the July updates do not seem to patch any vulnerability which is being actively and widely exploited, waiting until the August updates will be approved for installation sounds relatively safe (especially if you do not feel like going through more steps of restoring from a backup). Occasionally I’ve had W10 patches failing to install on a given month only to install without trouble the next: hopefully the same will happen for you.

Did you try downloading and installing KB5028166 from the Microsoft Update Catalog rather than using WUMgr? If that causes the Error Code 0xc0000225 issue all over again, maybe you could give KB5028244 (July preview update) a try in the hope that whatever is causing that error has been fixed in the preview update. If all that fails to avoid the error, then I would pass on KB5028166/KB5028244 and see if the Cumulative update from August will install without problem. And if the problem persists with the August update, then I’m afraid a reinstallation of Windows 10 might be a proper solution.

The only thing that comes to mind in order to check your Windows 10 installation is good is to run the DISM and SFC tools (https://support.microsoft.com/en-us/topic/use-the-system-file-checker-tool-to-repair-missing-or-corrupted-system-files-79aa86cb-ca52-166a-92a3-966e85d4094e):
1) In an elevated command prompt enter the following command
DISM.exe /Online /Cleanup-image /Restorehealth
2) Wait for the operation to be completed, then enter the following command
sfc /scannow

These steps should help locate and fix corrupt Windows 10 files and hopefully take care of the problem you are having with KB5028166.

1 user thanked author for this post.

Perq

Ok, the July 11 updates successfully installed on my Windows 11 Pro 22H2 machine and everything appears to be in working order. Here too, I installed the updates through WUMgr, but the system did two reboots after installing the updates, contrary to what happened with Windows 10 where I had the usual single reboot.

The interesting bit is that on Windows 11 I was offered only the July CU and the MSRT update, no .NET Framework updates at all. Did I get it wrong or wasn’t the multiple reboot supposedly caused by the .NET Framework update? And yet, I had no multiple reboots on Windows 10 where I received a .NET Framework update and two reboots on Windows 11 where no .NET Framework update was installed.

Anyway, not a big deal. An additional reboot is not a problem compared to issues we had to deal with in the past due to other updates, so no reason to complain I guess.

This is to report a successful install of July patches on my Windows 10 Home 22H2 machine. Installing through WUMgr did not prompt multiple reboots, only one reboot was necessary after all patches were installed. BTW, I installed the monthly CU and .NET Framework updates from July 11 and hid both of the previews from July 25.

And now to update my Windows 11 Pro 22H2 machine…

Thanks for the clarification b. I don’t have experience with Office 2021 and did not know it is updated via Click-to-run updates rather than Windows Update. If those updates are always listed as “install” in the Master Patch list, is it correct to say that the answer to L95’s question (3) is that there is no need to disable updates for Office 2021?

1 user thanked author for this post.

L95

June updates installed successfully also on my Windows 11 Pro 22H2 machine.

2 users thanked author for this post.

MrToad28, geekdom

Installed without issue the June updates on my Windows 10 Home 22H2 PC. Still need to update the Windows 11 Pro 22H2 machine and will update this post once done.

2 users thanked author for this post.

MrToad28, jburk07

Just my two cents, until/unless someone of the more experienced users on the forum can provide better/more complete answers:

(1) My experience from when I was relying only on turning on the “Metered connection” setting to prevent updates is that WU will ignore that you are on a (supposedly) metered connection and still download certain updates. I can thus assume that KB5027215 and those .NET Framework updates are installed regardless that you have set your connection as metered. I seem to remember that also the periodical re-release of KB4023057 can bypass metered connections.

(2) Yes, if you want to avoid updates until you are ready to install them one solution is to use the “Pause Updates” method. However, keep in mind that when the pause period ends (or you hit the “Resume Updates” button), WU will download and install all pending updates, including those you might wish to avoid (if any).

(3) I don’t recall the approval for Office updates being on a different schedule than Windows updates. However, sometimes non-security updates for Office are released before the next Patch Tuesday and those are not included in the go-ahead to install updates from the previous Patch Tuesday. Also, I don’t have Office 2021, but assuming its updates work the same as Office 2013 updates, then you should not need to separately disable updates in Office 2021. I never had Office 2013 updates install behind my back with a metered connection and using “Pause Updates” also prevents Office 2013 updates. However, Office 2021 might be a different beast in this respect.

BTW, in case it is helpful, I stopped using metered connection and Pause Updates entirely and now I only use WUMgr to handle the updates process on both W10 and W11. I have set WUMgr to block automatic Windows Updates, which prevents any updates (except Defender updates) from downloading and installing automatically. When we have the go-ahead to install updates, I let WUMgr download and install only the updates I really wish to install and hide anything I do not want (e.g. KB4023057).

1 user thanked author for this post.

L95