If you read the thread, this is a "Microsoft App" issue. The core OS remains functional. You can still play games, surf the Web, and run 3rd party software. Very embarrassing for MS, and it tracks with their ready, fire, aim QA process.
I think the current QA process is a deliberate outcome. If you invest drastically less in testing and mark some hardware configs as unsupported, eventually these hardware configs break.
Like with anything, lack of care leads to degradation. The core functions remain for a while, but without support it's clear where this leads. Microsoft has no reason to be embarrassed or surprised, they chose the circumstances that made this happen!
That's it. Was hoping I could ride out staying on Windows 10 until it support was cut off. Enough is enough, I'm wiping Windows tonight and only single booting Ubuntu. Steam library be damned, whatever works on Proton works on Proton. I'm buying a Steam Deck.
It's the principle and this isn't the first thing that pissed me off. Microsoft will break your PC with a software update and they do not give a single damn - "just buy a new PC". How about f*ck you?! Why should I give my business to a company that so clearly has disdain for their customers.
tl;dr is that an SSE4.2 instruction was introduced into an optional but commonly used runtime library that ships with the Visual C++ compiler. There's no runtime checking for whether the CPU supports this instruction, so it crashes on older CPUs.
No one tests their apps on declared unsupported hardware. How would you identify potential unsupported-but-might-work hardware? It's not worth the cost.
Still, it sounds like someone simply screwed up a compiler setting.
> Still, it sounds like someone simply screwed up a compiler setting.
A screw up would imply they hadn't intended to make the change. It could just have easily been someone trying to improve performance or security by optimizing for supported platforms while not knowing that a lot of unsupported platforms would run the code or be impacted.
If the change doesn't negatively impact stated supported platforms then it wasn't a mistake imo and I don't think they should revert it.
A lot of security issues exist because we continue to support legacy systems that cannot be secured or not without negatively impacting performance. If MS pushed a security patch that gobbled 5-10% performance from decade old systems some people would lose their minds.
Remember how painful the switch from XP was? And from Win7? And now Win10? Some people just refuse to upgrade hardware or software until forced and will bitch piss and moan the entire time.
Calling these processors unsupported for Windows 10 is dubious. The official minimum CPU specification for Windows 10 only mentions PAX, NX, SSE2, CMPXCHG16B, LAHF/SAHF, and PREFETCHW, not SSE4:
https://learn.microsoft.com/en-us/windows-hardware/design/mi...
However, this is not surfaced to the user nor are there compatibility blocks to prevent auto-upgrades to newer builds, and the page specifically says this:
> Changes to the processors listed do not indicate or impact a customer’s existing Windows support and are intended for OEMs to determine processors which may be used in new Windows devices.
If Microsoft wants to raise the minspec to maintain a reasonable support window, more power to them. I can't see how apps suddenly crashing is a good way to do this. It has to be an unintentional bug.
on one hand - it's not really windows 10 related, these are windows store apps (even though preinstalled), and core 2 duos are 18 year old at this point
but it's true that maybe the store should start blocking old systems from updating such apps instead
I recall that Microsoft periodically drops support for versions of Windows 10 AND drops support for hardware with newer versions. It looks like Windows 10, version 1909, which fell out of support in 2021, only supports Nehalem (2008) or newer CPUs. I didn't dig further back to see when support for Core 2 Duos was dropped but this makes me wonder what version of Windows 10 these folks are running.
Are they running 22H2 on unsupported hardware, or 1909 which just isn't supported. If it's the later case and old versions like 1909 aren't supported, shouldn't they just be excluded from these Windows Store releases entirely?
Is this just a matter of someone not specifying the correct OS version to target in the Store deployment?
Is there any chance someone at Microsoft is going to insert a CPU compatibility check before bug-patch-Tuesday force installs these on millions of machines? WindowsReport.com cautions about KB5034203 on older CPUS and I have some older machines currently showing "Optional quality update available 2024-01 Cumulative Update Preview for Windows 10 Version 22H2 for x86-based Systems (KB5034203)" I wouldn't be surprised if those are no longer optional come Tuesday.
21 comments
[ 0.17 ms ] story [ 59.9 ms ] threadNo runtime detection, no software trapping/emulation. Hard crash for very old hardware.
Like with anything, lack of care leads to degradation. The core functions remain for a while, but without support it's clear where this leads. Microsoft has no reason to be embarrassed or surprised, they chose the circumstances that made this happen!
That's it. Was hoping I could ride out staying on Windows 10 until it support was cut off. Enough is enough, I'm wiping Windows tonight and only single booting Ubuntu. Steam library be damned, whatever works on Proton works on Proton. I'm buying a Steam Deck.
tl;dr is that an SSE4.2 instruction was introduced into an optional but commonly used runtime library that ships with the Visual C++ compiler. There's no runtime checking for whether the CPU supports this instruction, so it crashes on older CPUs.
Still, it sounds like someone simply screwed up a compiler setting.
A screw up would imply they hadn't intended to make the change. It could just have easily been someone trying to improve performance or security by optimizing for supported platforms while not knowing that a lot of unsupported platforms would run the code or be impacted.
If the change doesn't negatively impact stated supported platforms then it wasn't a mistake imo and I don't think they should revert it.
A lot of security issues exist because we continue to support legacy systems that cannot be secured or not without negatively impacting performance. If MS pushed a security patch that gobbled 5-10% performance from decade old systems some people would lose their minds.
Remember how painful the switch from XP was? And from Win7? And now Win10? Some people just refuse to upgrade hardware or software until forced and will bitch piss and moan the entire time.
There is a more general Windows Processor Requirements doc that does drop a number of old CPUs off of the list for newer builds: https://learn.microsoft.com/en-us/windows-hardware/design/mi...
However, this is not surfaced to the user nor are there compatibility blocks to prevent auto-upgrades to newer builds, and the page specifically says this:
> Changes to the processors listed do not indicate or impact a customer’s existing Windows support and are intended for OEMs to determine processors which may be used in new Windows devices.
If Microsoft wants to raise the minspec to maintain a reasonable support window, more power to them. I can't see how apps suddenly crashing is a good way to do this. It has to be an unintentional bug.
but it's true that maybe the store should start blocking old systems from updating such apps instead
I recall that Microsoft periodically drops support for versions of Windows 10 AND drops support for hardware with newer versions. It looks like Windows 10, version 1909, which fell out of support in 2021, only supports Nehalem (2008) or newer CPUs. I didn't dig further back to see when support for Core 2 Duos was dropped but this makes me wonder what version of Windows 10 these folks are running.
Are they running 22H2 on unsupported hardware, or 1909 which just isn't supported. If it's the later case and old versions like 1909 aren't supported, shouldn't they just be excluded from these Windows Store releases entirely?
Is this just a matter of someone not specifying the correct OS version to target in the Store deployment?