.NET 10 SDK ARM64: Illegal instruction (SIGILL) on Apple M4 with macOS Virtualization.Framework

[psjamesh]

Description

When building .NET 10 applications in Docker on Apple M4 hardware, the .NET 10 SDK (version 10.0.101) crashes with "Illegal instruction (core dumped)" on ARM64 images. The crash occurs intermittently during various .NET CLI operations including dotnet new, dotnet add package, and dotnet build.

Environment:

• Host: macOS (Sequoia) on Apple M4 Pro
• Virtualization: macOS Virtualization.Framework (VZ) via Colima
  • Colima config: vmType: vz, arch: aarch64, rosetta: false
• VM OS: Ubuntu 24.04.1 LTS (Noble Numbat)
• VM Architecture: aarch64 (native ARM64, not emulated)
• .NET SDK: 10.0.101
• Docker Image: mcr.microsoft.com/dotnet/sdk:10.0 (ARM64 variant, sha256:d1823fecac...)

Key Observations:

• ✅ Works perfectly when using --platform linux/amd64 (via Rosetta translation)
• ❌ Fails on native ARM64 (--platform linux/arm64)
• The bug is intermittent but consistently reproducible with --no-cache builds
• Multi-project solutions with references trigger it more reliably than single projects
• Exit code: 132 (SIGILL - Illegal Instruction)

Impact:
Cannot build .NET 10 applications natively on ARM64 in macOS VZ environment. Workaround is to build for AMD64 and rely on Rosetta, but this defeats the purpose of native ARM64 support.

Reproduction Steps

docker run --rm --platform linux/arm64 mcr.microsoft.com/dotnet/sdk:10.0 \
  sh -c 'dotnet new classlib -n Test'

The above fails intermittently but regularly, see sample output below:

> docker run --rm --platform linux/arm64 mcr.microsoft.com/dotnet/sdk:10.0 \
  sh -c 'dotnet new classlib -n Test'
The template "Class Library" was created successfully.

Processing post-creation actions...
Restoring /Test/Test.csproj:
  Determining projects to restore...
  Restored /Test/Test.csproj (in 30 ms).
Restore succeeded.


> docker run --rm --platform linux/arm64 mcr.microsoft.com/dotnet/sdk:10.0 \
  sh -c 'dotnet new classlib -n Test'
Illegal instruction (core dumped)
> docker run --rm --platform linux/arm64 mcr.microsoft.com/dotnet/sdk:10.0 \
  sh -c 'dotnet new classlib -n Test'
The template "Class Library" was created successfully.

Processing post-creation actions...
Restoring /Test/Test.csproj:
  Determining projects to restore...
  Restored /Test/Test.csproj (in 33 ms).
Restore succeeded.


> docker run --rm --platform linux/arm64 mcr.microsoft.com/dotnet/sdk:10.0 \
  sh -c 'dotnet new classlib -n Test'
Illegal instruction (core dumped)

Expected behavior

Build succeeds

Actual behavior

Build fails (intermittently)

Regression?

No response

Known Workarounds

Build an AMD64 image instead

Configuration

Using SDK 10.0

Other information

System Information

# Host CPU
$ sysctl machdep.cpu.brand_string
machdep.cpu.brand_string: Apple M4 Pro

# Docker/VM architecture
$ docker info | grep Architecture
Architecture: aarch64

# .NET SDK version in container
$ docker run --rm mcr.microsoft.com/dotnet/sdk:10.0 dotnet --version
10.0.101

# CPU features visible in container
$ docker run --rm mcr.microsoft.com/dotnet/sdk:10.0 cat /proc/cpuinfo | grep Features
Features: fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm jscvt fcma lrcpc dcpop sha3 asimddp sha512 asimdfhm dit uscat ilrcpc flagm sb paca pacg dcpodp sve2 flagm2 frint svei8mm svebf16 bf16 afp sme smei16i64 smef64f64 smei8i32 smef16f32 smeb16f32 smef32f32 sme2 smei16i32 smebi32i32

[dotnet-policy-service]

Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch
See info in area-owners.md if you want to be subscribed.

[majoer]

I had a very similar error when building an image with Podman, running dotnet build from inside the container on a Mac with M4.

I always saw one of two different errors. Which one i got seemed very random:

• error MSB6006: "csc.dll" exited with code 132.
• Illegal instruction

I dont know what the underlying problem is, but i found a workaround by making sure i create the Podman Machine with LibKrun instead of Apple HyperVisor:

[psjamesh]

For now I've resorted to using Colima with Rosetta locally which means I can build and run amd64 images instead. It does mean in Kubernetes we will also need to run on amd64 which is unfortunate as arm64 offers a cost-saving.

[janvorli]

I will try to repro it on my M1. @psjamesh or do you already know that it repros on M4 ony?

[janvorli]

It doesn't repro on my M1, so it seems it is likely M4 specific.

[janvorli]

@psjamesh I've asked a colleague to repro it on his devices using your repro steps - neither M2 nor M5 reproduced the problem in about 100 runs.

[psjamesh]

Thanks @janvorli, I hadn't checked M1, M2 or M5 so thanks for doing that.

[JulieLeeMSFT]

@janvorli, how is the test going?

[janvorli]

@JulieLeeMSFT As I've reported above, I was unable to repro it on anything I could find. If you could find a M4 device, it would be great.

[JulieLeeMSFT]

I thought a collegue with M4 was trying the repro.
@AndyAyersMS will try it on M4.