[NETSDKE2E][ARM64].net9preview4sdk can't be used on ARM64OS.

[v-ainigao]

Build:
9.0.100-preview.4.24253.11

Repro steps:
1.Install .net9 preview4 SDK on arm64.
2.run dotnet --info on CLI.

Expected Result:
dotnet --info can be displayed normally and the project can be created without any problems.

Actual Result:
dotnet --info is not fully loaded and the project can't build and run.

[v-ainigao]

This memory dump file has been placed in this path. \mlangfs1\public\v-aini\arm64dump.zip

[v-ainigao]

Installing some workloads can be successful.
dotnet workload install maui --skip-manifest-update

dotnet workload install wasm-tools

But the dotnet workload list will also get stuck.

[v-ainigao]

This issue also repro's on arm64OS with .net9preview5SDK(9.0.100-preview.5.24256.12) installed.

The project can be created successfully, but it does not jump to the next line.

However, it took a long time and the build is still in progress

@richaverma1 Hi richa, can you help me take a look?

[LoopedBard3]

Hello, my team is also seeing this hang after ".Net workloads installed:" is printed when running dotnet --info on our windows arm64 machines. The latest failure we have seen has been with .NET SDK version: 9.0.100-preview.5.24257.6 with the last working version being 9.0.100-preview.4.24215.2. We are seeing this hang specifically on Windows ARM64 devices, or Linux ARM64 devices are still running as expected.

[LoopedBard3]

@ViktorHofer, do you happen to know the correct person/group to cc for this? I suspect it to be under the area src/CLI, but am having trouble figuring out which group to choose based on the CODEOWNERS file. Thanks!

[mangod9]

we are trying to investigate. @LoopedBard3, are you able to get things work after setting DOTNET_LegacyExceptionHandling=1 ?

[LoopedBard3]

Yes, that seems to fix the issue.

[mangod9]

ok good to know, believe there has been a fix recently for it: #101971

[Forgind]

@mangod9,
Should this be moved over the runtime repo then?

[mangod9]

yeah moved over now.

[mangod9]

We have made a temporary fix to disable new EH on win arm64 in Main and Preview4. @LoopedBard3 , could you please check that the latest build from Main resolves the issue for you? Thanks

[v-ainigao]

This issue still repro's in the latest net9preview4sdk.
SDK version:9.0.100-preview.4.24258.4(runtime-9.0.0-preview.4.24252.19)

[mangod9]

Looks like the fix is in runtime-9.0.0-preview.4.24260.3, which has this commit: #102060.

[Zheng-Li01]

Yes, the fixed worked in the 9.0.0-preview.4.24260.3 build on Arm machine.

[mangod9]

Ok great, thanks for confirming. We will keep the issue open till a permanent fix is done.

[v-ainigao]

Ok great, thanks for confirming. We will keep the issue open till a permanent fix is done.

This issue has been fixed in ARM64OS.

But x64sdk crashes on arm64OS still repro.
Related bugs: #100425 (comment)

[LoopedBard3]

We have made a temporary fix to disable new EH on win arm64 in Main and Preview4. @LoopedBard3 , could you please check that the latest build from Main resolves the issue for you? Thanks

@mangod9 We are still seeing this hang without the envvar. The version tested was .NET SDK version 9.0.100-preview.5.24262.2 (latest daily on channel 9.0).

[mangod9]

Is this native arm64 or are you running x64 ?

[LoopedBard3]

Do you mean the machine or the binaries? The machine is native arm64. If binaries, is there a good way to verify which is being used? It should be arm64 as I used -Architecture arm64 and the zip files end with win-arm64.zip.

[v-ainigao]

This problem still recurs on the latest net9preview5.
SDK version:9.0.100-preview.5.24262.2(runtime-9.0.0-preview.5.24256.1)
dotnet --info

dotnet new console

[LoopedBard3]

@mangod9 do you know if this is likely to be resolved for the preview 5 sdk in the short term? (This week). I am trying to determine if it is worth it to use the legacy EH envvar workaround to get some perf runs this week or if this will be fixed shortly so we can do backfill testing. Thanks!

[mangod9]

The workaround should already be in place, I am guessing the SDK build you were trying has not picked up the latest runtime bits. Also a permanent fix should be checked in today too.

[v-ainigao]

Today we are still seeing this hang. The version tested was .NET SDK version 9.0.100-preview.5.24265.9 (latest daily on channel 9.0).

[LoopedBard3]

It seems the PR flow to update the runtime pulled down with the latest SDK version has been stuck for a bit, dotnet/installer#19711, which is likely why the latest 9.0 daily is still not seeing the runtime workaround or fix taking affect. This means the runtime will also need to be updated in the installer with the fix for it to show.

[LoopedBard3]

Our runs are succeeding again after the dotnet/installer#19711 PR went in, though not sure if the installer includes the full fix for this issue or if it is using the workaround still.

[v-ainigao]

This issue has been fixed in the .net9preview5SDK on ARM64OS.

[mangod9]

Great, closing it now.