Problem
Title: QNNExecutionProvider registration fails on startup — duplicate EP name causes "Unknown EP bootstrapper name(s): ." on Snapdragon X Plus (arm64)
Environment:
Device: Samsung Galaxy Edge 4 (Snapdragon X Plus X1P42100, arm64)
Foundry Local version: Microsoft.FoundryLocal_0.10.3.0_arm64 (confirmed latest via winget upgrade --id Microsoft.FoundryLocal → no update available)
OS: Windows 11, DisplayVersion 25H2, Build 26200.9168 — stable channel, not Windows Insider (confirmed via Settings → Windows Update → Windows Insider Program; previously enrolled last year but not currently)
NPU driver: 30.0.219.1000 (exceeds documented minimum 30.0.140.0 for Snapdragon X Plus)
NPU device status in Device Manager: OK, class ComputeAccelerator, Snapdragon(R) X Plus - X1P42100 - Qualcomm(R) Hexagon(TM) NPU
Python: 3.12.10 (arm64), foundry-local-sdk (pip)
Summary:
QNN (NPU) execution provider registration fails on every daemon startup due to a duplicate QNNExecutionProvider entry in the internally-generated bootstrapper name list. This blocks all NPU-accelerated inference via the Foundry Local CLI/SDK, even though the NPU/QNN driver, hardware, and Windows build are all confirmed compliant and functional — the same device successfully runs NPU-accelerated inference through the Foundry Toolkit (AI Toolkit) VS Code extension's playground, ruling out driver, hardware, and OS-channel causes.
Steps to reproduce:
Fresh install / foundry cache remove (all models cleared) and foundry server restart.
Observe daemon log (foundry server logs) on every startup:
From Python SDK, confirm the duplicate via discover_eps():
download_and_register_eps(["QNNExecutionProvider"]) then fails:
foundry model list --device npu returns an empty table — no NPU variants surfaced; every model falls back to Device: CPU, EPs: CPUExecutionProvider.
foundry run qwen2.5-0.5b --device npu fails (exit code 1) for the same reason.
Expected behavior:
QNNExecutionProvider should appear once in discover_eps() / the daemon's internal bootstrapper list, register successfully, and NPU model variants should appear in foundry model list --device npu.
Actual behavior:
QNNExecutionProvider is listed twice; EP registration always fails with an empty/unmatched name in the error; the daemon permanently falls back to CPU-only inference on every restart.
Ruled out (all confirmed working):
❌ Not a Windows Insider issue — device is on stable Windows 11 25H2, previously left Insider program a year ago.
❌ Not a driver issue — QNN driver 30.0.219.1000 exceeds the documented minimum (30.0.140.0).
❌ Not a hardware/detection issue — NPU shows Status: OK in Device Manager under ComputeAccelerator class.
❌ Not a cache/state corruption issue — reproduced identically after foundry cache remove (full clear) and foundry server restart.
❌ Not a version issue — already on latest available Microsoft.FoundryLocal per winget upgrade --id Microsoft.FoundryLocal.
✅ Confirmed the NPU stack itself works: Foundry Toolkit (AI Toolkit VS Code extension) playground successfully shows NPU utilization (visible in Task Manager) running the same/similar models on this exact device.
Conclusion: The defect is isolated to the foundry-local daemon's AutoRegisterCertifiedEps / download_and_register_eps call, which passes QNNExecutionProvider twice in its self-generated request list, causing the EP name-matching logic to fail.
Workaround used: Running models on CPU (generic-cpu variants) via the foundry CLI/SDK, or using the Foundry Toolkit playground for actual NPU-accelerated inference.
Diagnostics
System
- OS: Microsoft Windows 10.0.26200
- Architecture: Arm64
- CPU: Snapdragon(R) X Plus - X1P42100 - Qualcomm(R) Oryon(TM) CPU (8 logical cores)
- GPU: Qualcomm(R) Adreno(TM) X1-45 GPU (128.0 MB)
- NPU: Qualcomm Technologies, Inc. Snapdragon(R) X Plus - X1P42100 - Qualcomm(R) Hexagon(TM) NPU
- RAM: 1.5 GB available / 15.6 GB total
- Disk: 52.6 GB free / 457.3 GB total (C:)
- .NET: .NET 9.0.18
Service
- State: Ready
- Web URLs: http://127.0.0.1:60994
- CLI version: 0.10.3
- Foundry Local Core: 1.0.0
- ORT: 1.26.0
- ORT GenAI: 0.0.0
Models
- Available variants: 44
- Loaded: 1
- Cached: 1
Connectivity
- Local service: Reachable
- Model registry: Reachable
Warnings
- Qualcomm Adreno GPU detected. If acceleration fails, try a CPU model variant or update the GPU driver.
Problem
Title: QNNExecutionProvider registration fails on startup — duplicate EP name causes "Unknown EP bootstrapper name(s): ." on Snapdragon X Plus (arm64)
Environment:
Device: Samsung Galaxy Edge 4 (Snapdragon X Plus X1P42100, arm64)
Foundry Local version: Microsoft.FoundryLocal_0.10.3.0_arm64 (confirmed latest via winget upgrade --id Microsoft.FoundryLocal → no update available)
OS: Windows 11, DisplayVersion 25H2, Build 26200.9168 — stable channel, not Windows Insider (confirmed via Settings → Windows Update → Windows Insider Program; previously enrolled last year but not currently)
NPU driver: 30.0.219.1000 (exceeds documented minimum 30.0.140.0 for Snapdragon X Plus)
NPU device status in Device Manager: OK, class ComputeAccelerator, Snapdragon(R) X Plus - X1P42100 - Qualcomm(R) Hexagon(TM) NPU
Python: 3.12.10 (arm64), foundry-local-sdk (pip)
Summary:
QNN (NPU) execution provider registration fails on every daemon startup due to a duplicate QNNExecutionProvider entry in the internally-generated bootstrapper name list. This blocks all NPU-accelerated inference via the Foundry Local CLI/SDK, even though the NPU/QNN driver, hardware, and Windows build are all confirmed compliant and functional — the same device successfully runs NPU-accelerated inference through the Foundry Toolkit (AI Toolkit) VS Code extension's playground, ruling out driver, hardware, and OS-channel causes.
Steps to reproduce:
Fresh install / foundry cache remove (all models cleared) and foundry server restart.
Observe daemon log (foundry server logs) on every startup:
From Python SDK, confirm the duplicate via discover_eps():
download_and_register_eps(["QNNExecutionProvider"]) then fails:
foundry model list --device npu returns an empty table — no NPU variants surfaced; every model falls back to Device: CPU, EPs: CPUExecutionProvider.
foundry run qwen2.5-0.5b --device npu fails (exit code 1) for the same reason.
Expected behavior:
QNNExecutionProvider should appear once in discover_eps() / the daemon's internal bootstrapper list, register successfully, and NPU model variants should appear in foundry model list --device npu.
Actual behavior:
QNNExecutionProvider is listed twice; EP registration always fails with an empty/unmatched name in the error; the daemon permanently falls back to CPU-only inference on every restart.
Ruled out (all confirmed working):
❌ Not a Windows Insider issue — device is on stable Windows 11 25H2, previously left Insider program a year ago.
❌ Not a driver issue — QNN driver 30.0.219.1000 exceeds the documented minimum (30.0.140.0).
❌ Not a hardware/detection issue — NPU shows Status: OK in Device Manager under ComputeAccelerator class.
❌ Not a cache/state corruption issue — reproduced identically after foundry cache remove (full clear) and foundry server restart.
❌ Not a version issue — already on latest available Microsoft.FoundryLocal per winget upgrade --id Microsoft.FoundryLocal.
✅ Confirmed the NPU stack itself works: Foundry Toolkit (AI Toolkit VS Code extension) playground successfully shows NPU utilization (visible in Task Manager) running the same/similar models on this exact device.
Conclusion: The defect is isolated to the foundry-local daemon's AutoRegisterCertifiedEps / download_and_register_eps call, which passes QNNExecutionProvider twice in its self-generated request list, causing the EP name-matching logic to fail.
Workaround used: Running models on CPU (generic-cpu variants) via the foundry CLI/SDK, or using the Foundry Toolkit playground for actual NPU-accelerated inference.
Diagnostics
System
Service
Models
Connectivity
Warnings