My USB device isn't recognized

“Not recognized” covers several different failures, and the first job is finding which layer yours is in. A USB connection has four of them: the physical path (cable, port), the power the device receives, the controller and driver in the computer, and — for a drive — the way Windows makes the disk visible. Each layer fails differently, and this page is organized so you test them cheapest first. The single most useful first observation is whether your computer acknowledges the connection at all — the connect sound, a notification, anything — because that tells you whether the fault is before or after the electrical handshake, and it sorts half the cases by itself.

The diagnostic ladder, top to bottom: does the system make a sound? → does the device appear in Device Manager (even with a warning)? → if it's storage, does it appear in Disk Management? → does it have a drive letter in File Explorer? Each rung is a free check, and each “no” narrows the suspect list: a no at rung one points at cable and port; a no at rung two at port and controller; a no at rung three at the enclosure or the drive; a no at rung four at a configuration step that takes a minute to fix. The table below maps the common presentations to their rung.

Two rules before you go further. If the device holds data you can't afford to lose, read the data safety section first — some steps are fine either way and some are not, and the RAW/Unallocated row above is where that distinction matters most. And if this is a work or school machine, “not recognized” can be a policy decision (an IT policy that blocks removable devices) rather than a fault, which changes who fixes it. The decision tree above the directory runs this ladder for you; the guides are where each branch lands.

The rule that organizes everything: the health of the data decides how aggressive you can be. A USB device with no data you need is a free experiment — format it, re-partition it, stress it, replace it. A USB device with files you can't replace is not, and the difference changes which steps you're allowed to take. Before any repair step, answer one question: if this step goes wrong, do I lose data I need? If yes, the step is only allowed after the data is copied — or after you've explicitly accepted the loss. Every guide on this page is written so the safe steps come first, but this article is the version of that rule you can check against mid-diagnosis.

The failure signs that flip the priority. A storage device showing any of these is a device to preserve, not a device to troubleshoot: it appears and disappears on its own; it's dramatically slower than it used to be; it makes clicking, grinding, or repetitive beep sounds (mechanical drives — a flash drive doing this is a controller fault, same principle); it surfaces read-error dialogs; or it shows as RAW or Unallocated when it held files before. If you see those signs, the order inverts: stop diagnosing the connection, get the important files off with a straight copy while the drive will read, and if it won't copy reliably, that's the line where a professional imaging service beats any home fix. No procedure on this page guarantees recovery — and some of them, repeated against a failing drive, make the position worse. A mechanical drive that has clicked once deserves rest, not ten more spin-ups.

What “safe” concretely means, mid-diagnosis: looking things up is always safe (Device Manager, Disk Management — both are read-only views of the system's current state); rescan-for-hardware-changes is safe (re-enumeration writes nothing to your device); a drive-letter change is low-risk (it relabels, it doesn't touch contents); a driver reinstall or a power-settings change is low-risk (they affect the interface, not the data). The line is drawn at disk operations: initializing, “repairing,” formatting, and deleting partitions all write to the disk, and on a drive with data they're last resorts at best. The data safety section below has the full risk table; this article is the reasoning for why the table is shaped the way it is.

The isolation test, and the cheapest one on this page: plug the device into another computer. The result splits the problem in half. If it works on the other machine, your computer is the cause — a specific port, a controller, a cable path, or a Windows setting — and you can stop suspecting the device entirely. If it doesn't work on the other machine either, the device (or the cable) is the cause, and every guide on this page that points at your computer is moot. Either way, you've converted “something's broken” into “which half is broken,” which is most of the diagnosis for the smallest possible cost.

