Device Descriptor Request Failed: when your Bluetooth radio stops answering the phone

Last Tuesday my Windows 11 workstation decided it no longer had Bluetooth. No icon in the system tray, no devices in Settings, AirPods suddenly strangers. Meanwhile, WiFi — on the very same PCIe card — carried on as if nothing had happened.

The traditional Windows response to this situation is a shrug, a reboot, perhaps a second reboot for luck, and finally the workaround: “fine, I’ll use my wired headphones instead.” We’ve all been there. Bluetooth often comes good again on its own, and nobody ever finds out why it left or why it returned.

This time I decided to investigate it Linux-style instead — and discovered something that nobody ever tells Windows users: Windows has a dmesg equivalent. It’s called Get-PnpDevice, it’s been sitting in PowerShell all along, and once you know how to read its output like a crime scene, an “annoying Windows thing” turns into a proper forensic investigation with a satisfying conviction at the end.

Why WiFi survives when Bluetooth dies

First, a piece of architecture that explains why this failure pattern is so common. My machine uses a PCIe combo card with an Intel AX200 chip for both WiFi and Bluetooth. Sounds like one device — but it isn’t. The WiFi half talks to the system over the PCIe lanes, yet the Bluetooth half is actually a USB device: on most desktop cards it connects through a little internal cable running from the card to a USB 2.0 header on the motherboard.

Two radios, one card, two completely different buses — and therefore two independent driver stacks that fail independently. “WiFi works but Bluetooth is gone” isn’t a contradiction; it’s a bus-level split. Once you know this, the mystery already shrinks: whatever happened, it happened on the USB side.

Windows does have a dmesg

On Linux, my first move would be dmesg and lsusb: what does the kernel see, and what’s on the bus? On Windows, the equivalent lives in PowerShell. Open an elevated prompt and ask what the Plug and Play manager knows:

Get-PnpDevice -Class Bluetooth | Format-Table FriendlyName, Status, InstanceId
Get-PnpDevice | Where-Object {$_.InstanceId -like "USB*"} | Format-Table FriendlyName, Status

The output looks unremarkable at first — a wall of device names and statuses. The trick is knowing that Get-PnpDevice shows you everything Windows has ever seen, not just what’s currently connected. That makes the Status column the single most informative piece of data on the system, if you know how to read it.

Reading the crime scene: ghosts and bodies

Here’s the decoder ring:

• Status “Unknown” means the device is not currently present. These are ghost entries — things Windows remembers but cannot see right now. A USB stick you unplugged last month is a ghost. This status is completely normal in moderation.
• Status “Error” means the device is present and misbehaving. This is a live problem — a body at the crime scene.
• Status “OK” means alive and well.

My Bluetooth class query returned over thirty devices — the Intel radio, both Microsoft Bluetooth enumerators, every set of AirPods, the game controllers, my graphics tablet — and every single one was a ghost. The entire Bluetooth stack had collapsed into “Unknown”. That’s a pattern in itself: when a whole device class goes ghost at once, you’re not looking at thirty failures, you’re looking at one failure with thirty casualties. Everything in that class hangs off one root device, and the root was gone.

And in the full USB listing, exactly one device on the entire system had a live Error status:

Unknown USB Device (Device Descriptor Request Failed)    Error

One body, thirty ghosts. Time to identify the body.

The suspect who won’t give a name

A more detailed look at everything in Error state:

Get-PnpDevice | Where-Object {$_.Status -eq "Error"} | Format-List FriendlyName, InstanceId, Problem

FriendlyName : Unknown USB Device (Device Descriptor Request Failed)
InstanceId   : USB\VID_0000&PID_0002\5&8B46B22&0&12
Problem      : CM_PROB_FAILED_POST_START

Every USB device carries a Vendor ID and Product ID — its name and passport. VID_0000 is not a real vendor. It’s the placeholder Windows assigns when a device is physically present, drawing power, but fails to answer the most basic question on the bus: “what are you?” That’s what “Device Descriptor Request Failed” means. The device isn’t unknown because Windows lacks a driver — it’s unknown because it’s refusing to identify itself. A driver never even enters the picture, because drivers only load after the descriptor is read.

This single fact already exonerated my first suspect. Two Windows updates had landed the very Tuesday the Bluetooth vanished, and the timing looked damning. But no driver update can cause a descriptor-level failure — that conversation happens below the driver layer entirely. The updates were innocent bystanders, convicted in my head purely by post hoc ergo propter hoc, the eternal Windows fallacy: “it broke after the update, therefore the update broke it.”

The fingerprint match

So who was the nameless suspect? Look closely at the instance paths — this is the beautiful part. The ghost entry for my Intel radio, from happier times:

Intel(R) Wireless Bluetooth(R)    USB\VID_8087&PID_0029\5&8B46B22&0&12

And the wedged unknown device:

Unknown USB Device                USB\VID_0000&PID_0002\5&8B46B22&0&12

