Windows App SDK 1.8.12 Final Update Fixes Unavailable Arm64 ML Providers

Windows App SDK 1.8.12 Closes the 1.8 Branch With a Single Windows ML Fix​

Microsoft's release page on GitHub says Windows App SDK 1.8.12 is the final servicing release for version 1.8. It fixes a Windows ML issue that could expose an unavailable execution provider on certain Arm64 devices. The Microsoft Learn release notes for 1.8 match the GitHub entry word for word. They give the release date as September 24, 2026 and list the same single bug fix, so the two first-party records agree on version, build number and scope.

Microsoft does not name the affected devices, Windows builds or execution providers. The only scope it gives is "certain Arm64 devices." So this is not a defect on every Windows on Arm PC, and nothing suggests x64 machines were affected.

Microsoft is also not describing this as a security fix, a crash fix or a performance change. It's a correctness fix to one discovery API. Most of the 1.8 line's servicing notes contain several fixes, so a one-item release is unusual. Here it looks like Microsoft is closing out one known problem before the branch goes quiet.

How ExecutionProviderCatalog.FindAllProviders Could List a Provider That Couldn't Be Delivered​

Some background on Windows ML helps here. The 1.8.1 release notes from September 2025 describe Windows ML as a way to run ONNX AI models locally on a shared, system-wide copy of ONNX Runtime. Hardware-specific execution providers (EPs) are installed dynamically instead of being bundled with each app. An EP is the component that runs a model on a particular piece of hardware. The same release added the ExecutionProvider and ExecutionProviderCatalog APIs, along with the ExecutionProviderReadyState and ExecutionProviderReadyResult types that report whether a provider can be used.

In Microsoft's API reference, ExecutionProviderCatalog.FindAllProviders retrieves a collection of all execution providers compatible with the current hardware. Microsoft's sample code calls ExecutionProviderCatalog.GetDefault(), then FindAllProviders(), and loops over the results to read each provider's name and device type. That's the normal starting point for an app choosing where its model will run.

A provider returned in the NotPresent state is one the catalog considers compatible with the device but not yet installed on it. ExecutionProvider.EnsureReadyAsync is the call that actually gets the provider ready. According to Microsoft's description of the bug, on certain Arm64 devices FindAllProviders could return a provider in NotPresent even though EnsureReadyAsync could not acquire it. Discovery said one thing and acquisition did another. In 1.8.12, the unavailable provider no longer appears in the list on affected devices.

In practice, an app that read the catalog on an affected machine could see an option it was never going to get. Our inference is that code which trusted the catalog list, for example by showing the provider as selectable or attempting it first, would then hit a failed readiness call. Microsoft hasn't said what older versions actually did at that point. Its note doesn't say whether apps got a specific error, quietly fell back to another provider, or failed outright, so it's unclear how visible the bug was to end users.

A Pattern of Windows ML Readiness Fixes Across the 1.8 Servicing Line​

1.8.12 is the latest in a string of 1.8 servicing fixes aimed at the same problem: making Windows AI and Windows ML APIs report readiness accurately. The Learn release notes show the trend clearly:

The 1.8.7 change stands out. Microsoft centralized NPU detection so that new and upcoming NPU hardware could be supported without client apps needing updates. Hardware support that depends on dynamically delivered components puts more weight on discovery APIs, since apps rely on the catalog to know what exists. When the catalog lists something that can't be installed, that promise breaks. Microsoft hasn't said whether the Arm64 bug is related to the centralized detection work, and the release notes don't give a root cause.

The table also shows how the servicing branch has worked. Early 1.8 servicing releases delivered new APIs, new EPs and ONNX Runtime updates. Later ones narrowed to crash, leak and correctness fixes. The previous release, 1.8.11 on August 13, 2026, fixed Storage Picker focus, an MRT Core fallback-path regression, and a runtime base-directory environment variable leaking into child processes. By 1.8.12, one bug is left.

What "RuntimeCompatibilityChange: N/A" Tells You About Upgrade Risk​

