Windows Arm64: daemon crashes during ONNX Runtime initialization on 0.10.0-0.10.2

Summary

On a Windows Arm64 machine, foundry server start consistently fails on Foundry Local CLI versions 0.10.0, 0.10.1, and 0.10.2 because the daemon exits during startup.

The issue does not reproduce on 0.8.119 on the same machine, which suggests the startup crash was introduced sometime between 0.8.119 and 0.10.0. However, 0.8.119 hits #752 so it does not retrieve any models.

Environment

• Platform: Windows Arm64
• OS version: 26100.8875
• Shell: PowerShell
• Affected versions:
  • 0.10.0
  • 0.10.1
  • 0.10.2
• Version without this specific startup crash:
  • 0.8.119
• Caveat on 0.8.119:
  • model retrieval does not work due to #752

Reproduction

1. Install Foundry Local CLI on Windows Arm64.
2. Run:

   foundry server start
   

Actual behavior

The CLI prints:

■ Starting Foundry Local server
● error: Daemon closed the connection mid-stream for op 'daemon.startup.subscribe'.
Hint: Run 'foundry server status' to inspect, or 'foundry server logs' for details.

Expected behavior

foundry server start should start or connect to the daemon successfully and list available models instead of crashing during startup.

Relevant logs

From foundry server logs after reproducing:

── daemon ── foundrylocald-2026-07-20.log ──
   at Microsoft.AI.Foundry.Local.FoundryLocalCore..ctor(Configuration, Action`1) + 0xac4
   at Microsoft.AI.Foundry.Local.FoundryLocalCore.<InitializeAsync>d__27.MoveNext() + 0x1d0
--- End of stack trace from previous location ---
   at Microsoft.AI.Foundry.Local.NativeInterop.<ExecuteCommandManaged>d__10.MoveNext() + 0x698
   at Microsoft.AI.Foundry.Local.Detail.CoreInterop..ctor(Configuration, ILogger) + 0x158
   at Microsoft.AI.Foundry.Local.FoundryLocalManager.<InitializeAsync>d__34.MoveNext() + 0x220
--- End of stack trace from previous location ---
   at Microsoft.AI.Foundry.Local.FoundryLocalManager.<CreateAsync>d__24.MoveNext() + 0x42c
--- End of stack trace from previous location ---
   at Foundry.Daemon.Sdk.FoundryManagerFactory.<InitializeAsync>d__11.MoveNext() + 0x1ec
--- End of stack trace from previous location ---
   at Foundry.Daemon.Sdk.SdkBootstrap.<CreateAsync>d__5.MoveNext() + 0x64
--- End of stack trace from previous location ---
   at Foundry.Daemon.Lifecycle.DaemonStartup.<RunAsync>d__9.MoveNext() + 0x780
2026-07-20T21:03:22.095Z [INF] Foundry.Daemon.Ipc.IpcServer: IPC server stopping (drain timeout 00:00:02).

── sdk (native) ── foundry.core20260720.log ──
   at Microsoft.ML.OnnxRuntime.OrtEnv.CreateInstanceWithOptions(EnvironmentCreationOptions&)
   at Microsoft.Neutron.OpenAI.OrtEnvHelper..ctor(String, ILogger`1)
   at Microsoft.AI.Foundry.Local.FoundryLocalCore.<>c.<.ctor>b__31_2(IServiceProvider provider) + 0x3c
   ...
   at Microsoft.AI.Foundry.Local.FoundryLocalCore..ctor(Configuration, Action`1) + 0xac4
   at Microsoft.AI.Foundry.Local.FoundryLocalCore.<InitializeAsync>d__27.MoveNext() + 0x1d0
--- End of stack trace from previous location ---
   at Microsoft.AI.Foundry.Local.NativeInterop.<ExecuteCommandManaged>d__10.MoveNext() + 0x698

Observations

• The crash is triggered by a simple foundry server start; no model download or inference is required.
• The daemon appears to exit during ONNX Runtime environment initialization (OrtEnv.CreateInstanceWithOptions).
• This points to a startup/runtime issue rather than a problem in the CLI command itself.
• Because 0.8.119 does not show this startup crash on the same machine, this appears to be a regression introduced after 0.8.119.
• foundry server logs appears cumulative/append-only, which makes it harder to isolate the latest startup attempt during debugging.

Possible areas to investigate

• Windows Arm64 native runtime packaging/dependency loading for ONNX Runtime / GenAI
• Version mismatch between Foundry Local core and bundled ONNX Runtime components on win-arm64
• WinML vs non-WinML Windows Arm64 packaging differences in 0.10.x
• Daemon startup path changes introduced after 0.8.119
• Any ONNX Runtime environment initialization changes between 0.8.119 and 0.10.0

So Windows Arm64 appears to be an intended supported target in the 0.10.x preview line.

Reproduce with foundry server start on Windows Arm64, then inspect foundry server logs, focusing on daemon startup and OrtEnv.CreateInstanceWithOptions in the ONNX Runtime initialization path. Compare the 0.10.x behavior with 0.8.119 and isolate the regression in native runtime packaging or startup initialization. Done means the daemon starts successfully and lists available models on the affected platform.