KB5001330 CU Windows 10 v2004 build 19041.928 and v20H2 19042.928 Win Update

RingTailCoon said:

And via the .MSI thingy in the main post?

No, I just did a repair install of Windows. Updated fine after that.

Try3 said:

Did anybody note the KB number for the SSU?

Denis

KB5001405

i486 said:

Well what do you know, the user account image placeholder is back on settings frontpage after this update!



Maybe they have different active hours set? Mine doesn't seem to ever proceed with the install automatically after download. I think it's default Windows behaviour starting from build 2004, maybe 1909, to wait for user input for a few days unless an opportunity opens outside of active hours. After that it will begin installing updates automatically.

You mean that it will install those updates automatically? Or it will install them automatically from then on?

rockfan13 said:

You mean that it will install those updates automatically? Or it will install them automatically from then on?

It will install just those updates that have already been downloaded and have been waiting for input. Only the most critical updates seem to download automatically. Microsoft keeps changing the update behaviour with every build.

Try3 said:

Not according to the CU's Release notes. See post #29 and the main article of this thread.

Denis

If you go to Events Log, you ll see that KB there.

Bo

Try3 said:

Not according to the CU's Release notes. See post #29 and the main article of this thread.

Denis

SSU KB4598481 is the last SSU required before you can install LCU KB5001330

SSU 19041.925 that include inside combined LCU KB5001330 is KB5001405
I got this KB from MDL

Bree said:

All installed without issues on my half-dozen machines. One I was particularly concerned about, as it had previously exhibited an obscure bug in OpenWith.exe (it hangs) when updated by the preview CU for 19042.906 and servicing stack 10.0.19041.903. The problem was detailed here....

Issue with OpenWith.exe freezed after you cancel file requester

One of my six machines exhibited the same bug as the OP described, and had to be reverted to a system image of 19042.867 to get rid of it. As I said in post #16 of that thread, 19042.928 and its servicing stack 10.0.19041.925 did not trigger the reappearance of the problem.

MS should really add a 'cancel' button for that, right now the only way to exit it is to interact with other windows, like left-clicking anywhere else but that window, or killing the task in task manager.