Run it clean, with two method notes. First, use a different cable if you can: a cable shared between the two tests is a shared variable — a bad cable fails on both machines and muddies the result, so the clean version of the test is a different machine and a known data cable. Second, plug into a rear port on the other machine and give the OS a few seconds to enumerate. Then hold the result to the right standard, because “works elsewhere” is less absolute than it looks: power budgets differ (the other machine's port may supply what yours doesn't), USB controller generations differ (a quirk that bites one xHCI implementation doesn't bite another), and for a drive the filesystem may be one the other OS reads and yours doesn't (a Mac-formatted drive on a PC is the classic). So “works elsewhere” points at your computer without naming the cause — the device-versus-computer guide below turns the result into a specific suspect.

The reverse test completes the picture: a known-good device in your computer's ports. Between the two you have a four-cell result, and each cell has exactly one answer. Works elsewhere, fails here → your computer's path (port, controller, or OS setting — the rest of this page is the lookup). Fails everywhere → the device or the cable (a replacement question, not a troubleshooting one). Works in some of your ports but not others → the specific port or the controller behind it (the dead-port guide). That's the whole diagnosis for the majority of USB problems, and it costs nothing but a second machine and ten minutes — which is why it's near the top of the tree rather than buried in the advanced material.

How to read the visibility ladder as a diagnosis. A USB device “exists” in Windows in stages, and how far it gets tells you where it stopped. Not in Device Manager at all → the electrical or enumeration layer (cable, port, power, or the device's own controller). In Device Manager with a warning → it enumerated and then failed (a driver or a device fault). In Device Manager clean, a storage device, but no disk in Disk Management → the enclosure's bridge or the drive itself. A disk in Disk Management but no letter → a configuration step is missing, and assigning the letter is the fix. A drive in Explorer that won't open → a filesystem or a data problem, and the data-safety rules are now in force. The table below is the ladder in one view.

The two tests that convert “where” into “what” are the ones in the other-computer guide: the device on another machine, and a known-good device in your ports. Do both, with a known data cable, and the fault lands on one of three places — the device, the cable, or the computer — after which the guides on this page stop being a search and become a lookup. There is no interpretation step; the tests are designed so the result either follows a swap or it doesn't.

One cell in the table deserves its own warning, because it's the most misdiagnosed: “Device Manager clean, no disk” on a storage device is the signature of a dying drive more often than a configuration problem. The enclosure's controller can enumerate perfectly while the drive inside never comes up, and that state is exactly where people burn an hour on driver fixes that can't possibly work. If the device has data, this is the cell where you stop configuring and start preserving — the no-disk guide and the data safety section are the next two reads, in that order.

What Windows 11 shows you, and what it means. Win11 surfaces USB faults in two places: the notification (“USB device fails” or “A device isn't working properly” — sometimes with the device's name) and the device list in Settings → Bluetooth & devices → Devices, with Device Manager as the technical view. The notification is a specific kind of failure: it means Windows saw the device start connecting and then the connection failed — an enumeration failure, the “recognized-then-not” variant, which is different from “never seen at all” and points higher up the stack (driver, device, or a controller that rejected it) than a cable problem does. Before anything else, note three facts: which port, which cable, and whether the connect sound played. The sound means the electrical layer worked; the notification means the layer above it failed.

The working sequence, cheapest first. Rescan — Device Manager → Action → Scan for hardware changes (or simply unplug and replug, which forces a fresh enumeration; a device that wedged on its first attempt very often connects fine on the second). Find the exact node — a failing device often lands in “Other devices” as an “Unknown device” with a warning, and the node's Properties → Details → Device Instance Path tells you which controller it tried, which is useful if the controller itself turns out to be the story. Read the warning — the error code and message matter; a Code 43 with a vendor message is the device reporting a fault, and that tilts the diagnosis toward the device rather than the driver (the driver guide decodes the common codes). Try a different port before a different driver — a port fault mimics a driver fault, and the port test is faster. What to expect: a rescan either makes the node vanish and reappear cleanly (fixed — leave it alone), or it surfaces the warning (now you have a handle to work with, which is progress).

The failure paths, so you know where to exit. If the device never appears at all — no node, no warning — even after a rescan in a known-good rear port with a known data cable, the problem is below the operating system: the cable, the port, the power, or the device's own electronics, and the port and path guides are next, not the driver ones. If it appears with a warning that a clean driver reinstall doesn't clear, the other-computer test is the next move, because at that point “the device is broken” is a live suspect and the test is how you confirm it. One version note: the same ladder applies to Windows 10 with slightly different control locations — the Windows 10 guide below maps where things live there, and the driver and controller guides are shared across both versions.

Where the same diagnosis lives in Windows 10. The diagnostic ladder is identical to Windows 11 — the Win11 guide has the full reasoning — so this guide is the map of the controls, which is what actually trips people up between the two versions. Device Manager in Win10 is one shortcut away: right-click the Start button → Device Manager (or Win + X → Device Manager), not buried in Settings the way newer builds push it. The device list lives in two views: Settings → Devices → USB gives the friendly list, and Device Manager gives the technical one, where the “Universal Serial Bus controllers” and “Other devices” groups live and the warning icons are. The rescan is the same control (Action → Scan for hardware changes), and the unplug-replug shortcut works identically.

The Win10-specific differences that matter. The error notification arrives as a balloon in the action center, which is easy to miss and dismiss without reading — check it, because it names the device and the failure, and that's the same information the Win11 notification carries. The legacy “Devices and Printers” control panel is still present and shows the device with its own warning icon, which is a useful second view when Device Manager's grouping is confusing (a device in the wrong category is often clearer to spot in the flat list). And the power-plan UI is the classic Control Panel → Power Options path — Win11's Settings page doesn't expose the USB selective suspend toggle the same way in every build, and the power management guide uses exactly that path, so if you're on Win10 use the Control Panel route it names. If you're jumping between the two guides, the translation is: Settings page → Control Panel equivalent, and everything else is the same.

The conclusion, so the version difference doesn't become a detour: the OS version doesn't change the physics — a cable is a cable, a port is a port, and a failing drive fails the same way on both. If the Win10 ladder takes you to “a warning that won't clear” or “never appears at all,” the exits are the same ones the Win11 guide names: the driver guide, the controller guide, the port guide, and the other-computer test. Don't re-run the whole page because the buttons live in a different menu — pick the guide that matches your current rung on the ladder and go.

When the driver is the suspect. The signature: the device enumerates — a sound, a node in Device Manager — but then fails. A yellow warning, a Code 43 (“Windows has stopped this device because it has reported problems”), a device filed under the wrong category, or a node that appears and disappears. A driver fault is separable from a hardware fault by one testable property: a driver problem usually follows the computer (the device fails on yours and works on another), while a device problem follows the device (it fails everywhere). Run that test before going deep — it's the two-minute other-computer guide — because it decides whether this guide is even the right one.

The repair sequence, using only Windows' built-in mechanisms. Find the node — in “Other devices,” in the device's proper category, or under “Universal Serial Bus controllers” if the fault is at hub level. Read the warning — the error code and the message: a Code 43 with a vendor string is the device telling you it failed, which tilts the diagnosis toward the device, not the driver; a Code 10/28 is more often a driver-stack problem. Update — Properties → Driver → Update Driver → Search automatically, which lets Windows find and install its own driver for the hardware ID. Roll back — if a recent update pushed a new driver version and broke things, the Roll Back Driver button is the most direct undo available, and it's only present when a previous version is still on the machine. Reset — Uninstall device (on a first pass, without ticking “delete the driver software”), then unplug and replug or rescan; Windows reinstalls the generic stack from scratch, which clears a wedged driver state better than any amount of clicking Update. What to expect on success: the warning icon gone, the node in the correct category, and the device doing its job within a few seconds of the replug.

A word on driver sources. Do not use third-party “driver updater” packages to fix USB problems. The generic USB driver stack is built into Windows and doesn't need a third party to maintain it, and the updater products are a well-known source of new problems — wrong drivers, bundled software, and settings changes you didn't ask for. The only legitimate sources are Windows Update itself and the device or computer manufacturer's own support page, matched to your exact model and OS version.

The failure paths and the boundary. If a clean reinstall of the generic driver doesn't clear the warning, there are two branches: the device needs a real driver (capture cards, MIDI interfaces, printers, certain cameras and webcams — the manufacturer's support page is the source, and the model number matters), or the device itself is reporting a fault (a Code 43 that survives reinstall, survives a port change, and — confirmed by the other-computer test — fails on other machines too, is a device, not a driver, and the answer is replacement or warranty). And the boundary with the next guide: if the warning is on a “USB Root Hub” or an “xHCI/eHCI Controller” node rather than on your device, that's a controller-level fault, and reinstalling the USB controllers is the right procedure — a different operation with different caveats than uninstalling a device, which is why it has its own guide.

How to prove a port is the problem. “This port detects nothing” is a claim you can test in a minute, and the test is: take two known-good devices (a flash drive and a phone, for instance) and try both in the suspect port, then both in a known-good port. The result is binary. Nothing works in the suspect port and both work in the other → the port, or the controller behind it, is the fault, and the device question closes. The devices work in the suspect port too → the port was never the problem, and the original device or cable is. There's no middle result, which is what makes this the port's definitive test rather than another data point.

The tells that make a port fault likely, before you even run the test. It's a front-panel port on a desktop — those run on an internal header cable that can loosen over time, and the header can be a lower-power one, so a high-draw device fails there while a mouse works fine. The port charges a phone but never passes data — the power lines are alive and the data pair is dead, a partial port failure and the most common “half-dead” state, and it explains a great many “my drive won't show but my phone charges” reports. It died after a power event — a surge, a static discharge, a spill — a controller-level fault, and in that case the other ports on the same controller may be affected too, which is why “several adjacent ports all dead at once” points at the controller rather than the ports. On a laptop, ports run direct to the board and a single dead port is usually that port's trace or controller, full stop.

What to do, by case. A front-port fault: use the rear ports (that's the fix, not the repair), and if you're comfortable with it, the header-cable check is a physical inspection — power off, unplug, reseat the front-panel USB cable at the board — but the practical answer for most people is simply “stop using that port.” A data-dead port: same, use another; a single dead data pair is a repair job, not a settings job. A controller-level death (multiple ports on one controller, or a Code 43 on the controller node): the controller re-enumerate first, and if that doesn't clear it, the hardware is the suspect and the when-to-stop section is the next read. And one hard stop worth naming here: if plugging into a specific port reboots or powers off the PC, that's a short circuit, and every further test re-applies the short — stop, and read the advanced guide's short-circuit section before touching that port again.

The path is more than the port. Between your device and the working end of the chain there can be a cable, a hub, a dock, a front-panel run, an extension, a KVM switch — and every one of those is a link that can fail while looking perfectly connected. The different-path test is the systematic version of “try another port”: change exactly one link at a time and watch whether the fault follows it. The links, in the order they actually fail: the cable (by a wide margin — a charge-only cable is the classic, alive on power and dead on data), an unpowered hub (a bus-powered hub has a power budget, and a device near the top of it gets dropped, often under load), a dock (a middleman with its own controller and firmware that wedges the same way small computers do), and the front-panel run (the header-cable case from the dead-port guide).

The method, in the order that isolates fastest. Direct first — plug the device into a rear port on the computer with a cable you've used for data before, bypassing every hub and dock. If that works, the fault is one of the links you just bypassed, and you re-add them one at a time — cable, then hub, then dock — until the fault returns, which names the link. If the direct path also fails, the fault is the device, that cable, or the computer's port or controller, and the other-computer test is the next move. The powered-hub test, for devices that need real power (an external drive, a hub with devices of its own): a powered hub gives the device its own supply and removes the budget question entirely — a device that works through a powered hub but not direct was a power-budget problem all along, and the powered hub (or a rear port for lower-draw devices) is the permanent fix, not a workaround.

The cable gets its own note, because it's the top link and the most misunderstood. A data cable and a charge cable are physically identical and electrically different: a USB-A or USB-C cable that's charge-only will power a phone (or do nothing visible for a bus-powered device) and never pass data, and people keep these cables in circulation for years without knowing. The test that proves a cable does data isn't “it's a new cable” or “it's a name brand” — it's history: the cable has to have demonstrably moved files or shown a device on a machine before. If your suspect cable has never done that, it's not a control, and you should replace the variable before you trust any result it produces. That single habit — a known data cable for every test — is worth more than most of the settings on this page.

USB-C's failure mode is capability, not just connection. The oval connector hides a lot: not every USB-C port does the same things, and not every USB-C cable does the same things. A port can be charge-only (some laptops and monitors ship “USB-C” charging ports that pass power and nothing else), data-only (USB data without the display or power profiles a given device wants), or full — data plus power plus whatever protocol the device needs, with Thunderbolt/USB4 at the top. Cables have the same spread: charge-only, data-only, and full, in identical shells. So “USB-C device not detected” is very often a capability mismatch — this cable or this port doesn't do what the device needs — which is solved by a different cable or port, not a driver, and which no amount of re-plugging on the same cable-and-port pair will ever fix.

How to read capability, then the sequence. Read the port: the markings (a lightning bolt is Thunderbolt, a display symbol means it does video, a plain USB trident means data, and no marking at all means check the manual), and the manual's port list, which is definitive and takes less time than guessing. Read the cable: its history — a charge-only cable has never moved data, full stop, and no label on the outside of a cable is a reliable capability marker. Then run the sequence: a known data-capable cable in a known data-capable port, direct (no dock — a dock is its own USB-C controller and a separate failure point, and the path guide's dock test applies); a different port if the first is charge-only; and the device on another machine to clear it. What to expect: a capability mismatch resolves the moment you're on a cable-and-port pair that both do data — often with no other change at all — and if nothing in the matrix works, the other-computer test decides device versus port.

The devices that bite here, so you can recognize your case. A USB-C flash drive on a charge-only port — the classic; it sits there, does nothing, and the port's charging behavior (or lack of it) is the only clue. A USB-C keyboard or mouse on a port that's data but the wrong generation for its controller — the input guide covers that branch. A Thunderbolt dock on a plain USB-C (non-Thunderbolt) port — it may connect at USB speed, or not at all, depending on the hardware, and the dock's own LED is usually the tell. A phone in a laptop's USB-C port — a phone is a USB device, and a data port will show it as a media device; if it doesn't, the cable or the port's data path is the suspect. The through-line for all of them: USB-C problems reduce to three questions — does this cable do data, does this port do data, does the device need more than data — and those three questions, in that order, end most of them before a driver is ever involved.

The specific case: the drive is recognized — the sound played, there's a node in Device Manager, maybe a disk in Disk Management — but there's no drive in File Explorer. That's a visibility failure, not a recognition failure, and the cause is almost always one of three: the drive has no letter (Windows recognized the disk but didn't — or couldn't — assign one), the partition's filesystem is one Explorer won't auto-mount, or the volume is in a state that blocks auto-mount (a RAW or failed state, or a policy that hides removable drives). The first move is the same every time: open Disk Management (right-click Start → Disk Management) and look at what Windows actually sees, because the answer is in that window and nowhere else.

What you'll see, and what each view means. A disk with a partition, a filesystem (NTFS, exFAT, or FAT32), and a letter → it should be in Explorer; if it's not, the letter is conflicting or the Explorer view is filtering it — check the removable section of This PC, and if the drive is genuinely missing, reassign the letter (right-click the partition → Change Drive Letter and Paths → Add, picking a letter nothing else uses; a low-risk, non-destructive change that touches the label, not the data). A partition that says RAW → the filesystem is damaged or foreign; if the drive holds data you need, this is the data-safety line — copy whatever will copy, and do not run a format or a “repair” that writes to the disk; if the drive is expendable, a format is the reset (and it's destructive, which is why the data question always comes first). A disk that says Unallocated across its whole length → there's no partition at all, either because it was last formatted on a system that used a layout Windows doesn't auto-create (some Mac and Linux layouts) or because the partition table is gone — and “Unallocated” on a drive that held files is a data event, not a configuration one, so the data-safety rules apply with full force.

The failure paths, and the power note. If Disk Management doesn't show the disk at all even though Device Manager does, you're not in this guide's case — you're in the no-disk case (the enclosure or drive layer), and the data risk is higher there, so that's where you go. And the storage-specific power note: a flash drive that's recognized but whose volume shows up and then disappears is often a power or connection marginality (the path guide), and a drive that's doing that with data on it should be copied now, not diagnosed later — a volume that can't stay mounted is a volume that's going to stop mounting, and the copy is the only step whose value doesn't decay while you decide.

External hard drives add a layer flash drives don't have: the enclosure. A “USB hard drive” is a drive, plus a bridge chip (the enclosure's electronics that translate USB to the drive's interface), plus a cable, plus — for a 3.5-inch drive — a power brick, and each of those can be the “not detected” while the others are perfectly fine. The first fork is mechanical: does the drive spin up? You should hear or feel it — a 2.5-inch drive is a faint hum, a 3.5-inch is obvious — and a drive that's silent when it should be spinning is a power or a drive problem before it's a USB problem. The 3.5-inch note is its own case and its own classic: those drives need their external power supply in addition to the USB cable, and a 3.5-inch drive on a cable alone will enumerate as a USB device and then have no disk — which looks exactly like a dead drive and is actually a missing plug.

The sequence, in the order that catches the most cases. Power first — the brick in, for a 3.5-inch drive, and a known data cable for everything (a charge-only cable on an external drive is the classic silent failure — the drive gets power and no data, which is indistinguishable from “not detected” at arm's length). Spin-up second — if it's silent, the power path is the suspect before any software step, and no amount of Device Manager work changes a drive that isn't spinning. Then the two panels: Device Manager (does the USB device enumerate?) and Disk Management (does the disk appear?). The result matrix is short and decisive: device and disk → a visibility or letter case (the flash drive guide's Disk Management reading applies); device, no disk → the bridge chip or the drive (the no-disk guide, data-first); no device → the cable, the port, the power, or the enclosure's controller (the path guide). What a healthy drive does: spins up, makes the connection sound, and shows a disk in Disk Management within a few seconds — if yours does that, the rest of the problem is a Windows configuration matter, which is the good-news half of this guide.

The data warning, stated where it belongs. An external drive is the most common “important data on a USB device” case, and the failing-drive signs are most visible here — a drive that spins up but takes an eternity to be found, one that clicks, one that was fine on Tuesday. If the drive has data and any of those signs are present, the order is: stop, copy what will copy (a straight file copy, while it reads, no tools in between), and if it won't copy reliably, escalate to a professional image — the when-to-stop section is the full version of this reasoning. A drive that's healthy and merely not showing has no data urgency and can take the whole ladder at its own pace; a drive showing failure signs has exactly the opposite priority. Confusing those two — spending an hour on driver steps while a failing drive sits in the port — is the most expensive mistake on this page, and the one the data-safety section exists to prevent.

The specific state: the USB device is recognized — the sound played, Device Manager is happy — but for a storage device, no disk appears in Disk Management. That's a narrow and important state, because it localizes the fault to the layer between the USB connection and the disk. For an external drive, that layer is the enclosure's bridge chip or the drive itself; for an internal drive on a USB-to-SATA adapter, it's the adapter or the drive. The USB side is proven fine (the device enumerated), the disk side is proven absent (no disk), so the fault sits in between — and “in between” for a USB drive is almost always the enclosure or the drive, weighted by what the drive is doing mechanically.

What to check before you conclude, because this state has impostors. Is the device node really the storage device — some enclosures present as a generic mass-storage node, others as a hub plus storage, and if you see a hub node with no storage node, the bridge is the suspect. Does the drive spin — a silent drive is a power or drive problem wearing this state's costume, and the external drive guide's power-first rule applies. Does the node appear and disappear — a marginal bridge or a dying drive's controller, and a data-risk sign that changes the priority. And what does the node say — a clean “USB Mass Storage Device” versus one carrying a warning reads differently. The one test that splits the state: the same drive in a different enclosure, or on a different interface (a USB-to-SATA adapter, another machine's port). Drive found there → the original enclosure's bridge is the fault, and a bridge failure is a repair-or-replace decision about the enclosure, not the drive. Drive not found anywhere → the drive is the fault.

The data line, stated plainly, because this is where it's strictest. “Device fine, disk absent” on a drive that held files is the signature of a drive failing to come up — and a drive failing to come up is a drive you should not be running diagnostic loops against. If there's data: stop, and the options are a careful copy attempt if it will come up intermittently (a straight copy while it reads, no utilities, no “optimization”), or a professional image if it won't, or if it's making mechanical noises — clicking and grinding in particular mean rest, not retries. If there's no data: it's a hardware question, the enclosure-swap test decides which component, and the answer for both components is replacement, not home repair — neither a bridge chip nor a failed drive is a soldering project at this point. The when-to-stop section below is the version of this paragraph with the full decision logic.

The power side of “not recognized.” USB devices get their power from the port (bus-powered), and the port has a budget — a standard USB 2.0 port is 500 mA, USB 3.x is 900 mA — and a device that wants more than its port can give fails in ways that look exactly like recognition problems: it enumerates and drops, it works until another device joins the bus, it works on a rear port and not a front one. Layer on top of that Windows' own power management — USB selective suspend, which puts idle hubs to sleep and wakes them on demand, and the per-device “allow the computer to turn off this device to save power” setting — and you have a whole category of faults that are power-policy problems, not hardware problems. The good news: every one of them is a reversible configuration change, which is what makes this guide a fix rather than a diagnosis.

The sequence, cheapest first. Physical power, before settings — a rear port (full budget, direct to the board), a powered hub for a high-draw device (a powered hub gives the device its own supply and removes the budget question entirely), and a different cable (a marginal cable adds resistance and drops the voltage at the device, which reads as a power fault and is the most common impostor of this whole category). Then the settings: Power Options → Change plan settings → Change advanced power settings → USB settings → USB selective suspend setting → Disabled — a low-risk, reversible change; test the device through a full sleep-and-wake cycle afterwards, because that's the condition selective suspend governs. And in Device Manager, the device's node → Properties → Power Management → uncheck “Allow the computer to turn off this device to save power” — the known culprit for specific devices that fail to wake, and the one worth trying on any device with a flaky wake. What to expect: a power-budget fault clears when the device gets real power and stays cleared; a selective-suspend fault clears when the device survives the sleep/wake test.

The failure paths, and the tell that sorts them. If the device drops under load specifically — fine while idle, dead when the drive spins up or a big copy starts — that's a power-budget or cable fault, and the powered-hub test is the decider: if it works through a powered hub, the budget was the problem and the powered hub (or a rear port for lower-draw devices) is the fix, not a workaround. If it drops on sleep/wake specifically, selective suspend or the per-device power setting is the problem, and the settings above are the fix. And the data-risk branch, stated because it overrides the rest: if the device drops at random with no pattern, and it's a storage device with data on it, that's a data-risk sign before it's a settings question — a drive that's dropping randomly is a drive to copy now, not a drive to configure, and the power settings are a story for after the files are safe.

The controller level. Under every port in Windows sits a controller node — a “USB xHCI Controller” (the modern one), an “eHCI” (the legacy USB 2.0 one), and a tree of “USB Root Hub” nodes representing the port groups. When the fault is at this level, the symptom is broader than one device: several ports on the same controller misbehaving, a Code 43 on a hub or controller node, USB devices failing after a Windows update, or a controller that enumerates but whose hubs don't come up. This guide is for that broader fault, and it's a deliberately different procedure from the device driver guide — the steps are related, the caveats are different, and mixing them up is how this fix goes wrong.

The working reset, with the caveat that makes it its own guide. The move is to make Windows tear down and rebuild the USB controller stack: in Device Manager → Universal Serial Bus controllers, right-click each “USB Root Hub” and the xHCI/eHCI controller nodes → Uninstall device. Do not tick “attempt to remove the driver software for this device” on the controllers — you want Windows to re-enumerate the hardware on reboot, not to delete the built-in driver packages, and deleting them is the specific way this procedure backfires (the packages are part of the OS and a “clean” delete just creates a worse state to clean up). Then restart the computer: on boot, Windows re-enumerates every USB controller and hub from scratch, and a wedged controller state — the kind an update or a power event leaves behind — clears on the rebuild. What to expect: a moment of “installing drivers” on boot, and then every port working as if nothing happened.

When it's not a re-enumerate. If a clean rebuild doesn't clear the controller fault, the branches are short. A specific controller that's hardware-failed — multiple ports on it dead, a Code 43 that survives the re-enumerate — is a board-level fault: on a laptop it's a repair decision, on a desktop the port group is simply out of service and the other controller's ports carry on (the when-to-stop section is the version of this with the full reasoning). A BIOS or firmware setting that's misconfigured — some boards expose a legacy-USB / xHCI hand-off option that, set wrong, breaks specific older devices; it's a board-specific setting, it's in the manual, and it changes one at a time with the known undo. And a Windows update that broke the stack — the after-update guide has the update-rollback path, which a re-enumerate can't reach. The order is re-enumerate → update check → the hardware conclusion, because the first two are free and reversible and the last one is a decision.

The timing clue that changes the diagnosis. “It worked before the update and not since” is the most useful sentence in USB troubleshooting, because it converts an open search into a bounded one: the update is the suspect, and the update did one of a short list of things — pushed a new USB driver, changed a power default, updated the controller stack, or (on a managed machine) applied a policy. Each of those has a specific undo, and each undo is cheaper than a fresh diagnosis from scratch. The first job is to confirm the timing honestly, because a “broke after an update” that turns out to be a coincidence sends you down the wrong path: Settings → Windows Update → Update history is the record, and the question is whether the device's last known-good moment genuinely precedes the update's install. If the device was already flaky before the update, the update was a red herring and the normal ladder applies.

The sequence, cheapest undo first. The re-enumerate — the controller guide's move: an update that wedged the controller stack clears on a clean rebuild, it's free, and it's the most common actual fix for “USB broke after an update.” The driver rollback — Device Manager → the device's node → Properties → Driver → Roll Back Driver, available only when the update pushed a new driver version and the previous one is still on the machine; if the button is there, it's the most direct undo of a bad driver push, and it's worth trying before the broader uninstall. The power-default check — an update that flipped a power plan default shows up in the selective-suspend setting, and the power guide's path is where to look. Uninstalling the update itself — Settings → Windows Update → Update history → Uninstall updates: a real undo, reversible in both directions, but it takes the whole update back (security updates included, until they re-apply), so it's the last move, not the first, and the one to reach for only when the device matters more than the update it's breaking. What to expect: a rollback or re-enumerate fix is immediate — the device works on the next plug-in; an update-uninstall fix comes after the reboot the uninstall requires.

The work-machine branch, and the failure path. If this is a work or school machine, add the policy branch before going further: an update from the organization can apply a group policy that blocks removable storage or specific device classes, and that presents as “not recognized” with no warning icon anywhere — because from the device's point of view nothing is wrong, it's simply not being allowed. The tells are that it's a managed machine and the change arrived with an organizational update; the fix is the IT team, not a setting you can safely touch, and deliberately so — editing the policy to work around a block is the “disable the security feature to make the hardware work” move this page doesn't recommend, for you or for the machine's owner. And the failure path for the whole guide: if the honest timing check doesn't hold, or if the update is uninstalled and the fault returns with the next one, the update was a trigger on top of a weaker underlying cause (a marginal cable, an aging port, a failing device), and the normal ladder — starting with the other-computer test — is where the real cause gets named.

The special case: your input device is the thing that's dead, which makes the normal “open Device Manager and look” steps harder to run, because you need a working input to run them. So the first move is to get any input. A different USB port (a USB 2.0 port for an older device; a different USB-C port for a USB-C keyboard or mouse — the capability rules from the USB-C guide apply and a charge-only port is a classic “dead keyboard”). A different cable or connector, where the device has one. A PS/2 port if the machine has the old round one — still alive on some desktops and the most reliable fallback that exists. A Bluetooth input if one will pair — it bypasses the USB path entirely, which is also a diagnostic, because if Bluetooth works and USB doesn't, the USB path is the suspect. Or a second machine to run the driver steps against, if this one is fully locked out. Get input first; diagnose second — it sounds obvious and it's the step that gets skipped most.

The device-side checks, because a large share of “dead” input is battery. Before any computer-side step: a wireless keyboard or mouse with a dead or low battery presents as a recognition problem from the computer's point of view only in the specific case where the dongle connects but the device never talks — check the device's LED, try fresh batteries, and for a dongle device, reseat the dongle in a different port (the dongle is a USB device too, and it has the same port and cable failures as everything else). A Bluetooth device that's paired to a different machine — it's connected elsewhere, not to you, and “not recognized” here is the honest description of a device that's busy. A device in a low-power state — some keyboards have a physical switch or a hold-to-wake behavior, and a “dead” device that's actually just off is the cheapest fix in the category. The LED is the tell throughout: a device with no LED at all is a power or battery problem before it's a USB problem, and fresh batteries clear more “dead wireless mouse” cases than any driver step on this page.

The computer-side, once you have input in hand. With something you can type or click with, the diagnosis narrows to the standard ladder: Device Manager → is the keyboard or mouse node there? A missing node with the device in a known-good port is a port or controller fault — the dead-port guide; a node with a warning is a driver fault — the driver guide, with the controller re-enumerate as the reset when the warning is on a hub. A different port, because a device that works in one port and not another has the port named in one test. And the other-computer test, which for a keyboard or mouse is the cheapest version of all — any machine will do, and a mouse that works on a neighbour's laptop is a mouse cleared, full stop. What a healthy input does: works within a few seconds of plugging in, with no driver install needed (the generic HID driver is built into Windows) — and if it doesn't, the node in Device Manager is where the answer is, one way or the other.

The advanced layer, and the line. Past the controller re-enumerate and the driver rollback, the remaining USB problems form a short list, and each one has a stop built into it. A Code 43 that survives reinstall, re-enumerate, and the other-computer test — a device reporting a fault to every machine it's been tried on is a failed device, and the answer is replacement or a warranty claim, not a deeper setting. A port that kills the PC on insertion — a reboot or power-off the moment a device goes in is a short circuit on the device or the port, and this is a hard stop, because every test you run re-applies the short and both the device and the port are damage suspects until a technician checks them; do not “try it once more.” A controller dead after a re-enumerate — a board-level fault: a repair decision on a laptop, a permanently lost port group on a desktop (the other controller's ports carry on, and the machine is usable). And a storage device showing failure signs with data on it — the data line: stop configuring, copy or image, and let a professional handle a drive that's clicking.