Almost every fix in the 1.8 servicing notes carries a named RuntimeCompatibilityChange tag, such as StoragePickers_RestoreFocusAfterDialogCloses in 1.8.11 or ThemeSettings_OffThreadDestructorFix in 1.8.10. The 1.8.12 fix is tagged "N/A, Windows ML provider availability fix." Microsoft uses "N/A" the same way elsewhere in the 1.8 notes, for example on build-time tooling and .targets changes.

Microsoft doesn't explain the N/A label for this entry. Our reading is that there's no named compatibility identifier for this behavior change, so there's nothing to cite if you wanted to pin the old catalog behavior. Since the old behavior was reporting a provider that couldn't be acquired, few developers are likely to want it back.

The change your code will notice is simple. On affected devices, FindAllProviders may return one fewer entry than before. Microsoft doesn't say EnsureReadyAsync, the API signatures or any other Windows ML behavior changed. Code that assumes a fixed number of providers, or hardcodes an expected provider on Arm64 test machines, could see a difference in what it enumerates.

Packaging Windows App SDK 1.8.260921001 and the Runtime Question​

The GitHub release tells developers to download the 1.8.260921001 NuGet package to use WinAppSDK 1.8 in your app. For most projects, that means changing the Microsoft.WindowsAppSDK package reference to 1.8.260921001 and rebuilding. Since 1.8, the Windows App SDK NuGet package has been a metapackage. Each component contributing to the Windows App SDK is now a component NuGet package and is listed as a dependency by the metapackage. This allows developers to choose either the metapackage or select specific component packages for their applications. If your project references individual component packages instead of the metapackage, make sure the component that carries Windows ML is updated too.

The 1.8 release notes send developers to the Windows App SDK downloads page for the updated runtime and MSIX packages. That matters for framework-dependent apps, which rely on the runtime installed on the user's PC and not on binaries shipped in the app. We couldn't confirm that a 1.8.12 runtime installer had been posted when this was written, so if your app uses a separately deployed runtime, check the downloads page before assuming users' machines will pick up the fix.

The end of 1.8 servicing makes that question more urgent. The NuGet Gallery already lists Microsoft.WindowsAppSDK at version 2.5.1 as the current package, so the 2.x line is well established. Microsoft's 1.8.12 notes don't say what support 1.8 apps get from here. Still, the "final servicing release" label means no more fixes are planned for this branch.

What this means for you​

Whether to act depends on one question: does your app call Windows ML's execution-provider catalog on Arm64 hardware? If it does, update and test. If it doesn't, this release changes nothing for you, and the bigger decision is when to move off 1.8.

Developers with Windows ML apps on Windows on Arm should update to 1.8.260921001. Then run the enumeration-and-readiness path on the Arm64 devices you support: call FindAllProviders, call EnsureReadyAsync on each provider your selection logic would use, and confirm every listed provider can actually be made ready. That's our testing advice, not a Microsoft procedure. Microsoft hasn't published a test matrix or a list of affected devices, so any Arm64 hardware you have is a reasonable test target.

Teams that use Windows App SDK 1.8 only for WinUI 3, app lifecycle or other non-ML features get no functional change here. They can wait, although building on the final 1.8 package means you're on the last patched code for that branch.

• Windows App SDK 1.8.12 (1.8.260921001) was released on September 24, 2026 and is the final servicing release for the 1.8 line.
• The only fix stops ExecutionProviderCatalog.FindAllProviders from returning a NotPresent provider that EnsureReadyAsync couldn't acquire, on certain unnamed Arm64 devices.
• Microsoft lists no security, crash or performance changes, and no changes to API signatures or EnsureReadyAsync behavior.
• On affected Arm64 devices, expect FindAllProviders to return one fewer provider, and check any code that assumes a fixed provider list.
• If your app relies on the installed Windows App SDK runtime and doesn't ship it self-contained, confirm the matching 1.8.12 runtime is available before relying on the fix reaching users.
• With 1.8 servicing finished and the 2.x packages current on NuGet, plan a migration for any app that needs fixes after this one.

Windows App SDK 1.8.12 does one thing: when Windows ML lists a provider on Arm64, that provider can now actually be acquired. For AI apps choosing hardware at runtime, that's the right last fix for the branch. With servicing for 1.8 now over, future Windows ML fixes and new EPs will ship in newer Windows App SDK releases, so anyone still building on 1.8 should put a 2.x migration on the schedule.