KB5068002: Vitis AI Execution Provider 1.8.25.0 on Windows 11 24H2 Copilot+

  • Thread Author
Microsoft has quietly pushed KB5068002, a targeted Windows Update that refreshes the AMD Vitis AI Execution Provider to version 1.8.25.0 for eligible Copilot+ PCs running Windows 11, version 24H2, delivering a compact—but consequential—component update for on‑device AI acceleration.

Background / Overview​

The Vitis AI Execution Provider (Vitis AI EP) is AMD’s runtime and tooling that allows ONNX‑based models to offload inference to AMD accelerators — from Ryzen AI NPUs in client APUs to Adaptable SoCs and Alveo cards on data‑center/edge platforms. On Windows, Vitis AI is published and consumed as a discrete execution provider that can be updated independently of the core OS and application binaries.
Microsoft’s KB entry for KB5068002 is intentionally concise: the public note simply states the update “includes improvements” to the Vitis AI Execution Provider AI component, that the package is delivered automatically via Windows Update, and that the device must already be running the latest cumulative update (LCU) for Windows 11, version 24H2 before it will apply. The entry also specifies the Update history label you should see after installation: “2025‑09 Vitis AI Execution Provider version 1.8.25.0 (KB5068002).”
Why Microsoft distributes Vitis AI EP as a component: Windows now treats vendor execution providers (AMD Vitis AI, Intel OpenVINO, Qualcomm QNN, NVIDIA TensorRT, etc.) as modular pieces of the on‑device AI stack so vendors and Microsoft can iterate on model runtimes and optimizations independently of full OS feature updates. That approach speeds delivery of performance and quality improvements but shifts validation responsibilities to IT teams, OEMs, and application developers.

What KB5068002 actually contains (public facts)​

  • Update name and version: Vitis AI Execution Provider version 1.8.25.0 (KB5068002).
  • Scope / applicability: Copilot+ PCs running Windows 11, version 24H2 (Home, Pro, Enterprise, Education, SE, Multi‑Session and IoT Enterprise SKUs are listed where Copilot+ hardware is present).
  • Delivery method: Automatic via Windows Update; the device must have the latest 24H2 cumulative update installed (LCU prerequisite).
  • Replacement behavior: Microsoft states this component update does not replace any previously released update; it is an incremental component refresh.
Those are the explicit, verifiable statements in the public KB. Any additional technical detail in community notes or vendor pages remains inferred or must be sourced from AMD or Microsoft engineering release notes, which are not included in the KB text itself. Treat feature‑level or CVE claims as unverified unless Microsoft/AMD publish more granular release notes.

Technical context — where Vitis AI EP fits in the Windows AI stack​

On Windows, the vendor execution provider sits as a backend to the system-managed ONNX Runtime/Windows ML runtime. Applications open an ONNX Runtime inference session, and the runtime can select a registered execution provider to offload supported operators to hardware accelerators. The Vitis AI EP compiles supported ONNX subgraphs into a device‑specific executable (on first load), caches that compiled artifact, and dispatches execution to the AMD NPU/GPU/DPU at runtime. Compilation time and the caching behavior are part of the provider model and are especially relevant to first‑run latency and storage on disk.
Key technical characteristics of the Vitis AI Execution Provider (derived from AMD/ONNX Runtime docs):
  • Model compilation on first load: The EP compiles the model into a runtime executable for the target accelerator; compilation can take minutes for complex graphs but is cached afterwards.
  • Graph partitioning: The EP partitions the ONNX graph — NPU‑supported operators run on the accelerator; remaining nodes fall back to CPU.
  • Provider configuration / caching: There are provider options such as cache directory, cache keys and config files that control compilation, caching, and runtime behavior on Windows.
These behaviors explain why an update to the Vitis AI EP — even when described only as “includes improvements” — can change performance, memory footprint, or numerical results under certain workloads.

What users and developers should realistically expect​

Because Microsoft’s KB is terse, practical expectations must be derived from the role of the component and past update patterns. The following are evidence‑based, realistic outcomes — not absolute promises:
  • Visible, incremental improvements to imaging flows that use local inference: Photos super‑resolution, background segmentation (Studio Effects / virtual backgrounds), live camera filters, and thumbnail generation may show crisper results or fewer artifacts on qualifying AMD Copilot+ hardware. These are typical target surfaces for image‑processing EP updates.
  • Slight reductions in inference latency or CPU offload: micro‑optimizations in operator scheduling, memory reuse, or quantization handling can lower latency and energy per operation for NPU‑backed tasks — actual gains are workload‑dependent.
  • Improved robustness and input hardening: updates often include better error handling and input validation for image parsing chains, reducing crashes with malformed content — but the KB does not list CVE identifiers if any security fixes are present. Treat security claims cautiously until a security advisory or CVE mapping is published.
For developers and ISVs, the practical implications include re‑running model validation, confirming fallback behavior (CPU vs. NPU), and validating numeric thresholds in post‑processing (mask binarization, tokenization timing, etc.). Even small numeric shifts from quantization changes can alter downstream logic in production apps.

Risks, common failure modes, and why careful rollout matters​

Component updates that sit between OS APIs, vendor runtimes, and hardware drivers have a consistent set of operational risks:
  • Driver/firmware mismatch: The most frequent cause of post‑update regressions is an out‑of‑sync GPU/NPU/chipset driver or OEM camera firmware. Align drivers with OEM‑recommended versions before broad deployment.
  • Opaque changelogs: Microsoft’s short “includes improvements” phrasing provides little forensic detail, which complicates root cause analysis and compliance checks. Large organizations requiring explicit change records should open a support case with Microsoft or the OEM for package‑level release notes.
  • Rollback complexity: Component updates delivered through Windows Update can be less straightforward to roll back than standalone packages. Ensure recovery images and rollback procedures are validated for critical systems.
