Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fatal error!!!! #100264

Open
mammablue33 opened this issue Mar 22, 2024 · 5 comments
Open

Fatal error!!!! #100264

mammablue33 opened this issue Mar 22, 2024 · 5 comments
Labels
area-VM-coreclr untriaged New issue has not been triaged by the area owner

Comments

@mammablue33
Copy link

URL

https://dotnet.microsoft.com/en-us/learn/aspnet/blazor-cli-tutorial/install

Operating system

windows 10 home

More information about your system

windows os version 22H2 and the architecture x64

Description

i put in the command dotnet --version then push enter on the command prompt screen its says fatal error. Internal CLR error. (0x80131506)

dotnet --info

C:\WINDOWS\system32>dotnet --info
Fatal error. Internal CLR error. (0x80131506)

@mairaw mairaw transferred this issue from dotnet/website-feedback Mar 26, 2024
@dotnet-issue-labeler dotnet-issue-labeler bot added the needs-area-label An area label is needed to ensure this gets routed to the appropriate area owners label Mar 26, 2024
@dotnet-policy-service dotnet-policy-service bot added the untriaged New issue has not been triaged by the area owner label Mar 26, 2024
@jeffschwMSFT
Copy link
Member

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
Copy link

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
Copy link
Member

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
Copy link

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
Copy link
Member

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.

@am11 am11 removed the needs-area-label An area label is needed to ensure this gets routed to the appropriate area owners label Apr 2, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-VM-coreclr untriaged New issue has not been triaged by the area owner
Projects
None yet
Development

No branches or pull requests

5 participants