You plug in a keyboard and nothing happens. You try a flash drive and get the same silence. When USB ports not working becomes your afternoon, the cause nearly always sits in one of four layers: the device, the cable or port, Windows, or the firmware on the motherboard. This tutorial checks all four in a fixed order, so you stop guessing and start isolating.
Wired controllers are a common casualty. If a USB pad keeps dropping out during cloud play, our Xbox Cloud Gaming not working fix covers the network side, while this guide covers the port side. Rule out both before you blame the controller.
The guide targets Windows 11 desktops as of November 1, 2026, although most steps also work on laptops. You need only built-in tools (Device Manager, PowerShell, pnputil, powercfg) and a screwdriver for the case-side checks. At the end you get a diagnostic script you can keep and rerun the next time a port misbehaves.
Why USB Ports Stop Working: The Four Failure Layers
A USB port is the visible end of a long chain. The connector on the back panel wires to a controller, the controller talks to a driver stack inside Windows, and the stack answers to power rules set by Windows and the BIOS. A break anywhere in that chain looks identical from the outside. Nothing lights up, nothing mounts, and the device may even vanish from Device Manager.
The first layer is the device and its cable. A dead flash drive, a charge-only cable or a worn connector produces the classic USB not recognized pop-up, and it fools people into thinking the port failed. The second layer is the port itself, including the front-panel header cables inside the case. Bent pins, a loose header plug and a shorted port can each take out a whole group of ports at once.
The third layer is Windows. Drivers can corrupt, power management can cut power to a hub and never restore it, and a half-finished update can leave a controller in an error state. This layer causes most of the cases where ports work after a reboot but fail after sleep. The fourth layer is firmware. BIOS settings can disable a controller, hand it off to the operating system badly, or cut standby power to the ports. A BIOS update can reset those options, which is why ports sometimes die right after one.
Knowing the layers changes how you test. Each step below eliminates one layer or one part of it, and every step tells you what its result means. If a step does not fix the problem, you still gain information, and you move on with a smaller search space. That discipline separates a quick, methodical fix from an evening of random driver installs.
Prerequisites and Tools
Gather these before you start. None of them cost money, and you probably own most of them already.
- Windows 11, fully updated through Windows Update. The steps assume the current Settings app layout.
- Windows PowerShell (built in). The commands in this guide are written for it, so you need nothing extra.
- An administrator account. Driver removal, power plan changes and registry edits need an elevated window.
- One known-good USB device that you have recently seen working on another computer, plus a second cable of a different type if the device uses a detachable one.
- A non-USB way to control the PC if your only keyboard and mouse use the dead ports. A Bluetooth keyboard, a PS/2 port (some boards still have one) or remote access from another computer all work.
- Your motherboard model. Run
Get-CimInstance Win32_BaseBoardin PowerShell if you do not know it. You need the model to find the right BIOS menu names and manual. - A small Phillips screwdriver for the case panel, and a flashlight for checking header cables.
Create a restore point before Phase 2. Search for Create a restore point in the Start menu, pick your system drive and click Create. The registry and driver steps are safe, but a restore point costs one minute and gives you a way back.
Triage Matrix: Match Your Symptom to the Right Step
Different symptoms point at different layers. Find your row first, then jump to the listed step if you want to skip ahead. If nothing matches, start at Step 1 and work down.
| Symptom | Most likely layer | Start at |
|---|---|---|
| One device fails everywhere, other devices work | Device or cable | Step 3 |
| One port is dead, neighbours work | Port or header | Step 10 |
| All front ports dead, rear ports fine | Front-panel header | Step 10 |
| Ports die after sleep or after idle time | Windows power management | Step 5 |
| Ports die after shutdown but work after restart | Fast Startup | Step 6 |
| Yellow warning icon in Device Manager | Driver | Step 4 |
| Every port dead, even at the BIOS screen | Firmware or hardware | Step 11 |
| Ports work in BIOS but not in Windows | Windows driver stack | Step 7 |
| Ports stopped right after a Windows update | Driver regression | Step 8 |
| Devices connect, then disconnect under load | Power budget or hub | Step 12 |
Phase 1: Isolate the Fault (Steps 1 to 3)
Phase 1 costs nothing and takes about ten minutes. It decides whether your USB ports not working problem is a software fault, a firmware fault or a physical one. Skipping it is the most common reason people spend an evening reinstalling drivers for a bad cable.
Step 1: Map Which Ports Fail
Take a sheet of paper and draw the back panel and the front panel. Plug your known-good device into every port, one at a time, and mark each as working or dead. Wait a full five seconds on each port, because a slow enumeration can look like a failure.
The pattern matters more than the count. A dead cluster of neighbouring ports usually shares one hub chip or one header. A dead front panel with healthy rear ports points at the internal cable. If every port fails identically, suspect the controller, the driver or the BIOS. If only the ports on one side of the board fail, the board may route them through a secondary controller that has crashed.
Note the port colour or label where you can see one, and note which ports host your keyboard and mouse. Some boards give those a dedicated controller. That detail explains why a PC can boot, show the BIOS and accept keystrokes while a different port group sits dead.
Step 2: Do a Full Power Drain
A restart does not reset a USB controller that has latched into a fault state. A full drain does. Shut the PC down from the Start menu, switch off the power supply with the rocker at the back, and unplug the power cable. Press and hold the case power button for a few seconds to discharge the board. Wait a minute, plug everything back in and boot.
While the cable is out, unplug every USB device except the keyboard. Peripherals that draw too much current or short a data line can trip a port group and keep it tripped. The same hold-and-drain logic fixes many console power faults, as our PS5 won’t turn on guide shows, and it costs you nothing to try here.
If ports return after the drain and fail again days later, you have a recurring trigger. Sleep, Fast Startup and USB selective suspend are the usual suspects, and Steps 5 and 6 target them directly. If ports stay dead, continue to Step 3.
Step 3: Rule Out the Device and the Cable
Test the suspect device on a second computer. If it fails there too, the device or its cable is the problem and the PC is innocent. Swap the cable next, because cables fail far more often than people expect. Charge-only cables look normal and carry no data lines, so a phone that charges but never appears in File Explorer often has the wrong cable.
Then test the opposite direction. Plug a device that you know works into the port that seemed dead. Two clean outcomes exist. The known-good device works, so your original device was the fault. Or the known-good device fails, so the port or the stack behind it is the fault. Do not skip this cross-check. It turns a vague feeling into a fact.
Pay attention to how the failure presents. A device that triggers the USB not recognized balloon means Windows detected electrical activity but could not read the device descriptor. A device that triggers nothing at all means no electrical contact or no power. That difference decides whether you look at drivers next or at the connector.
Phase 2: Fix the Windows Side (Steps 4 to 8)
If the known-good device also fails, or the failures follow sleep and updates, work through the Windows layer. Back up anything important first. Microsoft shipped a fix for a bug that broke File History backups, so check that your File History backups actually completed before you touch drivers.
Step 4: Read Device Manager and the PnP Inventory
Press Win + X and open Device Manager. Expand Universal Serial Bus controllers and look for yellow warning triangles, unknown devices and entries labelled with an error. Also open View and tick Show hidden devices. Greyed-out entries are devices Windows remembers but cannot reach, and a long list of them can mean stale driver bindings.
Device Manager is slow for a full survey, so pull the same data with PowerShell. Open an elevated window (Win + X, then Terminal (Admin)) and run:
# List every USB-class device Windows knows about
Get-PnpDevice -Class USB | Sort-Object Status |
Select-Object Status, FriendlyName, InstanceId |
Format-Table -AutoSize
# Show only USB entities that carry a problem code
Get-CimInstance Win32_PnPEntity |
Where-Object { $_.PNPDeviceID -like 'USB*' -and $_.ConfigManagerErrorCode -ne 0 } |
Select-Object Name, ConfigManagerErrorCode, PNPDeviceID |
Format-Table -AutoSize
The second command prints the numeric problem code for each failing device. Match it against the table below. A healthy PC prints nothing for the second command.
| Code | What Windows means | Usual fix |
|---|---|---|
| Code 10 | The device cannot start | Reinstall the driver (Step 7) or update the chipset driver (Step 8) |
| Code 22 | The device is disabled | Right-click the entry in Device Manager and choose Enable device |
| Code 28 | No driver is installed | Install the chipset package from the board maker (Step 8) |
| Not listed | Windows stopped the device after it reported a problem | Swap the cable, test another port, then reinstall the controller |
| Not listed | The device is not currently connected | Reseat the device, then check the port and cable |
A device error on a single device with a clean controller list points back at that device. The same error on a USB controller entry means the controller itself is unhappy, and that is more likely a driver or firmware question.
Step 5: Turn Off USB Selective Suspend and Hub Power Saving
USB selective suspend lets Windows power down individual ports when they look idle. In theory it saves a little energy. In practice it is one of the most common reasons a keyboard, mouse or external drive goes dead mid-session and refuses to wake. On a desktop plugged into the wall, the energy saving is negligible, so turning it off costs you nothing.
Use the graphical route first. Open Control Panel, then Power Options, click Change plan settings for your active plan, then Change advanced power settings. Expand USB settings and USB selective suspend setting, and set both On battery and Plugged in to Disabled. Click Apply.
To script the same change, which helps across several PCs, let PowerShell look up the setting GUID instead of typing it from memory. This version assumes an English-language Windows install because it searches the powercfg output for the setting name:
# USB settings subgroup
$sub = '2a737441-1930-4402-8d77-b2bebba308a3'
$line = powercfg /query SCHEME_CURRENT $sub |
Select-String 'Power Setting GUID:.*USB selective suspend'
$guid = [regex]::Match($line.Line, '[0-9a-fA-F-]{36}').Value
powercfg /setacvalueindex SCHEME_CURRENT $sub $guid 0
powercfg /setdcvalueindex SCHEME_CURRENT $sub $guid 0
powercfg /setactive SCHEME_CURRENT
# Confirm: both index values should read 0x00000000
powercfg /query SCHEME_CURRENT $sub $guid
Now fix the per-device switch, because Windows also keeps a separate power rule on each hub. In Device Manager, expand Universal Serial Bus controllers and double-click each USB Root Hub and Generic USB Hub entry. Open the Power Management tab and untick Allow the computer to turn off this device to save power. Repeat for every hub entry. Some entries have no Power Management tab, which is fine, so skip them.
Restart and test a long idle period. If your ports used to die after sleep and now survive it, you found the cause. Leave the setting off.
Step 6: Disable Fast Startup
Fast Startup does not fully shut Windows down. It saves the kernel state to disk and restores it at the next boot, which means a controller stuck in a fault state can come back stuck. The symptom is distinctive. Ports die after a normal shutdown and cold boot, but work after a restart, because restart skips the saved state.
Open Control Panel, then Power Options, then Choose what the power buttons do. Click Change settings that are currently unavailable, untick Turn on fast startup (recommended) and save. To do it from an elevated terminal, write the registry value directly:
reg add "HKLMSYSTEMCurrentControlSetControlSession ManagerPower" /v HiberbootEnabled /t REG_DWORD /d 0 /f
# Verify
reg query "HKLMSYSTEMCurrentControlSetControlSession ManagerPower" /v HiberbootEnabled
The query should print HiberbootEnabled REG_DWORD 0x0. Shut down fully, wait ten seconds and power on. Your boot gets a few seconds slower on a hard drive and barely changes on an NVMe drive, and in return every boot re-initialises the USB stack from scratch.
Step 7: Remove and Reinstall the USB Controllers
If Device Manager showed errors, or ports work in the BIOS but not in Windows, force Windows to rebuild its USB device tree. When Windows rescans, it detects the controllers again and installs fresh drivers from its own driver store.
A warning first. Removing the host controllers also removes the USB keyboard and mouse hanging off them until the rescan finishes. Do this with a Bluetooth keyboard or a PS/2 device, or run the whole sequence as a single pasted block so it finishes without your input. The block below removes every host controller entry and then rescans:
# Run in an elevated terminal. Input devices on USB will drop for a few seconds.
$controllers = Get-PnpDevice -Class USB |
Where-Object { $_.FriendlyName -match 'Host Controller' }
foreach ($c in $controllers) {
Write-Host "Removing $($c.FriendlyName)"
pnputil /remove-device $c.InstanceId
}
pnputil /scan-devices
Start-Sleep -Seconds 10
Get-PnpDevice -Class USB | Select-Object Status, FriendlyName | Format-Table -AutoSize
The final table should list your controllers again with OK in the Status column. If it does not, restart the PC and Windows finishes the job during boot. The graphical alternative is to right-click each controller in Device Manager, choose Uninstall device, leave the driver-deletion box unticked and restart.
Do not tick Attempt to remove the driver for this device unless you have the chipset package ready. That option deletes the driver files, and you want Windows to reuse its own copy for this test. If the ports now work, a corrupted binding was the cause.
Step 8: Update the Chipset Driver, or Roll Back a Bad One
Generic Microsoft drivers run most USB controllers, but the board maker’s chipset package adds the vendor-specific pieces for the extra controllers many boards carry. Download the package for your exact board from the board maker’s support page, because the package from a different board can install the wrong components. On AMD systems the chipset package comes from AMD’s support pages. Intel boards use the Intel chipset INF utility plus the board maker’s own USB driver where one exists.
Install it, restart and test. If the problem began right after a Windows or driver update, the opposite move can fix it. In Device Manager, double-click the failing controller, open the Driver tab and click Roll Back Driver if the button is active. When it is greyed out, uninstall the most recent cumulative update from Settings, then Windows Update, then Update history, then Uninstall updates. Pause updates for a week while the vendor ships a fix.
The same bisect-the-change habit applies across hardware: find what changed last, undo it, and test. Record the date of every change you make, because the timeline often points straight at the culprit.
Phase 3: Check Firmware and Hardware (Steps 9 to 12)
If the Windows layer is clean and you still have USB ports not working, the cause sits below the operating system. Phase 3 covers the event log, the BIOS, the physical connections and the power budget. These steps need the case open and about fifteen minutes.
Step 9: Read the Event Log for USB Errors
Windows logs controller resets, enumeration failures and power surprises. Reading them tells you whether the fault is constant or intermittent, and whether a specific device triggers it. Query the System log for recent warnings and errors from USB and plug-and-play sources:
Get-WinEvent -FilterHashtable @{
LogName = 'System'
Level = 2, 3
StartTime = (Get-Date).AddDays(-7)
} -ErrorAction SilentlyContinue |
Where-Object { $_.ProviderName -match 'USB|Kernel-PnP|usbhub|usbxhci' } |
Select-Object -First 25 TimeCreated, ProviderName, Id,
@{ n = 'Message'; e = { ($_.Message -split "`n")[0] } } |
Format-Table -AutoSize -Wrap
Read the timestamps first. Errors that cluster at the moment you plugged something in implicate that device. Errors that appear on resume from sleep implicate power management. Repeated controller resets at random times with no user action often mean an overcurrent condition or a failing hub chip. An empty result is useful too, because it suggests the problem lives in firmware or hardware rather than in the driver stack.
Step 10: Check BIOS Settings and the Front-Panel Header
Restart and enter the BIOS with Del or F2, depending on your board. If your keyboard is dead at this point too, the fault is below Windows, and a PS/2 keyboard or a rear-panel port next to the CPU often still works. Look for the options in the table. Names vary by vendor and BIOS version, so match by meaning and not by exact wording.
| Option (typical name) | What it does | Setting to try |
|---|---|---|
| xHCI Hand-off | Lets the operating system take over USB 3 controllers from the firmware | Enabled |
| Legacy USB Support | Keeps keyboards and mice usable before Windows loads | Enabled, or Auto |
| USB Controller or xHCI Mode | Switches the USB 3 controller on or off | Enabled, or Smart Auto |
| Per-port enable or disable | Turns individual rear or front ports off | Enabled for every port |
| USB power in standby (S5) | Keeps ports powered while the PC is off | Match your charging needs |
| ErP | Cuts standby power to save energy | Disabled if ports stay dead after shutdown |
If you recently changed BIOS options or updated the BIOS, load the optimised defaults and then re-apply only the settings you need. A BIOS update can silently reset the USB options above, which explains the common report of ports that died right after a firmware flash.
Now open the case with the PC unplugged. Follow the thin cables from the front-panel ports to the motherboard. Older USB headers are small blocks of pins with one position blocked, and the newer, faster headers are wider keyed blocks. Reseat each plug by pressing it straight down until it seats fully. Check that no plug sits one row off, since a shifted header plug can short pins and kill a port group. Also confirm that every USB plug sits on a USB header, not on a similar-looking fan or audio header.
While you are inside, look at the rear-panel ports with a flashlight. Bent tongues, burn marks or a loose connector body all show up under light. A port that wobbles in its socket may have a cracked solder joint, and that repair belongs with a technician.
Step 11: Clear the CMOS and Run a Minimal-Boot Test
Clear the CMOS next, which restores every BIOS option to factory state and flushes any corrupted setting. With the PC unplugged, press the clear-CMOS button on the board, or move the jumper according to your manual, or pull the coin battery for a minute. Reseat it, plug in and boot. You will need to re-enter the time and any custom options such as memory profiles.
Then try a minimal boot. Remove every USB device except one keyboard. Disconnect front-panel USB cables from the board. Leave only the keyboard in a rear port and boot into Windows. If that keyboard works and the problem ports now behave, one of the removed components was dragging the controller down. Add things back one at a time until the fault returns. The last item you added is the culprit.
If the minimal setup still fails, the controller may be physically damaged, perhaps by a static discharge or a shorted device. At that point you have a useful fact for any warranty claim: the fault survives a reset, a minimal boot and a driver reinstall.
Step 12: Audit Hubs and the Power Budget
Intermittent failures under load often come from power, not data. Every port group shares a limited current supply. An unpowered hub packed with a webcam, an external drive, a charging phone and an RGB controller can exceed it, and the port then resets and drops everything. The device list flickers, Windows plays the connect and disconnect sounds repeatedly, and the event log shows controller resets.
Fix it in three moves. First, move high-draw devices such as external hard drives straight into rear-panel ports on the board. Second, replace any bus-powered hub with a hub that has its own power adapter. Third, keep devices that need dependable bandwidth, like audio interfaces and capture cards, off shared hubs altogether.
Check long cables as well. Long extension cables and cheap passive extenders degrade the signal and the voltage, which can make a device flicker between USB 3 and USB 2 behaviour. Replace them with short, certified cables and retest.
Phase 4: Verify and Lock In the Fix (Step 13)
Step 13: Verify, Stress-Test and Document
A port that works once is not a port that works. Run a short validation before you call the job done. Plug your known-good device into every port and confirm it appears in File Explorer or Device Manager within a few seconds. Put the PC to sleep, wake it and test again. Do a full shutdown, wait ten seconds, cold boot and test a third time. Leave the PC idle for a while and repeat the check.
Run the diagnostic script from the project section below and keep the report. Save a copy somewhere safe with the date. If the fault returns in a month, comparing two reports shows you what changed. Finally, write down what fixed the issue in a one-line note. The next time a port fails, the note saves you the whole tutorial.
What a Healthy Result Looks Like: Output Examples
Compare your output against these samples. The device names below are illustrative and your list will differ, but the structure and the Status values should match.
PS C:Usersyou> Get-PnpDevice -Class USB | Sort-Object Status | Format-Table Status, FriendlyName -AutoSize
Status FriendlyName
------ ------------
OK USB Composite Device
OK USB Input Device
OK USB Root Hub (USB 3.0)
OK Generic USB Hub
OK USB xHCI Compliant Host Controller
PS C:Usersyou> Get-CimInstance Win32_PnPEntity | Where-Object { $_.PNPDeviceID -like 'USB*' -and $_.ConfigManagerErrorCode -ne 0 }
PS C:Usersyou>
A blank result from the second command is the goal. Here is what a broken system looks like, with the telltale Unknown status and a problem code:
Status FriendlyName
------ ------------
Unknown Unknown USB Device (Device Descriptor Request Failed)
Error USB Root Hub (USB 3.0)
OK USB xHCI Compliant Host Controller
Name ConfigManagerErrorCode PNPDeviceID
---- ---------------------- -----------
Unknown USB Device (Device Descriptor Request Failed) 43 USBVID_0000&PID_00025&2A1B3C4D&0&3
The phrase Device Descriptor Request Failed is the classic text behind USB not recognized. It means Windows saw the device attach but could not read its identity. Cables, power and ports cause it far more often than drivers do, which is why Phase 1 comes first.
Common Pitfalls That Waste Your Evening
These mistakes show up again and again when people chase USB ports not working reports. Avoid them and you save time.
- Blaming the port when the cable is bad. Always run the cross-check in Step 3 before touching any setting. A swapped cable takes ten seconds.
- Testing with only one device. If your only test device is the broken one, you cannot tell a device fault from a port fault. Borrow a second device.
- Deleting controllers with a USB-only keyboard. The keyboard dies mid-command and you cannot finish the rescan. Use Bluetooth, PS/2 or a pasted script block.
- Ticking the driver-deletion box. Removing the driver files when you have no replacement package leaves the controller with nothing to load.
- Forgetting Fast Startup. A restart appears to fix ports, a shutdown breaks them again, and people conclude the fix is unreliable. The cause is the saved kernel state.
- Installing the wrong chipset package. Chipset packages are board and platform specific. Match the exact board model, not just the CPU brand.
- Skipping the power drain. A restart never resets a latched controller. Holding the power button for the full drain is not superstition.
- Overloading an unpowered hub. A hub without its own adapter shares one port’s current. Heavy devices make everything on it flicker.
- Changing several things at once. You cannot tell which change fixed it. Change one setting, test, then move on.
Troubleshooting: 10 Specific Problems and Fixes
If the main sequence did not resolve your case, find the closest match below.
1. A device works in the BIOS but not in Windows
The hardware is fine, so the Windows driver stack is at fault. Remove and rescan the controllers (Step 7), install the board maker’s chipset package (Step 8) and enable xHCI Hand-off in the BIOS (Step 10).
2. Ports work after restart but not after shutdown
Fast Startup restores a faulty controller state. Disable it (Step 6).
3. The keyboard or mouse dies after the PC sits idle
That behaviour points straight at USB selective suspend or the hub power-saving checkbox. Apply Step 5 in full, including the per-hub setting, and test again after a long idle stretch.
4. Windows says Unknown USB Device (Device Descriptor Request Failed)
Replace the cable, move the device to a rear port and unplug other devices. If it fails on every cable and every port, the device itself is faulty. If it works on another PC, drain the power on this one (Step 2).
5. Only the front-panel ports are dead
Reseat the header plugs on the motherboard and check the case’s internal cable for kinks. If the plug is firm and the cable looks fine, test the header with another case cable, since cable assemblies fail more often than headers do.
6. Ports died right after a BIOS update
The update probably reset the USB options. Enter the BIOS, load optimised defaults, then enable the USB controller, xHCI mode and Legacy USB Support. If that fails, clear the CMOS (Step 11).
7. The USB 3 device runs slowly or acts like USB 2
Check the cable first, then the port colour and label, then the hub in between. A damaged or low-quality cable often forces a fall back to the older mode. Test the device on a short cable straight into a rear-panel port.
8. Device Manager shows an error code on the root hub
Unplug everything on that hub and look for a shorted or overdrawn device. Then uninstall the hub entry and restart.
9. Every device connects, then drops a few seconds later
Suspect power. Remove bus-powered hubs and heavy-draw devices, test with one device, and watch the event log for controller reset entries (Step 9). A tired power supply can contribute, especially in older builds.
10. Nothing at all works, including in the BIOS
The controller may be damaged or disabled in firmware. Clear the CMOS, try a PS/2 keyboard if the board has the port, and test with a minimal setup. If that fails, a PCIe USB expansion card is a cheap workaround while you arrange a warranty repair.
Advanced Tips for Stubborn and Recurring Faults
Once the basics are done, a few extra habits make the fix last. For related PC upkeep, the hardware section collects our other repair and setup guides.
- Use a tree viewer. Free tools such as USBView or USB Device Tree Viewer draw every controller, hub and device in a tree, with power draw and speed per device. They show which hub a flaky device sits on and how the board routes its ports.
- Add a PCIe USB card. A card with its own controller adds ports that bypass a damaged onboard controller, and it spreads load away from a crowded one. Choose a card whose controller has stable Windows drivers.
- Watch for power plan resets. Some vendor utilities and OEM tools switch power plans in the background. If selective suspend keeps coming back, check which tool changes your plan and set the USB option in every plan.
- Keep a recovery stick. A bootable Windows installer on a flash drive lets you test whether ports work outside your installed system, which separates hardware faults from software ones.
- Log intermittent faults. Run the script below on a schedule, for example at each logon, and compare reports when the fault strikes. Patterns in timestamps often reveal the trigger.
- Mind the static. Ports that die after you touch a case or a device may have suffered a discharge. Ground yourself on the case before plugging in hardware, particularly in dry rooms.
One more habit pays off. Before a BIOS update, photograph or write down your USB-related options. After the update, compare them to the new values. That two-minute habit ends the mystery of ports that vanish after a firmware flash.
Complete Project: A Reusable USB Diagnostic Script
This script bundles the checks from the tutorial into one report. Save it as usb-doctor.ps1. By default it only reads and reports. With the -Repair switch and an elevated window it also turns off USB selective suspend, disables Fast Startup and triggers a device rescan. It does not remove any controllers, so your keyboard and mouse stay alive.
#Requires -Version 5.1
[CmdletBinding()]
param(
[switch]$Repair,
[string]$OutDir = "$env:USERPROFILEDesktop"
)
$stamp = Get-Date -Format 'yyyyMMdd-HHmmss'
$report = Join-Path $OutDir "usb-doctor-$stamp.txt"
$admin = ([Security.Principal.WindowsPrincipal][Security.Principal.WindowsIdentity]::GetCurrent()
).IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator)
if ($Repair -and -not $admin) { throw 'Run an elevated PowerShell window to use -Repair.' }
function Add-Report([string]$Title, $Body) {
$text = "`r`n=== $Title ===`r`n" + ($Body | Out-String -Width 200)
$text | Out-File -FilePath $report -Append -Encoding utf8
Write-Host $text
}
# 1. Host details
Add-Report 'Board' (Get-CimInstance Win32_BaseBoard | Select-Object Manufacturer, Product)
Add-Report 'BIOS' (Get-CimInstance Win32_BIOS | Select-Object SMBIOSBIOSVersion, ReleaseDate)
# 2. Controllers, hubs and devices
Add-Report 'USB devices' (Get-PnpDevice -Class USB | Sort-Object Status |
Select-Object Status, FriendlyName, InstanceId | Format-Table -AutoSize)
# 3. Anything with a problem code
$bad = Get-CimInstance Win32_PnPEntity |
Where-Object { $_.PNPDeviceID -like 'USB*' -and $_.ConfigManagerErrorCode -ne 0 } |
Select-Object Name, ConfigManagerErrorCode, PNPDeviceID
if ($bad) { Add-Report 'PROBLEM DEVICES' ($bad | Format-Table -AutoSize) }
else { Add-Report 'PROBLEM DEVICES' 'None found.' }
# 4. Power settings
$sub = '2a737441-1930-4402-8d77-b2bebba308a3'
$line = powercfg /query SCHEME_CURRENT $sub | Select-String 'Power Setting GUID:.*USB selective suspend'
$guid = if ($line) { [regex]::Match($line.Line, '[0-9a-fA-F-]{36}').Value } else { $null }
if ($guid) { Add-Report 'USB selective suspend' (powercfg /query SCHEME_CURRENT $sub $guid) }
else { Add-Report 'USB selective suspend' 'Setting not found (non-English Windows?).' }
$fs = (Get-ItemProperty 'HKLM:SYSTEMCurrentControlSetControlSession ManagerPower' -ErrorAction SilentlyContinue).HiberbootEnabled
Add-Report 'Fast Startup (HiberbootEnabled)' "Value: $fs (1 = on, 0 = off)"
# 5. Recent USB-related errors and warnings
$events = Get-WinEvent -FilterHashtable @{ LogName = 'System'; Level = 2, 3; StartTime = (Get-Date).AddDays(-7) } -ErrorAction SilentlyContinue |
Where-Object { $_.ProviderName -match 'USB|Kernel-PnP|usbhub|usbxhci' } |
Select-Object -First 25 TimeCreated, ProviderName, Id,
@{ n = 'Message'; e = { ($_.Message -split "`n")[0] } }
if ($events) { Add-Report 'USB events, last 7 days' ($events | Format-Table -AutoSize -Wrap) }
else { Add-Report 'USB events, last 7 days' 'None found.' }
# 6. Optional safe repairs
if ($Repair) {
if ($guid) {
powercfg /setacvalueindex SCHEME_CURRENT $sub $guid 0
powercfg /setdcvalueindex SCHEME_CURRENT $sub $guid 0
powercfg /setactive SCHEME_CURRENT
}
reg add 'HKLMSYSTEMCurrentControlSetControlSession ManagerPower' /v HiberbootEnabled /t REG_DWORD /d 0 /f | Out-Null
pnputil /scan-devices | Out-Null
Add-Report 'REPAIR' 'Selective suspend off, Fast Startup off, device rescan issued. Restart, then retest.'
}
Write-Host "`r`nReport saved to $report" -ForegroundColor Green
Run it from an elevated terminal. If PowerShell blocks the script, allow it for the current session only, which changes nothing permanent:
Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass
.usb-doctor.ps1 # read-only report on your Desktop
.usb-doctor.ps1 -Repair # report plus safe fixes, then restart
The report lists the board, the BIOS version, every USB device with its status, any problem codes, the selective suspend setting, the Fast Startup flag and the last week of relevant errors. Attach it to a warranty ticket or a forum post and the helper sees everything they need in one file.
When to Stop Troubleshooting and Replace Hardware
Software fixes have limits. When USB ports not working persists after every step above, and a CMOS clear, a minimal-device test and a fresh set of drivers all fail, the controller or the port is damaged. Static, a shorted cable or a surge usually causes that. You then have three realistic choices.
- Add a PCIe USB card. It costs little, installs in minutes and works around the damaged controller. Use it if the PC is out of warranty and the damaged ports are not critical.
- Claim warranty. If the board is still covered, send the diagnostic report and describe the tests you ran. A documented fault survives a vendor’s first-line questions much better than a vague complaint.
- Replace the board. This is the last resort and makes sense when several ports on several controllers have failed, which usually means the damage is on the board itself.
Do not open the power supply or attempt soldering unless you have the training. The safe boundary for a home fix is everything on this page. Past that, hand the board to a professional.
Frequently Asked Questions
Why are my USB ports not working after a Windows 11 update?
An update can replace a USB or chipset driver with a version that does not suit your board, or it can reset power settings. Roll the driver back in Device Manager, reinstall the board maker’s chipset package, and re-check the USB selective suspend setting. If the problem began with one specific update, uninstall that update and pause updates until a fix ships.
What does USB not recognized mean?
Windows detected something electrical on the port but could not read the device’s identity. The usual causes, from most to least common, are a bad cable, a faulty device, too little power and a damaged driver or port. Swap the cable and test the device on another computer before changing any settings.
Is it safe to turn off USB selective suspend?
Yes. On a desktop connected to wall power, the energy saving is tiny and the setting causes many wake and drop-out problems. On a laptop running on battery, turning it off can shorten runtime slightly, so you may choose to disable it only for the plugged-in profile.
Can a bad power supply cause USB ports to fail?
It can contribute. A weak or ageing supply can sag under load, which makes ports reset and devices disconnect. If devices drop out only when the system is busy, and a power drain plus a minimal setup does not help, test with a known-good supply.
Why do my front USB ports work but the rear ports do not, or the reverse?
Front and rear ports often hang off different controllers or headers. If only the front fails, check the internal header plugs and cable. If only the rear fails, suspect a controller, a driver or a BIOS option for those ports. The port map from Step 1 shows which group is affected.
Will reinstalling Windows fix dead USB ports?
It fixes software faults, but it will not fix a hardware or firmware fault. Test from a Windows installer stick first. If ports fail in the installer environment or the BIOS, a reinstall will not help, and you would lose time and settings for nothing.
Should I update the BIOS to fix USB problems?
Only after the earlier steps fail, and only if the board maker’s release notes mention USB fixes for your board. A BIOS update carries its own risk and can reset options, so write down your settings first and follow the maker’s flashing instructions exactly.