You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Are you running against 8.0.3? For CPUs that do not support SSE4, .NET had a regression that made starting the runtime crash. The fix is coming in 8.0.4.
it is the same issue. 8.0.4 is being built with the msvc compiler that still has the issue, so we are disabling optimizations for the impacted methods. in 8.0.5 we should be using the fixed compilers and we will revert this change.
thanks for confirming that this is the same issue.
MSFT publishes a Supported Intel Processors list for each release, with Windows 10 1607's list being available here. Intel themselves maintain a similar document that explains Windows 10 support in terms of CPU microarchitecture families.
We had a user of our 8.0.3-equipped app run into this issue as they are attempting to run it on a Core2 Quad Q9300; a vintage of CPU model and microarchitecture that predates, by a reasonable measure, the oldest processors that are listed on the Supported Processors List. I see processors of similar era being mentioned by others in relation to this issue, and both our user's CPU model and the "Core2 Quad" quoted here, presumably of the Intel Penryn family, are explicitly called out as being not supported by Windows 10 in Intel's document.
While a patch-release regression ought to be fixed and indeed it seems that it will be, I think this situation raises a good question: How old of a system is too old to run a given major version of .NET? How should that be defined when taking into account CPU features that compilers might automatically optimize code paths for? From a pure documentation point of view, .NET 8 claims that Windows 10 1607 is the oldest supported OS. It is reasonable to assume that Windows 10 1607's own processor support list would effectively serve as a supported processor list of .NET 8 on Windows 10 (1607), with some corroboration being provided by Intel's document on the topic.
Some clarity to this question would be appreciated so that app developers can advise users with some certainty when it comes to the age of the platform they wish to run our app on. It also ought to provide reasonable guidance to .NET developers when it comes to which CPU features .NET must or must not rely upon, either directly though explicit use or implicitly through compiler optimizations, in order to avoid surprise regressions of the kind being dealt with here.
Excellent points @daleghent. This discussion comes up from time to time on what era CPU features should be our min bar. Our current stance continues to include CPUs that regressed with 8.0.3. In fact, this is a good (unintentional) reminder of what our customers continue to run on. As you mentioned, as Win10 support evolves we will reassess our minimal requirements. Though no changes right now.
Activity
jeffschwMSFT commentedon Mar 26, 2024
Are you running against 8.0.3? For CPUs that do not support SSE4, .NET had a regression that made starting the runtime crash. The fix is coming in 8.0.4.
#99926
Aerocatia commentedon Mar 26, 2024
I hit this on an old Core 2 Quad.
Is this not a compiler bug?, since it seems that it is intended to check for that instruction and use it if available. (see microsoft/terminal#16794)
Should that PR really be turning off optimization like that?
jeffschwMSFT commentedon Mar 26, 2024
it is the same issue. 8.0.4 is being built with the msvc compiler that still has the issue, so we are disabling optimizations for the impacted methods. in 8.0.5 we should be using the fixed compilers and we will revert this change.
thanks for confirming that this is the same issue.
daleghent commentedon Mar 28, 2024
This might be an opportunity to provide some clarity on .NET 8 supported processors. As of this writing, the oldest Windows version that is supported by .NET 8 is Windows 10 1607).
MSFT publishes a Supported Intel Processors list for each release, with Windows 10 1607's list being available here. Intel themselves maintain a similar document that explains Windows 10 support in terms of CPU microarchitecture families.
We had a user of our 8.0.3-equipped app run into this issue as they are attempting to run it on a Core2 Quad Q9300; a vintage of CPU model and microarchitecture that predates, by a reasonable measure, the oldest processors that are listed on the Supported Processors List. I see processors of similar era being mentioned by others in relation to this issue, and both our user's CPU model and the "Core2 Quad" quoted here, presumably of the Intel Penryn family, are explicitly called out as being not supported by Windows 10 in Intel's document.
While a patch-release regression ought to be fixed and indeed it seems that it will be, I think this situation raises a good question: How old of a system is too old to run a given major version of .NET? How should that be defined when taking into account CPU features that compilers might automatically optimize code paths for? From a pure documentation point of view, .NET 8 claims that Windows 10 1607 is the oldest supported OS. It is reasonable to assume that Windows 10 1607's own processor support list would effectively serve as a supported processor list of .NET 8 on Windows 10 (1607), with some corroboration being provided by Intel's document on the topic.
Some clarity to this question would be appreciated so that app developers can advise users with some certainty when it comes to the age of the platform they wish to run our app on. It also ought to provide reasonable guidance to .NET developers when it comes to which CPU features .NET must or must not rely upon, either directly though explicit use or implicitly through compiler optimizations, in order to avoid surprise regressions of the kind being dealt with here.
jeffschwMSFT commentedon Mar 28, 2024
Excellent points @daleghent. This discussion comes up from time to time on what era CPU features should be our min bar. Our current stance continues to include CPUs that regressed with 8.0.3. In fact, this is a good (unintentional) reminder of what our customers continue to run on. As you mentioned, as Win10 support evolves we will reassess our minimal requirements. Though no changes right now.
mangod9 commentedon Jun 28, 2024
The fix for the SSE2 regression has been included in 8.0.5.