The tail of that path — 5&8B46B22&0&12 — encodes the physical location: which hub, which port. Same hub, same port 12. The catatonic mystery device was sitting in the exact physical slot where the Intel radio is registered. That’s a fingerprint match. Case closed on identification: the Bluetooth radio was present, powered, and wedged so hard its firmware couldn’t state its own name.

The full causal chain, reconstructed: radio firmware crashes → can’t answer the descriptor request → Windows assigns placeholder VID_0000 → no driver can bind → the Intel Bluetooth device drops off the bus → both Bluetooth enumerators lose their root → every paired device collapses into a ghost. One catatonic chip, thirty casualties downstream. And WiFi never noticed, because it lives on the PCIe side of the card.

Whodunnit, then?

With the updates cleared, the real culprit was hiding a few days earlier in the timeline: a game with a kernel-level anti-cheat driver had hard-crashed the machine — an unannounced restart, mid-session, no controlled shutdown. That kind of dirty reset gives USB devices no orderly teardown, and wedging a Bluetooth radio’s firmware in exactly this way is textbook behaviour for these Intel combo chips afterwards.

But wait — the machine had been switched off for days between the crash and the Bluetooth discovery. Surely that would have cleared any wedged firmware?

The shutdown that isn’t

Here’s the second thing nobody tells you: “off” isn’t off. As long as the power cord is connected and the PSU’s rocker switch is on, the +5VSB standby rail keeps trickling power through the motherboard — it’s what makes wake-on-LAN, keyboard wake and USB charging work on a “powered down” PC. That standby rail also feeds the internal USB header where my Bluetooth radio lives. The wedged firmware state survived every honest shutdown, lovingly preserved by five volts of standby power, for days.

There’s a delicious irony in my case: everything on my desk hangs off one big switched power block that gets turned off overnight — every device gets an involuntary full power drain, every night. Every device except the workstation itself, which I’d deliberately excluded so that an accidental flick of the switch couldn’t yank power from a running OS. Sound reasoning — with the side effect that the one machine hosting a fault that required losing standby power was the one machine that never lost standby power.

While we’re exonerating suspects: Fast Startup, the usual “your shutdown is secretly a hibernate” culprit, was also innocent here. Worth checking on your machine though, because Windows feature updates have a habit of silently re-enabling it. The honest way to check:

Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager\Power" -Name HiberbootEnabled
powercfg /a

HiberbootEnabled of 0 means it’s off; powercfg /a tells you which sleep states your system actually supports. If Fast Startup shows as “disabled in the current system policy”, it’s pinned the durable way — that phrasing means a policy setting rather than a mere Control Panel checkbox, and policy settings survive feature updates where the checkbox quietly reverts.

The fix: the only true power-off your PC has

The cure follows directly from the diagnosis. The radio’s firmware needed to reload from scratch, and the only way to make that happen was a genuine, complete power drain:

1. Clean shutdown: shutdown /s /t 0 from an admin prompt (this always performs a full shutdown, bypassing Fast Startup wherever it might be lurking)
2. Flip the PSU rocker switch on the back — or pull the cord — and wait a good 30 seconds for the standby rail to fully drain
3. Switch on, boot

Step 2 is the entire fix. It’s also completely harmless: the OS is already down and the filesystems are flushed — you’re only draining the rail that keeps wake-on-LAN and catatonic Bluetooth radios alive. After the cold boot, the same query told the whole story in one line:

Intel(R) Wireless Bluetooth(R)    OK    USB\VID_8087&PID_0029\5&8B46B22&0&12

Real vendor ID back in place, same hub, same port 12 — and all thirty ghosts reanimated to “OK” along with it: enumerators, AirPods, controllers, tablet, the lot. The poetic footnote: the “Device Descriptor Request Failed” entry is still in the list, but now it’s the ghost. The impostor and the real radio have swapped places.

Keeping it fixed

One bit of prophylaxis, because USB selective suspend is the most common way these radios wedge themselves again without needing a crash: Device Manager → your Bluetooth radio → Power Management tab → untick “Allow the computer to turn off this device to save power”. On a desktop workstation the power saving is meaningless anyway, and the suspend/resume cycling is exactly the kind of transition that trips the firmware up.

The takeaway

The fix took thirty seconds and a rocker switch. The diagnosis is the part worth keeping, because it generalises to almost any “device mysteriously vanished” situation on Windows:

• Get-PnpDevice is your dmesg and lsusb wearing a trench coat — learn to love it
• “Unknown” entries are ghosts (absent); a lone “Error” is a body (a live fault) — an entire class of ghosts means one root device took everything down with it
• VID_0000 is a suspect refusing to give a name, not a mystery device
• Matching hub paths across a failure is a fingerprint match — it identifies a nameless device beyond doubt
• Descriptor failures happen below the driver layer — no driver update can cause them, however suspicious the timing
• And “off” isn’t off until the standby rail is drained

Windows gives you a shrug emoji where Linux gives you a kernel log. But the log is there — nobody just tells you where to look. Now you know.