KB5001649 CU Windows 10 v2004 build 19041.870 and v20H2 19042.870

f14tomcat · 21 Mar 2021

Melchior said:

ok I am back from this update... no issues other then it got stuck at 15% during the shutdown/update process.. then rebooted stuck at 91% then finished..

no borked install so all is good as far as I can tell..

If your WINVER says 19042.870, you are good to go. It's in your Update History, also. Down in the Optionals at the bottom. And in the Uninstall list. Reliability History will log it. May be somewhere else, also. I'm certain if it is, it will be brought to my attention.

ddelo · 22 Mar 2021

It showed up last night in WU, updated today. NO issues so far.

KB5001649 CU Windows 10 v2004 build 19041.870 and v20H2 19042.870-19042.870.png

Purpleroses · 22 Mar 2021

I noticed that my windows 10 servicing stack update is still sitting at 19041.860 it did not change to Windows 10 servicing stack update - 19041.868 and 19042.868. I see this under view installed updates.

RingTailCoon · 22 Mar 2021

Purpleroses said:

I noticed that my windows 10 servicing stack update is still sitting at 19041.860 it did not change to Windows 10 servicing stack update - 19041.868 and 19042.868. I see this under view installed updates.

You are not the only one. .860 here.

Ghot · 22 Mar 2021

Purpleroses said:

I noticed that my windows 10 servicing stack update is still sitting at 19041.860 it did not change to Windows 10 servicing stack update - 19041.868 and 19042.868. I see this under view installed updates.

RingTailCoon said:

You are not the only one. .860 here.

SSU .860 was part of KB5000802

KB5000802 CU Windows 10 v2004 build 19041.867 and v20H2 19042.867

f14tomcat · 22 Mar 2021

That's not unusual for the Kernel and sub-components to be at a different level. Note the OS at 19042.870 and the DISM command at the base 19041.844.

KB5001649 CU Windows 10 v2004 build 19041.870 and v20H2 19042.870-2021-03-22_09h02_53.png

Bree · 22 Mar 2021

f14tomcat is correct. A new service stack is only released as needed, not every month, so the version may not match the current Windows build. The easiest way to see what version you have and when you got it is to look in the folder C:\Windows\servicing\Version

KB5001649 CU Windows 10 v2004 build 19041.870 and v20H2 19042.870-image.png

I got 10.0.19041.860 on 9th March, last Patch Tuesday.

Homer712 · 22 Mar 2021

OK, so my curiosity has now been sufficiently piqued. In the below, I understand the Windows version part, but what is it that the numbers on the folder tell me?

Bree · 22 Mar 2021

Homer712 said:

OK, so my curiosity has now been sufficiently piqued. In the below, I understand the Windows version part, but what is it that the numbers on the folder tell me?

It's telling you the build number of your servicing stack, and that you got it on 10th February. You have...

KB4601395 Servicing Stack Update for Windows 10 version 1909 - Feb. 9

...as you can tell from the file version numbers here: https://support.microsoft.com/help/4601395

...and that you are one release behind the latest one, 10.0.18362.1430

This update replaces the previously released update KB4601395.

https://support.microsoft.com/help/5000908

Your Windows build is also one month behind the latest....

KB5000808 Cumulative Update for Windows 10 v1909 18363.1440 - March 9

Anak · 23 Mar 2021

With the last few posts about SSU's and regards to @Homer712 my curiosity has now also been sufficiently piqued.

Ever since I've been using windows 10 I've seen the prerequisite for the most recent SSU (Servicing Stack Update) before installing updates and in the next paragraph I've also seen where the update will check for the most recent SSU and if not present the update will install one if needed, so;

Would I be correct in assuming that a user would not have to concern him/herself with SSU's unless they encounter the error, 0x800f0823?

Maybe you can call me lucky but I've always relied on the update checking for the most recent SSU and the update has always been successful.