KB5005033 Windows 10 2004 19041.1165, 20H2 19042.1165, 21H1 19043.1165 Win Update

babyblue · 13 Aug 2021

fdegrove said:

If you're familiar with using the registry editor ....

My BuildLab and BuildLabEX values are the same as yours. CurrentVersion is "6.3". However "ReleaseId" was "2009". Changing this to 21H1 fixes winver and settings--about, many thanks :)

I guess I may never know, but I'm curious as to how it changed to 2009 in the first place. Maybe a buggy out of band update? I'd be interested in any ideas anyone has. In the meantime many thanks to @fdegrove for the fix :)

EDIT: Googling "releaseid 2009" came up with some relevant info, eg the following reddit post:
BUG Windows 21H1 don't update ReleaseId key and appears as 2009 version

If ReleaseId is used for winver, but is being deprecated, I wonder how this will affect winver's output in future releases.

don1952 · 13 Aug 2021

babyblue said:

I guess I may never know, but I'm curious as to how it changed to 2009 in the first place. Maybe a buggy out of band update? I'd be interested in any ideas anyone has. In the meantime many thanks to @fdegrove for the fix :)
I would say it's been 2009 since the 20H2 update.
The only setting that changes is the "DisplayVersion"

EDIT: Googling "releaseid 2009" came up with some relevant info, eg the following reddit post:
BUG Windows 21H1 don't update ReleaseId key and appears as 2009 version
If ReleaseId is used for winver, but is being deprecated, I wonder how this will affect winver's output in future releases.

As it says "some IT Admins" use releaseID to check OS version - Winver does not.
Winver uses the DisplayVersion entry.
If you have an MS account check your device info in that, even my Win11 PC's show 2009 as the version, so even some parts of MS are behind the times.

babyblue · 13 Aug 2021

@don1952 Changing ReleaseId fixed my "2009" issue (see previous pages), so for some reason on my pc at least, winver is getting its info from ReleaseId. Also if I change releaseid to something silly like "Beta" it still shows up in winver:

KB5005033 Windows 10 2004 19041.1165, 20H2 19042.1165, 21H1 19043.1165-2021-08-13-14_43_21-about-windows.png

EDIT: Looking at some other posts, it looks like winver using DisplayVersion is the expected behavior. So maybe my issue isn't that ReleaseId somehow got changed, but that winver has somehow reverted to older behavior. Here are the details of my winver.exe file:

Code:

 Directory of C:\Windows\System32

07/12/2019  10:09            59,392 winver.exe

don1952 · 13 Aug 2021

