← BackJan 7, 2026

Snapdragon Dev Kit Outage: A Windows 11 Update Failure and the Perils of Discontinued Firmware Support

A Snapdragon Dev Kit that had been running Windows 11 for ARM flawlessly since October 2024 was brought down by a failed security update (KB5068861). The update triggered repeated rollbacks, boot hangs, and an eventual complete loss of bootability, and the lack of an official recovery path from Qualcomm left the system irreparable. This incident underscores the importance of documented firmware recovery mechanisms for developer hardware.

In October 2024 I installed a Qualcomm Snapdragon Dev Kit equipped with a Snapdragon X Elite ARM64 CPU, 32 GB of LPDDR4x RAM, and a 512 GB SSD, and ran Windows 11 for ARM at launch performance. The unit proved robust for an entire year—no event‑viewer warnings, no driver complaints, and consistent latency for daily work. I even authored a full review a year later, noting that the system behaved like a top‑tier laptop despite its dev‑kit status. Around early December, the kit encountered a notorious Windows 11 security update (KB5068861). While the update initially failed to install, system logs recorded a rollback on reboot. Reinstalling the package three times—clearing the local update cache, running "sfc /scannow" and "dism /Online /Cleanup-Image /RestoreHealth"—did not resolve the issue, nor did a manual download from the Microsoft Update Catalog. A search of community forums revealed a widespread rollout failure that Microsoft intended to address in a forthcoming cumulative update. Consequently, I disabled automatic updates for the following month. When I re‑enabled updates at the beginning of the week, Windows prompted a restart to apply a pending patch. Triggering the restart led immediately to an identical failure: the same update rebounded, the system rebooted four times, and upon final boot I was presented with an unlogged‑in session, a fresh user profile, and the default Windows background. Most built‑in Windows utilities—including Windows Terminal, Event Viewer, and other Microsoft‑managed apps—could not launch. A simple restart from the boot logo failed, with the machine either rebooting automatically or powering off entirely. After numerous attempts, I accepted that the system had entered an unusable state. I proceeded to investigate the UEFI via the Boot Device Selection (BDS) menu accessed by pressing Home during POST. The BDS interface behaved erratically: random freezes, unresponsive menu items, and intermittent keyboard recognition. Alternate keyboards and USB ports did not alter this behavior. After several attempts, I succeeded in navigating the BDS menu, disabling Secure Boot, enabling USB‑first boot, and activating the UEFI function that allows Windows PE to use external displays—a necessary step for a non‑laptop machine. With a bootable USB drive containing the Windows 11 ARM ISO and another USB drive loaded with the Snapdragon Dev Kit driver suite downloaded from Qualcomm’s website, I booted into the Windows installer. The installation progressed normally and overwrote the existing C: partition. During the initial setup, after setting region and keyboard layout, the installer requested a network driver. I browsed to the second USB drive, but before I could select a driver the system froze and shut down. Subsequent attempts to boot from either drive failed, with the system stalling at the Snapdragon boot logo or powering off without clear error codes. The BDS menu remained but was no longer usable, effectively blocking any further attempts at Windows re‑installation or alternative OS deployment. I verified hardware integrity by reseating the SSD and testing it in an external enclosure; the drive performed perfectly in a different machine. The boot‑loop behavior points toward a corrupted firmware or UEFI component—possibly corrupted by the failed update—or a mismatch in Secure Boot/TPM state exacerbated by Qualcomm’s discontinuation of support for the dev kit. Because the kit was announced for discontinuation on the day of its release, Qualcomm offered no documented firmware recovery mechanism, nor any OEM‑backed recovery utility. In contrast, consumer Snapdragon PCs from ASUS, Dell, or Lenovo typically provide recovery images and re‑flash procedures. This post is a cautionary tale for developers and early adopters of niche platform hardware. When a vendor terminates product support, it is vital that they provide a clear, documented path for firmware recovery, particularly for devices that will be run as primary workstations. The Snapdragon X Elite chipset remains outstanding—its performance far exceeding the author’s 10‑year‑old Core i9 machine—but the lack of recovery tools has rendered a 32 GB ARM machine permanently inoperable after a single security update failure. If Qualcomm (or any vendor) revises its firmware recovery strategy for the Snapdragon Dev Kit, updates to this article will follow.