The genuinely advanced knobs, for the cases that are still a settings question and not a hardware conclusion. These are board-level, and they carry the “one at a time, know the undo” rule: the BIOS legacy-USB / xHCI hand-off option — some boards let you change how USB 2.0 devices are handed off at boot, and a specific older device that fails on a modern xHCI-only configuration can be fixed by the legacy option; it's a board-specific setting, it's in the manual, and the undo is setting it back to default. A USB 2.0 mode for a port group — the same family of board options, for the cases where a device wants the older protocol. And the powered-hub architecture for a high-draw device that outgrows a port's budget — not a setting, a component: a powered hub is the permanent fix for a device that needs more than 900 mA, and it's the answer that makes “it only works sometimes” stop being a thing. None of these are “try them all” moves; each one is for a specific diagnosis, and the ladder earlier on this page is what produces the diagnosis.

When to stop, collected, so the rule is in one place. A short (the PC dies on insertion) — stop; the device and the port are both suspects and a technician is the next step, not another plug-in. A failing drive with data — stop configuring; copy or image. A device that fails on every machine — stop diagnosing; it's a replacement or an RMA, and the evidence you've gathered (which ports, which cables, which machines) is exactly what the warranty form asks for. A dead controller after a re-enumerate — stop; it's a board fault, and the decision is repair versus living with the other port group. A work machine with a policy block — stop; it's IT, and working around the policy is not a fix you should be making. Everything else on this page is reversible and cheap, and the reason the page is organized the way it is is so you reach one of these stops only after the reversible steps have either fixed the problem or named the component that's left. The checklist below is the reversible steps in order; this guide is what's past them — and knowing the difference is the whole point of the advanced section.