What does "DisplayVersion" show in the same registry key section (HLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion??
This is a section of my current 19043.1165

KB5005033 Windows 10 2004 19041.1165, 20H2 19042.1165, 21H1 19043.1165-capture.png

KB5005033 Windows 10 2004 19041.1165, 20H2 19042.1165, 21H1 19043.1165-capture1.png

babyblue · 13 Aug 2021

don1952 said:

What does "DisplayVersion" show in the same registry key section (HLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion??

Mine says 21H1, but if i change it, it has no effect on winver. I added a note to my previous post as I think my winver might be misbehaving.

don1952 · 13 Aug 2021

Just to confirm, I have 4 pc's/laptops on Current Branch (19043.1165) plus 2 others on Insider Dev and Beta channels.

All show ReleaseID as 2009 but DisplayVersion shows 21H1 or 21H2 as expected.
In my MS Account all devices show as version 2009 and Win10 pro or Win 10 Home

As a test, changing releaseID to something other than 2009 makes no difference to Winver.

ddelo · 13 Aug 2021

A little PS script, for providing OS information, similar to 'About your PC' and 'winver'.

Get-OS.ps1

Code:

$OS = Get-ItemProperty "Registry::\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion"
$InstallationDate = ([datetime]'1970-01-01 00:00:00').AddSeconds($OS.InstallDate)
$XP =  (Get-AppxPackage -Name MicrosoftWindows.Client.CBS).Version

Write-Host
Write-Host "Edition".PadRight(15)$OS.ProductName
Write-Host "Version".PadRight(15)$OS.DisplayVersion
Write-Host "Release".PadRight(15)$OS.ReleaseId
Write-Host "Installed on".PadRight(15)$InstallationDate.ToString("dd/MM/yyyy")
Write-Host "OS Build".PadRight(15)$($OS.CurrentBuildNumber +'.'+$OS.UBR)
Write-Host "Experience".PadRight(15)"Windows Feature Experience Pack"$XP
Write-Host

You will get an output similar to the one below:

KB5005033 Windows 10 2004 19041.1165, 20H2 19042.1165, 21H1 19043.1165-get-os.png

Motorfingers · 13 Aug 2021

KB5005033 fails repeatably, stalling on reboot with black screen with "Making changes 100%" that never changes. Rebooting gets the light blue screen and the uninstallation of KB5005033. I've tried renaming the WU files/directory, downloading and installing KB5005033 locally twice, updating my video driver (NVIDIA Geforce 660), etc. My system drive has a 529 MB system recovery partition that Disk Manager says is 100% free, as is reported for the 100 MB UEFI partition. The remaining 1862.39 GB NTFS partition is 50% available.

The first time KB5005033 failed, an on-motherboard USB 3 controller failed to restart, dropping my two 4 TB RAIDs offline. Powering down and rebooting fixed that. SFE and DISM don't find a problem. Error is usually 0x800f0922 but once got an error that indicated WU files were corrupted, and fixed that.

Anyone with suggestions on how I can get 0x800f0922 to take?

EDIT 08/13/21: I manually updated from 21H1 to 21H2 using the jar file named in KB5005033, linked from the Microsoft article on KB5003791. It adds very little, principally WPA3 H2E standard, hooks to use GPU processing from WSL and a business deployment/connectivity/logon improvement, none of which apply to my home Windows workstation. In the hopes that either the WU file or my system was different and would avoid the 0x800f0922, I re-enabled WU. It now declared the update as updating from 21H2, and it ran without a glitch. Nothing else was changed between a failure and a success, so getting WU KB5005033 worked for me from 21H2.

babyblue · 14 Aug 2021

don1952 said:

Just to confirm...

I managed to solve the issue. Some while back I had followed the advice from Sumit's 3rd post on:

How to make Start Menu black with blue tiles_apps LIKE IT WAS - Microsoft Community

by deleting a registry key (with 3 sub-keys). Other side-effects are "This PC" properties takes you to the control panel version, and winver gives ReleaseId as version. Restoring the keys undoes this behavior.

Hopefully this is helpful for anyone with the samed issue, or who (like me) wants some of the older behaviors restored.
Many thanks to everyone here for their help and advice in trying to solve this :)

Leo123 · 15 Aug 2021

Motorfingers said:

KB5005033 fails repeatably, stalling on reboot with black screen with "Making changes 100%" that never changes. Rebooting gets the light blue screen and the uninstallation of KB5005033. I've tried renaming the WU files/directory, downloading and installing KB5005033 locally twice, updating my video driver (NVIDIA Geforce 660), etc. My system drive has a 529 MB system recovery partition that Disk Manager says is 100% free, as is reported for the 100 MB UEFI partition. The remaining 1862.39 GB NTFS partition is 50% available.

The first time KB5005033 failed, an on-motherboard USB 3 controller failed to restart, dropping my two 4 TB RAIDs offline. Powering down and rebooting fixed that. SFE and DISM don't find a problem. Error is usually 0x800f0922 but once got an error that indicated WU files were corrupted, and fixed that.

Anyone with suggestions on how I can get 0x800f0922 to take?

EDIT 08/13/21: I manually updated from 21H1 to 21H2 using the jar file named in KB5005033, linked from the Microsoft article on KB5003791. It adds very little, principally WPA3 H2E standard, hooks to use GPU processing from WSL and a business deployment/connectivity/logon improvement, none of which apply to my home Windows workstation. In the hopes that either the WU file or my system was different and would avoid the 0x800f0922, I re-enabled WU. It now declared the update as updating from 21H2, and it ran without a glitch. Nothing else was changed between a failure and a success, so getting WU KB5005033 worked for me from 21H2.

could you please post a link to the article AND to the KB5005033 update?

did you also update the KB5003791?

thanks