Just yesterday, I was catching up over at ElevenForum.com, and read a thread entitled “Winget errors…” It talked about issues accessing the WinGet source error. It reads "Failed in attempting to update the source: winget." I’ve seen this before myself. It occurs mostly when issues involved with accessing the MS WinGet servers come up. Then it happened to me soon thereafter, for updates and for an attempted export/import operation. This kind of WinGet chaos presages changes, as it shows a shakier Internet infrastructure than normal. Let me explain…

WinGet Chaos Presages Changes in Server Access/Reliability

In working with any cloud based service — including WinGet — the presumption is that the service is “always available.” Bad things, or nothing, happens when it’s unavailable. Ditto for issues when attempting to access the Internet infrastructure and cloud that leads to said service. Things don’t work like they’re supposed to — that’s where the “Chaos” part comes in — until the service returns to normal, expected behavior.

Recently, I’ve seen reports of outages or DNS attacks that have taken AWS, Google, Microsoft and others offline. Sometimes it’s just minutes, sometimes it’s hours; rarely, it’s half a day or longer. But chaos follows in the wake of such outages when things stop working, or don’t work as they should. Perhaps the strangest recent manifestion occurred when Internet-connected beds (human sleeping platforms) got wonky during an AWS outage.

Closer to my desk, yesterday’s WinGet weirdnesses reflect the same chaos that ensues when expected information sources and handling in the cloud go away. It seems to be happening more often. I’m inclined to look for ways to fall back on local information rather than simply failing when cloud information isn’t available.

In small things, and small ways, little bits of Chaos remain unavoiodable. Chaos is seldom desirable, especially in big doses. Let’s hope the wizards who make Windows-World such a big thing feel the same way, and help us work toward failover or workarounds to keep the Chaos at bay.

Note Added 4+ Hours Later: Azure Outage

As I’m reading Windows related news this afternoon, I see ample coverage of a major Azure outage yesterday afternoon. For example, Neowin  Microsoft Azure hit by massive outage… Whaddya bet the WinGet stuff falls under that umbrella. Seems to be working fine today, though.

It’s interesting and perhaps a bit puzzling. For “compatibility reasons” — some having to do with browsing the Web — Windows 11 has long reported itself as a kind of Windows 10. Indeed, one must examine Build numbers, mostly, to figure out which version of Windows is really driving the bus. To see this enduring Windows 10 hangover try this string in PowerShell:

[System.Environment]::OSVersion.Version

You can, of course, get the real skinny by running winver.exe, or a more nuanced Get-ItemProperty command in PowerShell:

Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion" | Select-Object DisplayVersion, EditionID, CurrentBuild

You can see the results of these two commands in this blog post’s lead-in graphic. It still shows my production Windows 11 PC (Build 26200) with a Major version number of “10,” while the Get-ItemProperly output shows the “real deal” on this machine.

Will Enduring Windows 10 Hangover Get Fixed?

Now that Windows 10 is past its End of Service date, will MS fix this strange reporting practice? Probably not. There are reasons upon reasons why this reporting quirk is likely to remain unaltered.

The whole compatibility thing is HUGE: lots of driver models, apps and applications, and enterprise tools assume that Windows 10 is the end-all and be-all for modern Windows versions. Indeed, it’s much, much more than a browser user-agent assumption. According to Copilot, “enterprise environments rely on registry keys such as ProductName and ReleaseId for automation,” so “those keys are often left untouched in Insider Builds to avoid disrupting telemetry and deployment pipelines.”

Hence the following, also from PowerShell using this command sequence:

Get-ComputerInfo | Select-Object WindowsProductName, WindowsVersion, OsBuildNumber

Notice that my Production Win11 system reports in this command as Windows 10 Pro, version 2009, with correct build number.

At least, I now know why this apparent misreporting occurs, and understand that it’s for good cause. Here in Windows-World there are plenty of apparent mysteries whose simple explanations lie in the many twists and turns in Windows history. This is one of those, I reckon.