.NET 11 requires x86-64-v2 and Arm64 LSE CPUs, previews runtime-native async

Microsoft has detailed what ships in the .NET 11 runtime, and the most consequential change is a raised floor for hardware: the runtime will no longer run on CPUs that lack instruction sets that have been standard for over a decade. According to the Microsoft Learn documentation, last updated for release candidate 2 and currently surfacing on the Hacker News front page, both the x86/x64 and Arm64 baselines have moved up, and the ReadyToRun (R2R) compilation targets have moved with them.

Higher CPU baselines on x86/x64

Across Apple, Linux and Windows platforms, the JIT and AOT minimum moves from x86-64-v1 to x86-64-v2. Where v1 guaranteed only CMOV, CX8, SSE and SSE2, v2 additionally guarantees CX16, POPCNT, SSE3, SSSE3, SSE4.1 and SSE4.2. Microsoft notes that Windows 11 already requires this level, as does every x86/x64 CPU officially supported on Windows 10, and that the last excluded chips went out of vendor support around 2013.

The ReadyToRun target moves further still, from x86-64-v2 to x86-64-v3 on Windows and Linux, layering on AVX, AVX2, BMI1, BMI2, F16C, FMA, LZCNT and MOVBE. Apple's R2R target stays where it was.

Arm64 splits by operating system

Arm64 changes differ per platform. Apple sees no change at all, keeping its M1 baseline. Linux keeps the armv8.0-a minimum, preserving support for devices such as Raspberry Pi boards that implement only the AdvSimd instruction set, but the R2R target now includes LSE, which Microsoft warns may require extra JIT work when an application launches. Windows raises its baseline to armv8.0-a plus LSE, something required by Windows 11 and by all Arm64 CPUs officially supported on Windows 10, and consistent with Arm's SBSA server architecture requirements. The Windows R2R target is set to armv8.2-a plus RCPC.

What happens on older machines

The consequence is blunt. Starting with .NET 11, the runtime fails to start on hardware below the new baselines and prints a message telling the user that the CPU is missing one or more baseline instruction sets. Even on supported hardware, applications using ReadyToRun assemblies may see extra startup overhead where the processor falls short of the R2R target and more code must be jitted instead.

Microsoft frames the motivation as maintenance burden: supporting very old silicon adds complexity to the codebase for hardware unlikely to still be in use, and it forces AOT compilation to aim at an older common baseline that can cap performance on modern devices.

Runtime Async moves into the runtime

The other headline feature is Runtime Async V2, a preview that shifts responsibility for async methods from the compiler to the runtime itself. Rather than the compiler emitting state-machine classes, the runtime tracks suspension and resumption directly.

The most visible payoff is in live stack traces. In Microsoft's example, an async call chain produces 13 frames with compiler-generated state machines, cluttered with infrastructure entries, versus 5 frames showing only the real methods under Runtime Async.

Developers opt in by setting a runtime-async feature flag in the project file, and net11.0 projects no longer need preview features enabled to use it. Notably, the .NET runtime libraries themselves are compiled with the feature on, with no compiler-generated state machines remaining, which Microsoft describes as broad functional and performance validation of the model. The team is inviting reports, positive or negative, on throughput and library size changes.

Two supporting changes ship alongside. Covariant overrides, where a derived method returns a generic Task in place of a base method's non-generic one, now work through a runtime-generated thunk that bridges the calling convention, with the same fix applying to NativeAOT. Separately, restrictions that prevented runtime-async methods from being inlined during crossgen2 compilation have been lifted. The environment variables that previously controlled the behavior are gone; opting out per project is now done by setting UseRuntimeAsync to false.

Why it matters

The hardware floor is the change most teams will feel. Anyone running .NET workloads on repurposed older servers, long-lived embedded x86 boxes or aging thin clients may find an in-place upgrade to .NET 11 simply fails to start. The affected silicon is, as Microsoft points out, roughly a decade past vendor support, but plenty of it still hums along in labs, factories and server closets. On the other side of the ledger, freeing the JIT and AOT pipelines from the v1 baseline lets generated code assume wider instruction sets by default, and the move of R2R targets to v3 should push vectorised code paths into more precompiled binaries. Runtime Async, meanwhile, signals the platform's long-term direction: if the experiment sticks, the stack-trace noise and debugging friction that have characterised C# async for a decade start to disappear.