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:
- Version without this specific startup crash:
- Caveat on 0.8.119:
Reproduction
- Install Foundry Local CLI on Windows Arm64.
- Run:
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.
Summary
On a Windows Arm64 machine,
foundry server startconsistently 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
Reproduction
Actual behavior
The CLI prints:
Expected behavior
foundry server startshould start or connect to the daemon successfully and list available models instead of crashing during startup.Relevant logs
From
foundry server logsafter reproducing:Observations
foundry server start; no model download or inference is required.OrtEnv.CreateInstanceWithOptions).foundry server logsappears cumulative/append-only, which makes it harder to isolate the latest startup attempt during debugging.Possible areas to investigate
So Windows Arm64 appears to be an intended supported target in the 0.10.x preview line.