Operational experience from prior EP updates shows that most user‑visible regressions are mitigated by aligning vendor drivers and performing staged rollouts, rather than immediate mass deployment.

Practical guidance — how to prepare and validate (admin & power‑user checklist)​

Follow a methodical, measurable process to reduce risk and confirm value.
Pre‑deployment checklist:
  • Confirm devices are Copilot+ and running Windows 11, version 24H2 with the latest cumulative update (LCU) installed; the component will not apply otherwise.
  • Inventory which endpoints are eligible Copilot+ AMD machines (Ryzen AI / Adaptable SoC / Alveo where applicable). Maintain a CMDB flag for component version.
  • Align vendor drivers and firmware: update AMD chipset, GPU drivers, and any NPU runtime/firmware to OEM‑recommended versions before staging the component.
Pilot ring (recommended 7–14 days):
  • Deploy KB5068002 to a small, representative pilot group covering major OEMs, firmware revisions, and thermal profiles.
  • Run focused acceptance tests:
  • Photos: Super‑Resolution, Erase/Restore, Restyle.
  • Video conferencing: background removal/blur and Studio Effects.
  • Camera/Windows Hello: capture and biometric enroll/login if your pipeline uses the same imaging stack.
  • Collect telemetry: Event Viewer logs, Reliability Monitor, CPU/NPU utilization traces, latency measurements, and crash dumps. Record sample inputs (images/streams) that reproduce issues for escalation.
Broader deployment:
  • Move from pilot → small → medium → broad in stages, monitoring telemetry for 7–14 days per stage.
  • Maintain a tested rollback image and a documented sequence for recovery in managed environments.

How to verify the update on a device (step‑by‑step)​

  • Open Settings → Windows Update → Update history. You should see an entry titled: 2025‑09 Vitis AI Execution Provider version 1.8.25.0 (KB5068002) after installation.
  • Confirm underlying driver versions: record AMD GPU/Adrenalin, chipset, and any vendor NPU runtime versions. Compare to OEM recommendations.
  • Run representative functional tests (Photos super‑resolution, Studio Effects) and compare latency/quality metrics with pre‑update baselines. Capture logs and sample images for repeatable repro cases.
  • If anomalies occur, collect: Update history entry timestamp, Windows Event logs, WER crash dumps, and exact driver/firmware versions before escalating to OEM or Microsoft support. Including the full package name from Update history speeds triage.

Developer and ISV notes — validating model behavior​

  • Re‑run model validation suites on target hardware using ONNX Runtime with the VitisAIExecutionProvider selected to detect any changed operator behaviors or fallbacks. Confirm cached EP context behavior and session creation timing.
  • Pay particular attention to quantized models and post‑processing thresholds: small numeric deltas can change mask/boundary decisions and downstream automation.
  • Consider enabling session options that reveal fallback behavior or OP partitioning during tests to ensure critical subgraphs continue to run on the targeted accelerator.

Cross‑checks and independent corroboration​

The Microsoft KB is definitive about the package name, version and delivery mechanism. The ONNX Runtime and Ryzen AI documentation independently confirm how a Vitis AI Execution Provider integrates with the runtime (compile‑on‑first‑use, caching, provider options and graph partitioning), which explains the likely operational effects of the KB update. Use those vendor docs to interpret how a component update could affect compilation time, cache layout, and runtime partitioning.
Note: The KB itself does not list a line‑by‑line engine changelog or CVE mappings. Where public details are lacking, the responsible course is to treat specific claims (security fixes, exact performance numbers) as unverified until vendors publish dedicated release notes or security advisories.

Troubleshooting and escalation guidance​

If you experience regressions after the update:
  • Reproduce and capture: sample inputs, screenshots/video, timestamps, and clear repro steps.
  • Collect system diagnostics: Update history entry, Windows Event logs (Application and System), WER crash dumps, and driver/firmware version strings.
  • Where evidence points to driver incompatibility (GPU hangs, camera failures), escalate to the OEM or AMD driver support with collected artifacts. Where the issue appears tied to the on‑device AI component behavior and persists after driver alignment, escalate to Microsoft Support and provide the full package name and Update history entry — Microsoft’s component KBs are terse and support staff will often require the package identifier to correlate internal release notes.

Strategic takeaways for IT leaders​

  • Treat KB5068002 like any OS‑level change that touches hardware acceleration: pilot, measure, and stage. Component updates can materially affect user experience even when the KB text is minimal.
  • Maintain an accurate inventory of Copilot+ endpoints (silicon vendor, OEM image, driver/firmware versions) to reduce time‑to‑resolution for any post‑update regressions.
  • If your organization requires precise change records for compliance or security, plan to open vendor or Microsoft support cases immediately after rollout to request detailed engineering notes or CVE mappings; the public KB alone may be insufficient.

Conclusion​

KB5068002 is a narrow but strategically consistent example of how Microsoft and silicon partners iterate on on‑device AI: a vendor execution provider packaged as a small Windows Update component to deliver incremental runtime and model improvements. For users on qualifying AMD Copilot+ hardware it is likely to be net positive — modest UX and performance gains on imaging and inference paths — provided drivers and firmware are aligned. For enterprises and developers the operational burden increases: rigorous pilot testing, driver alignment, telemetry capture, and an escalation pathway are now required components of routine Windows maintenance. The KB’s brevity leaves engineering detail opaque; where precise fixes or security impact matter, request the deeper technical notes from Microsoft or AMD and validate behavior on representative hardware before broad deployment.


Source: Microsoft Support KB5068002: AMD Vitis AI Execution Provider Update (1.8.25.0) - Microsoft Support