Peripherals: keyboards, mice, USB devices and printers that act out

What it looks like: the cursor moves (or a touchpad works) but nothing you type registers. The first fork in this problem is whether the keyboard works in BIOS/UEFI. If it does, the hardware, cable, and port are proven good and the failure sits in Windows: the USB controller driver, the HID class driver, or a recent update. If it doesn't work in BIOS either, you're dealing with a hardware or power problem, not a driver one.

Where it usually lives: a dead or loose USB cable, a port that lost power, a USB controller in error, or (on laptops) a keyboard connector issue. Driver-layer failures are less common for "totally dead" than for "works in BIOS, dead in Windows."

1. Test the keyboard in a different port on this machine, and a different keyboard in the original port — this one swap assigns the fault to the device or the PC.
2. Open Device Manager (devmgmt.msc) and check for a "HID Keyboard Device" and any USB controller with a warning icon; a Code 43 on the controller can kill every keyboard on that port group.
3. On a desktop, try a rear motherboard port directly — front-panel ports have their own failure modes (see the front-panel guide).
4. If it works in BIOS but not Windows, boot into Safe Mode: if the keyboard works there, a third-party driver or startup program is the cause, not the base OS.
5. Reinstall the HID and USB drivers (uninstall the device in Device Manager, then "Scan for hardware changes"), and update chipset drivers from the manufacturer.
6. If the keyboard is dead in BIOS on every machine, treat it as a hardware failure: cable, connector, or the board itself.

What it looks like: most of the keyboard works, but one or several keys are dead or sticky. This is the one keyboard problem where drivers almost never help — Windows doesn't manage individual key circuits. The pattern of the dead keys tells you what broke: one or two adjacent keys points at a local contact failure; a diagonal line of dead keys points at a shared matrix trace; all modifier keys misbehaving points at software.

Where it usually lives: debris under a key, a worn membrane or switch, liquid damage, or (for the modifier-key variant) accessibility settings and remapping software rather than hardware.

1. Open the on-screen keyboard (osk) and click the "dead" key. If it types there, Windows and drivers are fine and the physical key or its path is at fault.
2. Map exactly which keys fail and look for a pattern — adjacent pairs and diagonal lines are hardware signatures; scattered single keys across the board can indicate a connection or controller issue.
3. Power off, remove the keycap (if removable), and clean under it; compressed air and isopropyl alcohol resolve a large share of partial-keyboard failures.
4. For laptops, check whether the ribbon connector under the keyboard is reseatable — a partially loose flex cable shows up as random dead zones.
5. If the pattern is modifier-only, test with Sticky Keys and Filter Keys turned off (Settings → Accessibility → Keyboard) and with any remapping tool uninstalled.
6. When the pattern is a clear hardware signature and cleaning didn't help, a per-key repair or keyboard replacement is the realistic fix — further software testing will not change that outcome.

What it looks like: every key physically works, but the characters that appear don't match the key — symbols where letters should be, or consistently shifted output. Wrong-character problems are almost never hardware: the keyboard is sending the correct scancodes and something in the input pipeline is translating them differently. The usual suspects are the active keyboard language/layout, a stuck modifier, and remapping utilities.

Where it usually lives: the Windows language list (a second layout that got activated), a physically stuck Shift/CapsLock, or third-party remapping software that's still running in the background.

1. Type in Notepad and in a browser field. If the output differs between apps, the culprit is app-specific (a remapping tool or game software with a per-app profile), not the OS layout.
2. Check the language indicator in the taskbar; press Win + Space and cycle layouts until the correct one is active. Remove layouts you don't use (Settings → Time & language → Language & region → Keyboard).
3. Tap every modifier key several times and re-test — a half-stuck Shift changes every symbol, and a stuck CapsLock changes every letter.
4. Review installed remapping tools (AutoHotkey scripts, vendor keyboard software with "remap" profiles, gaming macros) and disable them one at a time.
5. If the layout is correct and no remapper is installed, reset the input method: remove and re-add the keyboard language, and check that the on-screen keyboard shows the same physical mapping as the screen.

What it looks like: characters appear with no input, a single character repeats, or random text shows up while the machine is idle. The pattern decides the diagnosis: one character repeating steadily points at a stuck or shorted key circuit; random words and commands point at something injecting input (software or malware); bursts only when pressing several keys at once is classic ghosting, a limitation of the keyboard's matrix.

Where it usually lives: a shorted switch or debris (repeating character), an injection-capable process or infection (random text), or the keyboard's electronics (multi-key bursts).

1. Identify the pattern first — which characters, at what cadence, and only under multi-key pressure or at any time. Write it down; it's the whole diagnosis.
2. For a repeating single character: unplug the keyboard and see if it stops (confirms source), then inspect/clean that key's switch and neighbors.
3. For random text: boot into Safe Mode. If the typing stops there, a third-party process is injecting input — remove recently added utilities, and run a full antivirus scan to cover the malware case.
4. Check for remapping or automation tools (AutoHotkey, macro software, "keystroke" utilities) in the startup list and disable them.
5. If the bursts only happen when pressing three or more keys simultaneously, it's ghosting — a hardware characteristic; anti-ghosting keyboards or N-key rollover models are the fix.

What it looks like: the keyboard drops and reappears — you get the connect/disconnect sounds or the cursor just stops mid-word, then returns. Every drop is an event Windows records, so this is a problem you can watch rather than guess at. The recurring drop pattern usually points at power delivery (a marginal cable or port, USB selective suspend) or a device that's failing to hold its connection, less often at a flaky hub.

Where it usually lives: the cable/connector, the specific port, a hub in the chain, or the power-management side of the USB stack. Driver corruption rarely produces a clean periodic drop/reconnect cycle — that rhythm is physical or power-related.

1. Catch it red-handed in Event Viewer (eventvwr.msc) → Windows Logs → System, filtering for Kernel-PnP and USB sources — the events will show exactly which device is re-enumerating and how often.
2. Move the keyboard to a rear motherboard port on a desktop; if the drops stop, the original port or front-panel header is the cause.
3. Remove any hub from the chain and connect directly.
4. Disable USB selective suspend (Power Options → Change plan settings → Advanced → USB settings) and re-test over a day of normal use including sleep cycles.
5. If drops continue on a direct rear port, swap cables (for USB keyboards) or test the keyboard on another machine to assign the fault before considering hardware replacement.

What it looks like: a 2.4 GHz wireless keyboard simply won't pair or won't stay found by its USB receiver. Keep the two wireless families separate from the start: a dongle-based keyboard talks to a specific receiver and has nothing to do with Bluetooth, so Bluetooth settings are irrelevant here. The failure is in the receiver link: power to the keyboard, the receiver's connection to the PC, radio range/interference, or a broken pairing between the two.

Where it usually lives: dead batteries, the receiver in a marginal port (or behind a USB 3.0 device that interferes with 2.4 GHz), a pairing that fell out, or the receiver itself.

1. Replace the batteries (or charge) and confirm the keyboard's power indicator behaves — a keyboard on weak batteries often "connects" for seconds, then drops.
2. Move the receiver to a rear port with no USB 3.0 device immediately beside it; 2.4 GHz dongles are genuinely sensitive to neighboring high-speed ports.
3. Re-pair using the vendor's procedure (usually a pairing key or a hold-combo on the keyboard) — not by unplugging and replugging, which only re-reads an existing pairing.
4. Test the receiver on another machine with the same keyboard: receiver dead elsewhere → receiver; keyboard pairs on another PC → this machine's port/stack.
5. If the keyboard also offers a Bluetooth mode, that's a clean fallback path and a useful diagnostic in itself — if Bluetooth works while the dongle doesn't, the receiver is the failed component.

What it looks like: the keyboard is in pairing mode, Windows sees it, but the pairing never completes — or it completes and immediately fails. Pairing and connecting are different steps, and most "won't pair" problems are actually stale-pairing problems: the keyboard is still bonded to another device (an old PC, a tablet, a phone) and won't form a new bond until the old one is cleared, on the keyboard side.

Where it usually lives: a leftover bond on the keyboard, a PIN mismatch, the adapter's driver, or the keyboard not actually entering pairing mode (power on is not the same as pairing mode).

1. Remove any existing bond for this keyboard in Windows (Settings → Bluetooth & devices → Devices → three-dot menu → Remove device) before attempting a fresh pair.
2. Put the keyboard into its documented pairing mode — usually a hold that makes an indicator blink rapidly. A steady light means powered, not pairing.
3. Add it from Settings → Bluetooth & devices → Add device. If a PIN is requested, try the keyboard's on-screen value, then a blank entry, then 0000 — keyboards disagree, and the manual says which.
4. If the keyboard was paired to another machine, unpair it there first (or reset the keyboard's Bluetooth memory per its manual) — a device bonded elsewhere will reject new bonds.
5. If pairing never completes on any keyboard, the problem is the adapter, not this keyboard — continue with the Bluetooth driver guide.

What it looks like: characters land a beat late, or typing in games feels "mushy" while the rest of the system seems fine. Input lag is a pipeline problem: the keystroke travels keyboard → port/hub → USB controller → driver → the app, and any congested stage adds delay. The two most common causes are a shared USB path that's saturated (a camera or external drive on the same hub) and system load spikes that starve the input thread.

Where it usually lives: a crowded hub, a USB 2.0 port carrying heavy traffic, high CPU load at the moments of lag, or — for the "delivered but slow" variant — Filter Keys and similar input-processing settings.

1. Turn off Filter Keys and Key Repeat changes (Settings → Accessibility → Keyboard) — Filter Keys introduces deliberate delay and is a common "mystery lag" cause.
2. Note when the lag happens: constantly, or in bursts? Bursts that line up with Task Manager CPU spikes point at system load, not the keyboard path.
3. Move the keyboard to a direct rear port, off any hub, and away from high-bandwidth devices on the same controller group.
4. For gaming keyboards, check the polling-rate setting in the vendor software — a deliberately low polling rate (e.g. 125 Hz) feels like lag to anyone used to 1000 Hz.
5. If lag persists with a direct port, low load, and no input-processing settings on, test the same keyboard on another machine before assuming a driver issue — a failing keyboard's electronics can add real latency.

What it looks like: regular typing is fine, but combinations fail — Win + D, Ctrl + C, Alt + Tab, or the laptop's Fn row. Shortcuts are modifier-key combinations, so this problem class lives in the modifier layer: accessibility toggles that swallow modifiers, an application that's capturing them, or (on laptops) the Fn key matrix, which is handled partly by firmware.

Where it usually lives: Sticky Keys / Filter Keys, a running remapping or automation tool, a specific application's key handling, or the laptop's Fn layer — in that order of likelihood.

1. Scope which combinations fail: all shortcuts, only ones involving Win, only ones in one app, or only Fn combinations. Each answer points to a different layer.
2. Check Settings → Accessibility → Keyboard and turn off Sticky Keys and Filter Keys; both silently alter modifier behavior.
3. If shortcuts fail only inside one application, that app is handling (or blocking) the keys — check its own shortcut settings, and test the same combo in another app to confirm the scope.
4. Disable any remapping/macro software and test again; these tools often "fix" one shortcut by breaking others.
5. For laptop Fn-row failures, check the Fn-Lock state (usually Fn + Esc) and the BIOS setting for Fn/ multimedia key behavior, and update the vendor's keyboard driver.

What it looks like: in UEFI setup the keyboard works perfectly; after Windows loads, it's dead. This is one of the most diagnostic symptoms in all of peripheral troubleshooting, because the firmware uses its own minimal USB stack (Legacy USB), completely independent of Windows drivers. The split proves the keyboard, cable, and port are all healthy and puts the failure squarely in Windows' USB/HID layer — a controller driver, the HID class driver, a bad update, or a startup program.

Where it usually lives: the xHCI USB controller driver, the HID driver, Fast Startup restoring a broken session, or a recent Windows Update that changed the driver stack.

1. Boot into Safe Mode. If the keyboard works there, the base driver stack is fine and a third-party driver or startup program is the cause — remove recent additions and test.
2. In Device Manager, expand Universal Serial Bus controllers and look for any controller with a warning; update or reinstall it from the chipset vendor.
3. Uninstall the HID keyboard device and the relevant USB hub devices, then choose "Scan for hardware changes" to force a clean re-enumeration.
4. Test with Fast Startup disabled (Control Panel → Power Options → Choose what the power buttons do → Change settings currently unavailable) — a corrupted hibernation image can carry a broken USB state into every "shutdown."
5. If the problem started after a Windows Update, check Update history and try uninstalling that update, or roll back the USB/HID drivers if a rollback option exists.

What it looks like: the keyboard is detected but behaves wrong in a way that tracks with driver events — after a driver update, after a vendor utility install, or with a warning icon on the HID device. Keyboard drivers are a two-layer stack: the generic HID class driver (Windows' job) and any vendor layer (game keyboard software, macro drivers, vendor "drivers"). Most real problems are in the vendor layer or in a driver store conflict, not in the base HID driver.

Where it usually lives: vendor software that installed a misbehaving driver, a driver store conflict between generic and vendor packages, or a bad driver version that Windows Update selected.

1. In Device Manager, open the keyboard's properties → Driver tab and check the driver provider and date. A vendor name where you'd expect "HID Class" (or vice versa) tells you which layer to suspect.
2. If a rollback option exists and the problem began after an update, roll back and test before doing anything more invasive.
3. Uninstall the vendor's keyboard software via Settings → Apps, then remove the keyboard device and rescan — this clears the vendor driver layer while keeping the generic HID driver.
4. Use the driver toolbox below (pnputil /enum-drivers) to see which keyboard-related packages are in the store; remove stray ones only if you can identify them as vendor leftovers.
5. Reinstall the vendor software from the manufacturer's site if you need its features — not from a third-party updater — and verify the keyboard's behavior after each layer change.

What it looks like: the keyboard appears in Device Manager but with a warning — an error code, an "Unknown HID Device" entry, or a device that keeps reappearing after removal. The code is the entry point: each one has a different meaning and a different first action (the Device Manager codes section below covers them individually). Two HID-specific patterns worth knowing: the fault sometimes sits on the parent USB hub rather than the keyboard entry, and stale hidden device entries can block clean re-enumeration.

Where it usually lives: the specific error code's cause (driver, power, hardware), a failing upstream hub, or accumulated hidden device instances confusing the PnP manager.

1. Read the exact code and message on the device, then follow that code's guide below — Code 10, 28, 43, and 45 lead to very different paths.
2. Check the parent chain: expand the USB controller and root hubs above the keyboard entry. A warning on the parent hub means the port path is failing, not the keyboard.
3. Show hidden devices (View → Show hidden devices), right-click faded stale instances of the keyboard and remove them, then Scan for hardware changes.
4. Uninstall the HID keyboard entry and rescan; if Windows re-detects it cleanly, the problem was a corrupt instance, not the driver package.
5. If the entry returns with the same code on a different port and a different machine shows the same device fine, weigh a failing device against a failing port group using the cross-test from the top of this page.

What it looks like: the cursor is frozen and the mouse gets no input. As with keyboards, the BIOS test is the fork: a mouse that moves in UEFI but not in Windows has healthy hardware and a Windows-side failure (HID driver, USB controller); one that's dead in UEFI too is a hardware/power problem. Laptops add a useful extra probe — the touchpad. If the touchpad works, Windows' pointing stack is fine and the external mouse's path (port, receiver, driver) is the failure.

Where it usually lives: the port or cable (wired), batteries/receiver (wireless), the HID driver, or the mouse itself. PS/2 mice on legacy ports add a twist: a PS/2 device moved while powered on won't be re-detected without a full reboot.

1. Confirm scope with the touchpad (laptop) or a second mouse: if another pointing device works, the OS is fine and you're chasing this mouse's path.
2. Wired: swap the port (rear on a desktop) and the cable. Wireless: replace batteries, check the receiver seating, and re-pair per the vendor procedure.
3. Check Device Manager for an "HID-compliant mouse" and USB controllers with warnings — a Code 43 controller can kill the mouse without touching the keyboard (if it's Bluetooth).
4. For PS/2 mice: unplug only at a full shutdown and replug before power-on, then boot — hot-plugging PS/2 is not supported and is a classic "mouse died" cause.
5. If the mouse is dead in BIOS on this machine and dead on another, the mouse (or its cable/receiver) is the failed hardware.

What it looks like: the cursor stops for a second or several, then resumes. Freezing is rarely "the mouse" — it's usually the system failing to process input fast enough, and the freeze pattern tells you which. Freezes that happen under load (video, games, heavy apps) point at CPU/GPU saturation; random freezes at idle point at USB power management or a struggling disk (a pegged drive stalls everything, input first); periodic freezes that align with sleep/wake point at resume bugs.

Where it usually lives: system load, a saturated disk, USB selective suspend, or a driver that drops the device briefly. A genuinely failing mouse sensor more often produces stutter or jumps than clean freezes.

1. Watch Task Manager during a freeze: high CPU/GPU → load problem; disk at 100% with low CPU → storage problem; everything low → driver/power problem.
2. Disable USB selective suspend (Power Options → Advanced → USB settings) and re-test, especially if freezes follow idle periods or wake-from-sleep.
3. Check the disk: sustained 100% active time is its own problem (see the USB/storage guides); fixing the disk often ends the freezes.
4. On laptops, rule out the touchpad: some drivers pause the external mouse path when the touchpad is active — disable the touchpad while docked and test.
5. Update the mouse's driver (vendor or HID) and the chipset drivers; if freezes persist with low load, a direct rear port and a different mouse isolate the last two suspects.

What it looks like: the cursor drifts, jumps, or darts without input. Erratic movement is the one mouse symptom where the environment matters as much as the hardware: optical sensors are affected by the surface (glass, glossy, uneven), by dirt on the lens, and — for wireless — by electromagnetic noise from charging phones and chargers. Two "software" causes round out the list: a DPI setting or curve that amplifies small movements, and a second pointing device (touchpad) feeding input at the same time.

Where it usually lives: the sensor/surface pair, wireless interference, an aggressive DPI profile, or dual pointing devices. A truly failing sensor usually shows a signature — drift in one direction or jumps tied to specific surfaces.

1. Test on a plain matte mousepad or a sheet of paper. If it's clean on paper but jumps on your desk surface, the surface is the cause — not the mouse.
2. Clean the sensor lens (power off, blow/softly wipe the optical window) — a smudged lens produces exactly this symptom.
3. On laptops, disable the touchpad (or use the vendor's "disable when external mouse connected" option) and re-test; an active touchpad under a resting palm injects real input.
4. For wireless mice, move the receiver away from chargers, USB 3.0 devices, and the router, and try a different battery — weak cells show up as erratic tracking before they show up as shutdown.
5. Reset DPI and any "enhanced precision" or sensitivity curve to defaults; a mis-set profile makes normal micro-movements look like jumps.

What it looks like: clicks happen with no finger on the button — selecting text, opening items, or advancing dialogs on their own. The first split is location: clicks that always map to the same screen position when the mouse is stationary point at a physically shorted button (the button's electrical contact is stuck closed); clicks at moving or random positions point at the input layer — another device, a driver, or on some systems pen/touch calibration feeding phantom clicks.

Where it usually lives: a worn left-button switch (the most common mechanical mouse failure), a stuck contact under the keycap of a laptop, or — less often — a driver/pen-layer issue on systems with touch or pen support.

1. Hold the mouse still and note where the phantom clicks land. Fixed position → the button switch; moving positions → the input path.
2. Press the suspect button firmly and repeatedly — if phantom clicks stop while you hold it down, the contact is mechanically intermittent and the switch is failing.
3. Test the mouse on another machine. Phantom clicks everywhere → the mouse hardware; only here → the PC's input layer.
4. On laptops and 2-in-1s, check for pen/touch settings and tablet PC services that can generate phantom pointer input; temporarily disable the digitizer in Device Manager and re-test.
5. For a confirmed failing switch, cleaning the contact helps marginally at best — the realistic fix is a new mouse or a switch replacement for a worthwhile device.

What it looks like: single clicks register as doubles — files open when you meant to select, right-clicks fire context menus twice. Two causes produce identical symptoms at different layers: the double-click speed setting is set so fast that normal clicks count as a pair, or the button switch is bouncing (making one physical click electrically register as two). The setting is the one to check first because it's instant to test and instant to fix.

Where it usually lives: the double-click speed setting, or a worn/bouncing left-button switch. Driver causes are rare for this specific symptom.

1. Open Settings → Bluetooth & devices → Mouse (Windows 11) or Settings → Devices → Mouse (Windows 10) and drag the double-click speed slider toward "Slow," then test on a folder of files.
2. If the slider fix works, the setting was the cause — find the level that feels right and stop there.
3. If it double-clicks at the slowest setting, the switch is bouncing: press-and-hold the button to confirm intermittent contact, then test the mouse on another machine to be certain it travels with the device.
4. Check for a per-application variant: some apps (games, CAD tools) define their own double-click behavior — if it only doubles in one app, that app's settings are the source.
5. A switch that bounces at the slowest setting is a hardware failure; a new mouse is the proportionate fix.

What it looks like: one or more buttons simply don't fire. Which button is the clue. Left and right are standard momentary switches. The middle "button" is actually the scroll wheel pressed down — a different switch in a different mechanism, and the most mechanically fragile of the three. App-specific button failures (middle-click works in one program, not another) point at application handling, not hardware.

Where it usually lives: the specific button's switch (middle most often), a per-app mapping, or — for multi-button mice — the vendor software's button assignment rather than the hardware.

1. Establish the scope per button: test each button in Explorer, in a text field, and in a game or app that uses middle-click. One app only → that app; everywhere → hardware/driver.
2. For middle-click failures specifically, try a different middle-click consumer (browser tab close, middle-click paste in a terminal) to confirm the switch isn't firing at all.
3. Open the vendor software (if the mouse has one) and verify button assignments haven't been remapped — a "disabled" or misassigned button behaves exactly like a dead one.
4. Test the mouse on another machine: dead there too → the switch. Alive there → this machine's driver stack; update or reinstall the mouse driver and test.
5. Failed switches are not software-fixable; if the cross-test confirms the hardware, replace the mouse (or the switch, for a device worth opening).

What it looks like: the wheel spins but nothing scrolls — everywhere, in some apps, or (for horizontal-scroll failures) only sideways. Scrolling is interpreted per application: browsers have their own smooth-scroll and zoom-on-scroll settings, office apps map the wheel to lines vs pages, and some programs rebind it entirely. So "the wheel doesn't work" is three different problems: the mechanism (the wheel encoder), the driver, or the application's scroll handling.

Where it usually lives: a per-app scroll setting, the wheel encoder (a dirty or worn detent mechanism), or the mouse driver. A wheel that scrolls in one app but not another is nearly always the app.

1. Test the wheel in three contexts: a browser, File Explorer, and a document editor. All fail → mechanism/driver; one fails → that app's settings.
2. In the failing browser, disable smooth scrolling and check the zoom-on-scroll setting; in office apps, check lines-per-scroll and whether the wheel is remapped.
3. Blow out the wheel mechanism — encoder dust is a classic cause of "spins but doesn't register," and a burst of air often restores detents.
4. Update or reinstall the mouse driver, and check the vendor software for any scroll-related options (free-spin mode, scroll acceleration).
5. If the wheel is mechanically dead (spins with no clicks, no registration anywhere, even after cleaning), the encoder has failed — a hardware limit that a new mouse resolves.

What it looks like: the cursor stops for moments or minutes, then returns — a 2.4 GHz link dropping. Wireless disconnects follow a short list of physical causes: receiver placement (USB 3.0 ports and enclosures are a real source of 2.4 GHz interference), range and obstacles between mouse and receiver, battery state, and sleep/resume behavior where the receiver or mouse doesn't re-establish cleanly after the PC wakes.

Where it usually lives: the receiver's environment (port, neighbors, distance), power (batteries), or the resume path after sleep. A receiver that's genuinely failing usually drops constantly rather than intermittently.

1. Move the receiver to a rear port with no USB 3.0 device adjacent, or use a short USB extension to put it on the desk near the mouse — this single change resolves a large share of 2.4 GHz dropouts.
2. Replace the batteries with fresh cells; marginal power causes exactly this intermittent signature.
3. Note whether drops follow sleep/wake. If so, disable USB selective suspend and the receiver's power management (Device Manager → USB Root Hub → Power Management → uncheck "Allow the computer to turn off this device").
4. Re-pair the mouse to the receiver per the vendor procedure, then test the receiver in another PC to separate a failing receiver from a failing mouse.
5. If drops persist with fresh batteries, a well-placed receiver, and no sleep correlation, the mouse's radio or the receiver is the failed component.

What it looks like: the mouse won't pair, pairs but won't connect, or connects and the cursor does nothing. Bluetooth mice are HID devices over a radio, so three layers can each fail independently: the radio link (range, interference, adapter), the bond (stale pairings, wrong mode), and the HID function (the connection exists but no input flows). "Connected but dead" is the tell that the first two layers are fine and the third — or the mouse's own HID firmware — is at fault.

Where it usually lives: a stale bond or wrong pairing mode, the Bluetooth adapter's driver, adapter power management, or the mouse's own state after a battery swap.

1. Remove the mouse from the paired-devices list, put it into its documented pairing mode, and re-add it from Settings → Bluetooth & devices. A fresh bond clears most "paired-but-dead" states.
2. After a battery swap, some mice lose their bond locally — re-pairing (not just re-connecting) is the fix, and the manual's pairing sequence is the one to follow.
3. Check the Bluetooth adapter in Device Manager for warnings, and disable its Power Management "allow turn off" option — adapter-level power saving is a common disconnect source.
4. Keep the adapter physically separated from USB 3.0 ports and hubs; Bluetooth and 2.4 GHz share a band and a crowded front panel degrades both.
5. If no Bluetooth mouse can pair or function on this PC, continue to the Bluetooth driver guide — the adapter, not the mouse, is the shared failure.

What it looks like: the cursor moves but in micro-stutters, or trails behind the hand — smooth hardware, choppy result. Stutter is a throughput problem at one of the stages: the device's polling rate (how often it reports position), the USB path (a saturated hub or port), system load (input processing starved by CPU/disk), or — for wireless — radio dropouts masquerading as stutter. The distinguishing test is context: stutter only under load is the system; stutter at idle with a direct connection points at the device or its polling configuration.

Where it usually lives: a deliberately low polling rate, a congested USB hub, system load, or wireless interference — in that order for most reports.

1. Check the polling rate in the vendor software; 125 Hz feels like stutter to anyone used to 1000 Hz, and this setting is a common "nothing is wrong but it feels wrong" cause.
2. Move the receiver or cable to a direct rear port, off any hub shared with cameras or external drives, and re-test at idle.
3. Compare against Task Manager: if stutter tracks CPU or disk spikes, the fix is in the system load (see the performance library), not the mouse.
4. For wireless, apply the same environment fixes as the disconnect guide — receiver placement, batteries, distance — since micro-dropouts read as stutter.
5. If a direct-connection mouse stutters at idle on this PC but not on another, the fault is in this machine's USB stack (controller driver first); if it stutters everywhere, the device is the cause.

What it looks like: with an external mouse plugged in, the pointer still drifts, clicks appear from nowhere, or the mouse and touchpad seem to "fight" — cursor jumps when a finger brushes the pad, phantom clicks while typing with palms down. This is not really a conflict in the driver sense: both devices feed the same pointer, and Windows happily accepts input from both. The problem is that the touchpad is still active and receiving the incidental contact your hands produce while using a mouse.

Where it usually lives: the touchpad staying enabled while docked, palm-rest contact, or vendor driver behavior around "disable when mouse connected." It's a configuration problem, not a hardware one — both devices are usually perfectly healthy.

1. Use the vendor's laptop utility (Lenovo Vantage, ASUS MyASUS, Dell Command, HP Command Center) to enable "disable touchpad when external mouse is connected" if available.
2. Otherwise, disable the touchpad in Settings → Bluetooth & devices → Touchpad while you work docked, or disable the HID touchpad device in Device Manager (reversible — re-enable when traveling).
3. If the touchpad must stay enabled, adjust its tap settings (turn off tap-to-click) so incidental contact stops generating clicks.
4. Check the vendor driver for a "palm rejection" or "docking mode" option; some drivers handle mouse-connected state poorly until updated.
5. A BIOS "touchpad disable when external PS/2/USB mouse present" option exists on some models — the most robust variant, worth checking in UEFI.

What it looks like: the mouse entry in Device Manager carries a warning, or the mouse keeps vanishing from the list. Read the code first — the codes section below treats each one — and then apply the two mouse-specific twists. First, the fault frequently sits on the parent USB root hub, which fails silently for the mouse while "working" for lower-priority devices. Second, USB power management settings apply per root hub, so the fix may be a hub property rather than a mouse property.

Where it usually lives: the error code's cause (driver, power, hardware), the parent hub's health, or per-hub power management settings.

1. Read the exact code/message on the mouse entry and follow that code's guide below before touching anything else.
2. Inspect the parent chain: expand the USB controllers and root hubs above the mouse; a warning there means the port path is the failure.
3. On the relevant root hub, open Properties → Power Management and uncheck "Allow the computer to turn off this device to save power," then re-test including sleep cycles.
4. Uninstall the mouse entry, show hidden devices, remove stale faded instances, and Scan for hardware changes for a clean re-enumeration.
5. If the code persists across ports and the mouse is clean on another machine, the cross-test result decides: port/controller group on this PC, or (if the mouse is also affected elsewhere) the device.

What it looks like: you plug in a USB device and Windows does nothing — no sound, no notification, nothing new in File Explorer or Device Manager. The critical first observation is what Device Manager actually shows, because it splits the problem in half. If something appears (even an "Unknown device" or a flash drive entry with a warning), enumeration worked and the problem is driver-level. If nothing appears, Windows never saw the device at all, and the problem is detection-level: power, cable, port, or the device itself.

Where it usually lives: detection failures: cable (data lines), port power, the device, or a failed controller. Driver failures: a missing or mismatched driver package, a device that needs vendor software to function.

1. Open Device Manager and choose "Scan for hardware changes" after plugging in. Note precisely what appears: nothing, an unknown device, or a named device with an error — each is a different branch.
2. Try a different cable (many cables are charge-only with no data lines) and a different port, preferably a rear desktop port.
3. Power-hungry devices (external HDDs, hubs) need the powered port or their own supply — a device that "isn't recognized" may simply be under-powered.
4. Check the Event Viewer System log around the plug-in moment for USB errors — a controller error there points at the host controller rather than the device.
5. Cross-test the device on another machine. Recognized there → this PC's port/controller/stack; unrecognized everywhere → the device or its cable.

What it looks like: Windows pops up its "A USB Device Failed Initialization" / "USB device not recognized" balloon — the system saw the plug-in event, started enumeration, and the device failed to present a valid descriptor. That's a more specific failure than "nothing happens": the electrical link exists (Windows noticed), but the handshake broke. The usual causes are a device with a failing controller chip or firmware, a marginal cable that passes power but corrupts the data handshake, a port that can't deliver the negotiated current, or a device that's simply defective at the descriptor level.

Where it usually lives: the device itself (failing USB controller or firmware), the cable, or port power negotiation. The host PC is less often the culprit when this specific popup appears — but a failing controller can produce it, which is why the port test still matters.

1. Identify which device triggers it (plug devices in one at a time) — the popup is per-device, and knowing the offender is half the diagnosis.
2. Try a known-good cable and a rear port; a handshake that fails on one port/cable but succeeds on another localizes the fault to the path, not the device.
3. Check the System log for USBHUB3 or USB errors with a port number — they name the exact port that rejected the device.
4. If the device has a firmware update (some SSDs, capture cards, and dongles do), apply it — descriptor-level failures are occasionally firmware bugs.
5. If the popup follows the device to every port and every machine, the device's USB controller has failed; that's a hardware end, not a settings problem.

What it looks like: the device drops and reappears in a rhythm — File Explorer flickers, the connect/disconnect sounds repeat, or a drive letter appears and vanishes. Flapping is a timing problem, and timing problems are measurable: every flap generates a PnP event, so you can watch the cadence and correlate it with what the machine is doing. Flaps that follow a steady interval point at power management (selective suspend cycling); flaps that follow movement or total USB load point at a physical connection (cable, port contact, hub); flaps that follow sleep/wake point at resume.

Where it usually lives: a marginal cable or connector, a hub under load, selective suspend, or a port with worn contacts. The device is less often the cause of a clean periodic flap than of an irregular one.

1. Record the flaps in Event Viewer → Windows Logs → System (Kernel-PnP events) for an hour of normal use — the timestamps reveal the cadence and whether it correlates with sleep, idle, or specific devices.
2. Replace the cable first; a frayed shield or worn connector is the single most common flap source and the cheapest to test.
3. Remove hubs from the chain and connect directly to a rear port; if flapping stops, the hub or the original port is the weak link.
4. Disable USB selective suspend and uncheck power-off on the relevant root hubs, then re-test across a full day including sleep.
5. If flapping survives a direct rear port with a new cable, cross-test the device on another machine to assign the last suspect.

What it looks like: one or more USB ports accept a plug but deliver nothing. The organizing question is grouping: ports on a PC are wired in groups behind host controllers (often by color — blue USB 3.x, black USB 2.0 — but not always). If all ports of one group are dead while another group works, the failure is the controller or its driver, not individual ports. If a single port is dead while its siblings work, the failure is that port's physical path (the port itself, or for front panels, the header).

Where it usually lives: a failed or driver-broken host controller (whole group dead), a damaged port or header (single port dead), or — on desktops — a BIOS USB setting. A machine where every USB port on the board is dead is a chipset/board-level problem, not a Windows one.

1. Map the dead ports by position and color to identify which controller group they belong to — Device Manager's USB controller list plus a process of elimination shows the grouping.
2. In Device Manager, check the corresponding eXtensible Host Controller for a warning code; a Code 43/10 on the controller explains a whole dead group, and its code's guide is the next step.
3. Reinstall the chipset drivers from the motherboard/laptop vendor — controller-group failures are frequently driver-level and this is the highest-yield software fix.
4. On a desktop with dead front ports only, reseat the front-panel USB header inside the case (see the front-panel guide); a loose or mis-seated header kills exactly those ports.
5. If a whole group is dead with clean drivers, check UEFI for USB settings (some boards have per-group enables), and test a USB device in BIOS to separate a board-level fault from Windows.

What it looks like: the same device, the same cable — works in port A, dead in port B. This is one of the cleanest isolation results you can get: the device and the system are both proven functional, and the fault is confined to port B's path. The path is short: the port's physical contacts, (for front ports) its header wiring, its power delivery, and the controller it hangs off. A device that works in a USB 2.0 port but not a USB 3.x one (or vice versa) adds a compatibility dimension, covered in its own guide below.

Where it usually lives: the specific port (worn/damaged contacts), a front-panel header, that port's power delivery (some ports can't supply the device's current), or — when the pattern follows port color — a single controller.

1. Extend the test: which other ports fail with this device? One port → port fault; all ports of a color → controller; scattered → power or the device's current draw.
2. Check the port's power capacity against the device's needs — an external HDD or a hub full of devices may exceed what a particular port (or the front header) delivers.
3. For front-panel ports, reseat the header cable at both ends; front ports are the most common "one port dead" case on desktops.
4. Inspect the failing port's contacts for bent pins or debris — a single bent ground pin can kill data while leaving power alive (device lights up, Windows sees nothing).
5. If the fault follows one controller's whole group, update/reinstall that controller's chipset driver before concluding the hardware is damaged.

What it looks like: the device is clearly detected — Windows chimes, Device Manager lists it happily — but no drive shows up in File Explorer. This means the failure is below the "drive" concept: the device's storage isn't presenting a browsable volume. The causes are a missing drive letter or mount point, a volume that needs formatting (RAW or unallocated), a partition scheme the PC doesn't use (e.g., a Mac-formatted drive), or simply a non-storage device being expected to show a drive (USB audio, a webcam, a dongle never appear in Explorer by design).

Where it usually lives: the volume/letter layer in Disk Management, the file system, or a mismatch between what the device is and what you expect it to do. The USB transport itself is working in every one of these cases.

1. Confirm the device class: open Device Manager and check where the device landed. Under "Disk drives" → storage path; under "Imaging devices," "Audio," etc. → it was never a drive.
2. Open Disk Management (diskmgmt.msc). Does the device appear with a volume? No letter → right-click the volume → "Change drive letter and paths" and assign one.
3. If it appears as Unallocated or RAW, stop and decide before formatting: RAW with important data means a data-recovery conversation first; formatting erases whatever is there. Format only a drive you're prepared to lose.
4. For drives formatted on another OS (Mac APFS, some Linux layouts), Windows may see the partition but not the file system — reformatting for Windows use is the fix, again only with data handled first.
5. If the device doesn't appear in Disk Management at all despite being in Device Manager, the device's storage controller is failing or the device is a non-storage peripheral — cross-test on another machine to close it out.

What it looks like: you plug in a device and it doesn't appear anywhere — not in Explorer, not in Device Manager, not even as an unknown device. This is the deepest failure level: the USB stack never registered the device at all, which rules out every driver cause and confines the fault to the physical and electrical layer. Nothing in software will make a device appear that the controller never electrically detected. The remaining suspects are the cable's data lines, the port, the hub, the device's power, or the device itself.

Where it usually lives: the cable (charge-only or broken data lines — extremely common), a dead port, an unpowered device that needs a powered hub, or the device's USB connector/controller.

1. Try a different cable and a different rear port before any other step — the cable is the statistical winner in this exact scenario.
2. If the device has a power switch or needs an external supply, provide it; many devices are silent (no enumeration, no error) when under-powered.
3. Check whether any device works in that specific port; a port where nothing enumerates is a dead port, not a device problem.
4. Remove hubs entirely for the test — a failed hub can mask every downstream device as "missing."
5. Cross-test the device (with a known-good cable) on another machine. Missing everywhere → the device's connector or controller is failed; present elsewhere → this PC's port/controller path.

What it looks like: Windows warns about a USB power surge, or the machine shuts down with a USB overcurrent message, or a port simply stops working after a device was plugged in. This is the one USB symptom that is electrical rather than logical: the port's overcurrent protection tripped because something on that port drew too much current or presented a short. The important reframe: this warning is the protection working. The job now is to find what tripped it — a failing device, a shorted cable, or (less commonly) a damaged port — and to stop using the affected path until it's identified, because forcing a shorted port can damage the board.

Where it usually lives: a failing device (a dying external drive's controller is a classic), a shorted cable, or a damaged port/header. Treat it as a hardware fault hunt, not a driver problem — no software state causes an overcurrent trip.

1. Unplug everything from the affected port(s) and leave it empty. If the warning was tied to a specific device, that device is the prime suspect.
2. Reconnect devices one at a time to identify the trigger. A device that trips it on this machine and on another has a failing power stage — stop using it.
3. Check the System log for the overcurrent event (Kernel-Power / USB sources); it can indicate which port or hub reported the fault.
4. If no device trips it but the port stays dead, the port or its header may have taken damage — on a desktop, inspect and reseat the front header; on a laptop, treat a dead-after-surge port as a board repair question.
5. Do not keep plugging suspect devices into the port "to check" — each trip is another stress event on the protection circuitry.

What it looks like: USB devices fail in patterns that correlate with idle time or sleep — a wireless dongle drops after the PC idles, an external drive disappears on wake, a controller fails to resume. USB selective suspend is a power feature that puts idle USB hubs into a low-power state; on most systems it's harmless, but some devices and controllers resume badly, and the failure looks like the device "died" when really it was switched off and didn't come back cleanly.

Where it usually lives: the power plan's USB setting, per-hub power management flags in Device Manager, or a controller/driver that mishandles the resume transition. The setting path is identical in Windows 10 and Windows 11 — Power Options → Change plan settings → Show additional settings → USB settings → Selective suspend.

1. Confirm the correlation first: do the failures follow idle periods, sleep, or both? If the device fails with zero idle time in between, selective suspend is not your cause.
2. Set USB selective suspend to Disabled in the active power plan and re-test across a day including idle and sleep cycles.
3. In Device Manager, expand Universal Serial Bus controllers → each USB Root Hub → Properties → Power Management, and uncheck "Allow the computer to turn off this device to save power."
4. Update the chipset drivers — several selective-suspend resume bugs were controller-driver issues that vendor chipset updates fixed.
5. If disabling the feature resolves the failures, keep it disabled; the power cost is small and the reliability gain is the point.

What it looks like: everything works, the PC sleeps, and on wake one or more USB devices are gone or dead until replugged. This is a resume-path failure: the device (or its hub) didn't survive the transition from S3 sleep back to full power. Three layers can each break resume — the hub's power state, the device's own firmware, and (on some configurations) Fast Startup, which changes what "resume" actually involves by blending it with a hibernated kernel.

Where it usually lives: selective suspend plus a weak resume (most common), a device firmware that doesn't handle S3 well, or Fast Startup interacting with a driver. A device that fails after sleep but never during normal use is telling you precisely which path is broken.

1. Disable USB selective suspend (Power Options path in the guide above) and uncheck power-off on the root hubs — this is the first and most frequent fix.
2. Test sleep versus shutdown versus hibernate separately: if the device only fails after sleep and survives a full reboot, the S3 path specifically is the problem, which narrows the suspect list.
3. Try Fast Startup disabled (Power Options → Choose what the power buttons do → change settings currently unavailable) and re-test — a surprising share of "after sleep" USB failures are actually Fast Startup state issues.
4. Update the device's firmware if the vendor offers it (external SSDs, capture cards, and some wireless dongles ship resume fixes this way), and update chipset drivers for the controller side.
5. If one specific device always fails resume and nothing else does, its firmware/hardware is the weak link — a powered hub between it and the PC is a workable mitigation even if it's not a fix.

What it looks like: a USB device that worked for months stopped after a Windows Update — gone from Explorer, erroring in Device Manager, or simply not enumerating. Update-induced regressions are a distinct problem class because the timeline is the evidence: the update changed the driver store, replaced a driver, or changed a USB-stack component, and the device's old working state was overwritten. The two legitimate responses are rolling back the specific driver the update touched, or uninstalling the specific update — both reversible, both targeted.

Where it usually lives: a replaced driver (check the driver date in Device Manager), a changed USB-stack component from the update, or an optional/vendor driver that the update invalidated. "Reinstall the driver" from the vendor often restores the exact prior state.

1. Confirm the timeline in Settings → Windows Update → Update history (Windows 11) or Update & Security → Windows Update → Update history (Windows 10) — note the update that preceded the failure.
2. In Device Manager, check the affected device's driver date/provider. A date matching the update confirms a driver replacement; use Roll Back Driver if the option exists.
3. Reinstall the vendor's driver package for the device (official site) — this restores a known-good driver into the store over the update's version.
4. If that doesn't restore behavior, uninstall the specific update from Update history and reboot, then re-test the device before letting Windows reinstall it.
5. Check Windows Update's optional updates for a vendor driver entry for your device — installing the vendor's listed package is sometimes the intended fix path.

What it looks like: the USB ports on the front of a desktop case are dead (or flaky) while the rear motherboard ports work fine. Front ports aren't part of the board's port array — they're wired to it with internal headers (a USB 2.0 9/10-pin header and a USB 3.0/3.1 19/20-pin header), and that wiring is the entire extra failure surface: the header can be loose, mis-seated, bent, or (on some boards) sharing a controller group that's misbehaving. A dead front port with a healthy rear port is, statistically, a header problem first and a board problem second.

Where it usually lives: the header connection at the board or the case, a bent pin, or a case front-panel module with failed ports. Note that front USB 3.0 headers on some boards draw power through the data header — a partially connected 3.0 header can kill the 3.0 front ports while 2.0 ports survive.

1. Confirm the split: rear ports of the same USB generation working, front ones dead. That split localizes the fault to the front path.
2. Power off, open the case, and reseat both front USB headers at the motherboard — pull fully and re-press until the latch clicks. This resolves the most common variant.
3. Inspect the header pins (board and case cable) for bends or misalignment; a single bent ground pin produces "port dead but device LED sometimes lights" behavior.
4. Swap which front-port group uses which header if the case supports it, to test whether one header/cable is the failure.
5. If the header is clean and reseated and the ports still die, test the case front module on another board (or the board's header with a known-good front cable) to split the fault between case and board.

What it looks like: devices behind a hub fail in ways no single device explains — several drop together, failures follow total load, or a device that's fine on a direct port flaps behind the hub. Hubs are legitimate failure points, not just pass-throughs: a bus-powered (unpowered) hub has a fixed current budget it shares across all downstream ports, and when the sum of the devices' draw approaches or exceeds it, the hub starts shedding devices — often the newest plug-in, often at random. Hub quality and age matter too; a failing hub's electronics produce exactly the "intermittent, load-dependent" signature.

Where it usually lives: the hub's power budget (bus-powered hub + several devices), the hub's own electronics, or — less often — a hub driver issue. The diagnostic is structural: remove the hub and see if the failure follows it or stays behind.

1. Connect the failing device directly to a rear port, bypassing the hub entirely. Failures stop → the hub (or its power budget) is the cause; failures continue → the device or the PC.
2. For multi-device setups on a bus-powered hub, count the draw: each external drive and each downstream device eats the shared budget. Move high-draw devices to direct ports or put a self-powered hub in the chain.
3. Test a different hub (ideally self-powered) with the same device set — if the problem moves with the original hub, the hub's electronics are failing.
4. Check whether failures correlate with a specific downstream port on the hub rather than total load — a single bad hub port behaves like a dead port with extra steps.
5. As a last software check, look at the hub's own entry in Device Manager (it's listed as a USB Hub under the controller) for warning codes — a Code 43 hub is a failed hub, full stop.

What it looks like: a device that "should" work behaves wrong depending on which generation of port it's in — a USB 2.0 device that fails in a 3.x port, a 3.x device that's glacially slow in a 2.0 port (expected, but worth confirming), or a niche device (older scanners, some industrial/medical hardware, legacy dongles) that only works when the system presents USB 2.0-mode support. Modern Windows hosts both protocols through the xHCI controller, and most mismatches are transparent — but the mismatches that do surface have a short, specific cause list.

Where it usually lives: a device with a firmware that dislikes xHCI (the "legacy" problem), a cable rated for the wrong generation, speed expectations (a 3.x drive in a 2.0 port is ~40× slower by design), or a BIOS Legacy USB setting on older systems.

1. Establish the speed baseline: check the device's negotiated speed in Device Manager (its properties show the connection speed). A 3.x device reporting 480 Mbps is in 2.0 mode — port or cable limitation, by design.
2. For a USB 2.0 device failing in a 3.x port, try the reverse: a known 2.0 port. If it works there, the device's firmware is the xHCI-disliker, and a 2.0 port or 2.0 hub is the practical configuration.
3. Check the cable's rating — cheap "universal" cables are often 2.0-spec inside a 3.x-shaped plug and will silently cap (and sometimes break) a 3.x connection.
4. On older desktops, UEFI may expose a Legacy USB Support option that changes how pre-OS and 2.0-mode devices behave; verify it's enabled for legacy peripherals.
5. Accept the design limits where they exist: a 3.x device in a 2.0 port will always be 2.0-speed. That's not a fault to chase.

What it looks like: a USB device error-changes in ways that don't match any single cause — a Code 28 that a reinstall "fixes" until the next boot, a device that works with one driver version and not another, or two devices that can't coexist. These are driver-store conflicts: Windows keeps multiple driver packages in a central store and binds the best match to each device, and when two packages claim the same device (generic vs vendor, or two vendor versions), the binding can flip between boots. The store is inspectable and manageable with pnputil, which turns "mystery driver behavior" into a list you can read.

Where it usually lives: competing packages in the driver store (a leftover vendor package vs the generic one), a vendor installer that registered a partial package, or a third-party updater that added an untested driver. Avoid the untested category proactively: driver-updater tools are a leading source of exactly these conflicts.

1. Run pnputil /enum-drivers (driver toolbox below) and look for multiple packages matching the device's hardware ID — duplicates are the conflict's footprint.
2. In Device Manager, check the driver's provider and date; a provider you don't recognize (or that doesn't match the device's vendor) is a misbound package.
3. Roll back to the previous driver version if available; if the conflict recurs, remove the offending store package with pnputil (toolbox below) and reinstall the vendor's official package cleanly.
4. Uninstall any third-party "driver updater" software and remove the packages it added — re-verify with the enum command that the store is back to vendor + Microsoft entries only.
5. After cleanup, re-test across reboots, not just one session — a conflict that only rebinds at boot will look fixed until it isn't.

What it looks like: the warning is on the controller itself — an "USB xHCI Controller" or "USB Root Hub" entry carrying a Code 10/43 — and with it, an entire group of ports goes quiet. Controller-level failures are the upstream version of everything above: one sick controller knocks out every port and every hub hanging off it, which is why "several ports died at once" is a controller symptom, not a coincidence of several dead ports. The usual causes are the chipset driver, a power-state transition the controller mishandles (S3 sleep), or the controller hardware on the board.

Where it usually lives: the chipset/USB driver (most common and most fixable), a sleep-resume bug in the controller, or — when software fixes are exhausted — the controller hardware. Map ports to controllers first; the mapping tells you how much of the machine a controller failure actually affects.

1. Read the controller's exact code and follow that code's guide below — a controller with a Code 43 and a controller with a Code 10 take different paths.
2. Reinstall the chipset drivers from the motherboard/laptop vendor (not Windows Update's generic set) — controller warnings that clear with a chipset reinstall are the most common variant.
3. Test the sleep cycle deliberately: sleep, wake, check Device Manager. A controller that errors only after S3 has a resume bug — chipset update first, then the selective-suspend and Fast Startup fixes from the guides above.
4. Disable and re-enable the controller in Device Manager to force a clean re-initialization — a stuck controller sometimes recovers with this, which is itself diagnostic (state bug vs hardware).
5. If the controller errors persist with clean drivers across reboots and sleep cycles, treat it as board-level: the port group it owns is permanently reduced, and the practical answer is USB 3.0/2.0 expansion via a known-good path (e.g., a PCIe card on a desktop).

What it looks like: the printer is on and connected, but it never shows up in Settings → Printers & scanners, or in the "Add a printer" list. Detection is really two mechanisms: network discovery (Windows finding the printer on the LAN) and direct connection (you telling Windows exactly where the printer is and with which port). Discovery is convenience; direct connection is the reliable path, and most "not detected" problems end the same way — the printer gets added manually with an explicit port, which also bypasses whatever discovery glitch existed.

Where it usually lives: the printer's network presence (IP, discovery protocols, firewall), the USB path (for wired USB printers — treat it as the USB detection problem), or a missing driver package for the model. Confirm the printer is healthy first with its own self-test page.

1. Print the printer's self-test/config page from its own controls. If it can't self-test, the problem is the printer, not Windows — stop there.
2. For USB printers, verify the cable/port with the USB detection guides; a "not detected" USB printer is a USB problem wearing a printer costume.
3. For network printers, confirm reachability: get the printer's IP from its config page and ping it from the PC. No ping → network layer (cable, SSID, subnet, router).
4. Add the printer manually: Settings → Printers & scanners → Add device → The printer that I want isn't listed → Add manually using TCP/IP (enter the IP) or via the USB port. This skips discovery entirely.
5. When prompted for a driver, install the vendor's package for the exact model — the generic Windows catalog driver works for basics but misses features and is a recurring source of later driver problems.

What it looks like: the printer is listed, powered on, and physically fine, but Windows marks it "Offline" and jobs won't release. "Offline" is a status, not a diagnosis — it's set by several different things: a manual "Use printer offline" flag (often toggled by accident), a port that lost contact with the printer (network port, or a USB port that re-enumerated), a bidirectional-communication failure, or the printer itself reporting an error state (EIO) it's surfacing to Windows. The first move is to find which of those set the flag, because each has a different fix.

Where it usually lives: the manual offline flag (most common and most embarrassing), the port (especially WSD ports, which are convenient and flaky), or the printer-side error state. Check the printer's own panel before anything else — a printer in paper-out or error will drive Windows offline legitimately.

1. Check the printer's own panel for errors (paper, toner, door, EIO) and clear them — a printing-side fault sets the offline status honestly.
2. In the printer's Properties → Ports, and Printer → "Use printer offline," verify the offline flag is off (Windows 11: Print queue → three dots → Printer offline; Windows 10: the classic queue window → Printer menu).
3. Test the port: Properties → Ports → Select the active port → Configure Port → Details/Test. A network port that fails the test has lost the printer at the network layer — re-add the port with the current IP.
4. If the port is a WSD port and the printer drops offline periodically, re-create the printer with a Standard TCP/IP port instead — WSD is the convenience layer and the common flake.
5. Restart the Print Spooler service after port changes (driver toolbox below) so the port state refreshes, then send a test page.

What it looks like: jobs are sent, the printer is online, and nothing comes out — or the job sits, errors, or the printer simply ignores it. The diagnostic ladder for "refuses" is to print at successively lower layers: the printer's own self-test (printer hardware), the Windows test page (driver + port + spooler), then a trivial application document (app layer). Whichever layer first fails is where the problem lives, and the ladder takes five minutes to run while eliminating most of the suspect list.

Where it usually lives: a stuck or corrupted spooled job (most common), a driver/port mismatch after a change (network move, update), or — for the self-test-fails variant — consumables and paper path, which are the printer's own domain.

1. Self-test from the printer's panel. Failure here → consumables/paper path/mechanics; skip to the printer's own manual. Success → continue in Windows.
2. Print the Windows test page (Print queue → Printer properties → Print test page). Failure here with a working self-test → the driver/port/spooler layer is the fault.
3. Clear the queue completely (cancel all documents) and restart the Spooler service — a single corrupted job can block everything behind it, and this is the highest-yield first software fix.
4. Print a one-line document from Notepad. If Notepad prints but your real app doesn't, the problem is that app's document (format, driver-mode compatibility) — see the per-app guide below.
5. If the test page fails with a clean queue, verify the active port (Configure Port → Test) and reinstall the vendor driver package — the two remaining software causes.

What it looks like: documents sit in the queue as "Printing…" or "Paused" indefinitely, and the printer either does nothing or works only after the queue is manually cleared. Stuck queues have a characteristic fork: the first job stuck while later ones queue behind it points at that job's content or the driver's handling of it (a document feature the driver can't spool, a paper-size mismatch); all jobs stuck points at the spooler service itself or the port. The standard recovery is the same either way — clear, restart, delete spool files — but knowing which fork you're in tells you what to fix so it doesn't return.

Where it usually lives: the spooler service state, a poison job (one document that breaks the driver), or a port that stopped delivering. A queue that clogs on a specific document type every time is a driver-format problem, not a spooler problem.

1. Open the queue (Windows 11: Print queue app under the printer; Windows 10: the classic queue window), cancel all documents, and note which job was at the head — its source app and document are your "poison job" candidate.
2. Restart the Print Spooler service (Services → Print Spooler → Restart, or the command in the driver toolbox below).
3. If jobs still won't clear or the spooler won't restart, stop it and delete the contents of C:\Windows\System32\spool\PRINTERS (these are spooled job files only — documents themselves are safe, but re-send anything you cancel), then start it again.
4. For a recurring poison job, identify the document feature (large graphics, special paper size, a PDF with unusual fonts) and adjust the print settings for that document — paper size in the app must match the driver's installed size, a classic silent mismatch.
5. If the queue clogs regardless of document, reinstall the vendor driver package and verify the port with a test — the spooler is then usually exonerated.

What it looks like: the Print Spooler service itself is the problem — it won't start, stops repeatedly, or starts but no printer can talk through it. The spooler is a single Windows service that every print path goes through, so its failure looks like "all printers dead at once," which is itself the clue: a total, simultaneous loss of printing across every printer is a spooler (or a common driver-layer) event, not N separate printer failures. The usual causes are a corrupted spool state, a driver package that crashes the service at load, or (rarely) a damaged service component.

Where it usually lives: spool-state corruption (most common — cleared by the stop/clean/start cycle), a bad driver package (cleared by removing the offending printer's driver), or a service/component repair (rare, fixed by reinstalling the Print Features component).

1. Check the service state: Services → Print Spooler. Note whether it's stopped, crashing, or running-but-useless — and check the Application event log (source: Spooler) for the specific fault, which names the driver or job involved.
2. Run the standard recovery: stop the spooler, delete C:\Windows\System32\spool\PRINTERS contents, start the spooler. This clears the most common corruption state.
3. If the spooler crashes again immediately on start, a driver package is faulting at load: remove your printers one at a time (with their driver packages) and restart the spooler after each removal until it stays up — the last removed printer is the cause.
4. Reinstall the vendor driver package for the removed printer cleanly, and re-add the printer — the goal is the same printing capability without the crashing package.
5. If the service component itself is damaged (won't start even with no printers), repair the Windows print features via Settings → Apps → Optional features (add/reinstall the print-related features) or a System File Checker run (driver toolbox below).

What it looks like: the vendor's driver installer runs and fails — a generic error, a "driver package failed to install" message, or the printer added with a fallback generic driver instead of the vendor one. Install failures cluster around a few causes: the installer being older than the OS build (vendor packages lag), the Windows Update driver catalog interfering (Windows may substitute its own package mid-install), architecture mismatch (a 32-bit package on a 64-bit system for a component that must match), or a security product blocking the driver install.

Where it usually lives: an outdated vendor package (download the current one — the #1 fix), a Windows Update substitution (install offline or right after a clean state), or a blocked install. The "Add a printer → let Windows choose" path deliberately avoids vendor packages and is a fine fallback for basic printing when the vendor installer is the problem.

1. Download the current driver package from the vendor for your exact model and OS version — install failures on older packages are routine, and the vendor's site is the source of truth for what's current.
2. Before running the installer, remove the existing printer and its driver package (see the full-reinstall guide below) so the installer isn't upgrading over a broken state.
3. Run the installer as administrator; if it fails with a specific error, note it — "0x800f0831"-style codes are driver-store/catalog issues and point at the Windows Update substitution path.
4. Fallback path: add the printer via Settings with "let Windows choose a driver" — the catalog driver supports core printing and gets the printer functional while you sort out the vendor package.
5. If a security product is installed, check its block log for a driver-install block before assuming the package is bad — and re-allow the vendor's signature rather than disabling protection permanently.

What it looks like: the vendor driver is installed, works for a while, and then silently reverts — the printer still exists but now runs on a generic driver, features are gone, or the printer errors until the vendor package is reinstalled. This is Windows Update's driver catalog doing its job aggressively: it maintains its own printer driver packages and will replace or supplement what's in the store when it decides its version is a better match, which can undo a vendor installation. It's not a malfunction of your system — it's a policy you have to work with, because there's no supported per-printer "never touch this driver" switch.

Where it usually lives: the driver store, where both Microsoft's and the vendor's packages coexist and Windows re-binds between them — often after updates, often between reboots. Checking what's actually in the store (pnputil, toolbox below) turns this from a mystery into a visible state change.

1. When the driver "disappears," check the printer's current driver (Properties → Driver tab) and the store (pnputil /enum-drivers) — you'll usually see the binding switched to a Microsoft package.
2. Reinstall the vendor's full package (not just the driver component) — full packages register their driver in the store with the metadata that makes it the preferred match.
3. After any major Windows Update, proactively re-check the driver binding — a scheduled 30-second check after updates prevents most "my printer broke overnight" events.
4. Keep the vendor package current: an old vendor package that Windows keeps replacing may be losing the match legitimately; the current vendor package usually wins the binding.
5. If the churn continues with current packages from both sides, run the printer on the Microsoft catalog driver deliberately — for most models it covers everyday printing, and a stable generic driver beats a flapping vendor one.

What it looks like: pages come out — the mechanism works, paper feeds, counts increment — but they're blank. Blank pages are almost always a consumable or transfer problem, with the driver as a distant third. On lasers, the classic causes are a toner cartridge that's empty, seated wrong, or still has its transport lock/wrapper in place, and (for older machines) a failing fuser that isn't transferring toner. On inkjets, dried or empty cartridges and a blocked printhead. The driver enters the picture mainly through paper-type settings, which change how the machine treats the media.

Where it usually lives: the toner/ink cartridge (fit, charge, seals), the paper-path settings in the driver, or — for lasers with otherwise healthy consumables — the fuser. The self-test page is the split: a blank self-test is the printer's own problem; a good self-test with blank Windows prints is the driver/settings path.

1. Print the printer's self-test. Blank self-test → the fault is inside the printer (consumables/transfer): continue there. Normal self-test → the problem is in what Windows sends: jump to step 4.
2. Remove and reseat the toner/ink cartridge(s); for a new toner, remove all transport locks and wrapper tape (a sealed new cartridge prints blanks by design of its seal).
3. Try a known-good cartridge if one is available — the definitive consumable test. For lasers, run the vendor's cleaning/transfer routine from the printer's maintenance menu.
4. On the driver side, check the paper type/size match between the driver settings and the actual tray (a "thick paper" setting on plain stock changes fuser behavior on lasers), and print the Windows test page again.
5. For a laser that self-tests blank with good toner and clean settings, the fuser or transfer roller is the likely failed part — a service/repair decision, not a settings one.

What it looks like: the printer works, but jobs take minutes where seconds used to be normal — or the first page takes forever while subsequent pages are fine. Slow printing has a short cause list with very different fixes: the driver's processing mode (some drivers rasterize complex documents slowly, especially PostScript-driven jobs on light drivers), the document itself (heavy graphics, high effective DPI), the network path (a Wi-Fi printer on a congested link is bandwidth-bound), or the spooler waiting behavior. The first-page-forever variant is the spooler processing the whole job before release, which is normal behavior misread as slowness.

Where it usually lives: the driver/driver mode, the document's complexity, or (for network printers) the link. A USB printer printing a simple document slowly points at the driver; a network printer printing everything slowly points at the network first.

1. Time a controlled job: one page of plain text, then a graphics-heavy page. Text fast, graphics slow → document/driver-processing (expected behavior for complex jobs). Both slow → driver or path problem.
2. For network printers, compare printing over Wi-Fi versus wired (or move the test PC closer to the router) — if speed tracks the link, the network is the bottleneck, not the printer stack.
3. In the driver's preferences, drop the print quality/DPI for the test and switch any "high quality" or "photo" mode to "draft/normal" — a large share of "slow printer" reports is a quality setting set for photos being used for documents.
4. Check the driver mode where exposed (PCL vs PostScript vs EMF on the same model): a model that's slow on one mode is often fast on the other, and the mode choice is per-driver-install.
5. If a simple USB document is slow with a draft setting, reinstall the vendor driver package — a corrupted or mismatched driver is the remaining software cause.

What it looks like: a printer on the network — directly or shared from another PC — won't connect: the port test fails, the add-printer wizard times out, or a previously working network printer is suddenly unreachable. Network printing adds the whole network stack under the print stack, and each layer has its own failure: the printer's IP (changed by DHCP), the path (subnet, router, firewall), the sharing layer (SMB for shared printers), and the port type in Windows (WSD vs Standard TCP/IP behave differently). The ping test from the PC to the printer's IP is the first split: no ping means the network layer; ping works but the port fails means the print layer.

Where it usually lives: an IP that moved (DHCP lease renewal), a firewall blocking the print paths (especially for shared printers over SMB), or a WSD port that lost the printer. Shared printers add the host PC's availability and its sharing settings to the chain.

1. Ping the printer's IP from the PC. No response → network layer: check the printer's current IP (its config page — it may have changed), the cable/SSID, and that both devices are on the same subnet.
2. For a stable fix, give the printer a DHCP reservation on the router (or a static IP) and re-create the Windows port with that address — flapping IPs are the most common "network printer died" cause.
3. Test the Windows port: printer Properties → Ports → Configure Port → Details. A failing port with a pinging IP points at the printer's print services or the port type — recreate the port as Standard TCP/IP if it was WSD.
4. For shared printers (printed via another PC), verify the host is on, that File and Printer Sharing is enabled on both machines, and that the firewall allows the SMB print paths — Windows 10/11 firewalls block new share paths by default.
5. Re-add the printer with the verified IP and vendor driver, then send a test page from a second PC to confirm the fix is network-wide, not per-machine.

What it looks like: a wireless printer drops off the network periodically — Windows shows it offline, the IP "can't be reached," and it often comes back after a power cycle or a day. Wi-Fi printers add two failure modes that wired printers don't have: the IP lease (the printer's address can change when its DHCP lease renews, silently breaking the Windows port) and the wireless link itself (range, band, the printer's own power-saving radio behavior, and router features like AP isolation). The signature question is what precedes the drop: nothing (lease or link), a long idle period (printer radio power-save), or a router change (settings, firmware, band steering).

Where it usually lives: the IP lease (most common — fixed with a reservation), the printer's Wi-Fi power saving, or a router-side setting. A printer that drops only after long idle is the power-save signature; one that drops at seemingly random times is usually the lease or the link.

1. Compare the printer's current IP (config page) with the IP in the Windows port. Different → the lease changed; set a DHCP reservation on the router for the printer's MAC and update the port.
2. In the printer's network settings, disable Wi-Fi power saving / "energy save" radio behavior — printers that nap their radio are a classic idle-drop cause.
3. Check the band: if the printer is on 5 GHz and the PC is sometimes on 2.4 (or vice versa), band steering can separate them; pin the printer to the band the PCs actually use, or to 2.4 GHz for range.
4. Review the router for AP/client isolation and "print server" features that were enabled or changed — isolation modes break printer discovery and direct printing in different ways.
5. If the drops continue with a reserved IP and power-save off, test the printer on a wired connection: stable wired, flaky wireless → the printer's radio or its placement; flaky both → the printer or the router.

What it looks like: the same document (or any document) prints fine from one program and fails or misbehaves from another — stuck, blank, wrong format, or "printer unavailable" in the app that works everywhere else. Per-app print failures live in the layer between application and driver: each app submits its document in its own format and with its own printer selection, and the driver's handling of that format is where compatibility problems show. A driver that handles Notepad's simple stream fine can choke on a specific app's graphics or fonts. There's also a mundane version: the failing app is silently targeting a different printer (a per-app default, or a PDF/virtual printer that got selected).

Where it usually lives: the failing app's printer selection (check first — it's free), the driver's handling of that app's document format, or (for the "works for one user, not another" variant) per-user driver registration. The cross-app comparison is the diagnostic: same printer, same document, different result = app/driver-format layer.

1. In the failing app's print dialog, verify the selected printer is the real one — per-app defaults and leftover virtual/PDF printers are the cheapest explanation and the first to check.
2. Print the same document from the working app and from the failing app with identical settings. If the document prints from the working app, the fault is the failing app's output, not the printer or driver globally.
3. Simplify the document in the failing app: remove heavy graphics, unusual fonts, or a specific page. If a particular element breaks it, that element is the driver-format incompatibility — print that content via a different app or as an image.
4. Update or reinstall the vendor driver — driver updates frequently fix per-format spooling bugs, and a clean reinstall resets the driver's per-format state.
5. For the per-user variant (works in one account, not another), re-add the printer and its driver in the affected user's account — drivers are registered per-user as well as per-system, and a broken per-user registration behaves exactly like a per-app failure.

What it looks like: the same physical printer shows up two or three times in the printer list — "Office Printer," "Office Printer (2)," or the same model under a WSD name and a TCP/IP name. Duplicates form because Windows registers a printer once per (port, driver) combination it has learned about: a printer reached by USB, by WSD discovery, and by a manual TCP/IP port is three printer entries pointing at one machine. They're usually harmless — but they're also a real troubleshooting hazard, because jobs sent to the "wrong" duplicate go down a different port path, and a half-broken duplicate can look like the printer is broken when the healthy duplicate works fine.

Where it usually lives: the printer inventory itself — multiple learned ports for one device, plus WSD auto-discovery re-adding entries you've removed. The fix is deliberate: decide on one port path, remove the rest, and accept that WSD may occasionally re-add its favorite (harmless, removable again).

1. Open each duplicate's Properties → Ports and note which port each uses (USB, WSD-…, Standard TCP/IP with which IP). One of them is the path you actually want — usually the TCP/IP or direct USB one.
2. Send a test page from the duplicate you intend to keep, confirming that path is healthy before removing anything.
3. Remove the other duplicates: Settings → Printers & scanners → the printer → Remove. Repeat until only the chosen entry remains.
4. Set the kept printer as the default (and per-app defaults where relevant) so applications stop scattering jobs across removed-and-readded entries.
5. If WSD re-adds its duplicate later, remove it again — or avoid WSD ports entirely by always adding printers with explicit TCP/IP or USB ports, which stops the re-adds at the source.

What it looks like: you've tried the targeted fixes — port tests, spooler restarts, driver updates — and the printer's state is too tangled for patches: wrong driver bound, stale port, spooler state that survives restarts. The complete removal is the reset that clears every layer at once: the printer entry, its port, its driver package, and its spool state. Done properly it's the most reliable printer fix in existence; done partially (removing the printer but leaving the driver package) it often isn't a fix at all, because the bad driver survives in the store and re-binds on the next add.

What "complete" means: four layers — the printer object, the port, the driver package in the store, and the spool state. Skipping the driver package layer is the most common incomplete reset. The procedure below is the full one; it's the endpoint several other guides in this section point to.

1. Cancel all jobs in the queue, then remove the printer: Settings → Printers & scanners → printer → Remove.
2. Remove the port and driver package: run control printers (Print Management / Print server properties) → Ports tab → remove the printer's custom ports; → Drivers tab → remove the printer's driver package. (The toolbox's pnputil commands do the same from the command line.)
3. Restart the Print Spooler service so all removed state is fully released.
4. Reinstall the vendor's current driver package from the manufacturer's site, then add the printer fresh — with the explicit port you want (TCP/IP with the reserved address, or USB).
5. Verify the full stack: correct driver in Properties → Driver, correct port in → Ports, a successful test page, and a real document from your main application. Only then is the reinstall "done."

What it looks like: the printer worked, a Windows Update installed, and printing degraded — offline, wrong driver, missing features, or (on some Windows 11 builds) built-in options like "Microsoft Print to PDF" behaving differently because those moved to store-based optional features in 22H2 and later. Update regressions in printing have two distinct shapes: the driver was replaced (the "driver disappearing" guide covers the mechanics), or the update changed a component the print path touches. The timeline check is the same as for USB: the Update history names the suspect, and the driver date in the printer's properties tells you whether the driver was the thing that changed.

Where it usually lives: a replaced driver package, a changed print-related component, or (version-specific) the optional-features move for built-in print targets. The fixes are the standard regression tools: re-apply the vendor driver, or uninstall the specific update.

1. Check the printer's driver date/provider against the update timeline. Driver changed → follow the full-reinstall guide to restore the vendor package cleanly.
2. Check Update history for the update that preceded the change, and note its KB number — it's the reference for everything that follows.
3. For changed built-in print targets (Print to PDF, XPS on Windows 11 22H2+), verify the optional features are present: Settings → Apps → Optional features → add the print-related features if missing.
4. If the vendor driver restore doesn't fix it, uninstall that specific update from Update history and reboot, then re-test printing before Windows reinstalls the update.
5. After any fix, re-verify across a reboot and note the KB number that caused the issue — if the same update re-breaks printing after the next cycle, the vendor-driver re-apply becomes a scheduled post-update step.

What it looks like: the pairing dialog finds the keyboard, but the pairing fails, completes without the keyboard working, or the keyboard simply never appears in the add-device list. This guide takes the Windows-side view of the pairing flow (the device-side pairing-mode steps are in the keyboard section): the adapter has to be healthy and its driver current, the Bluetooth services running, the device not bonded elsewhere, and the adapter not suppressed by power management or a stuck disabled state. "Not appearing at all" is the adapter's signal; "appears but fails" is usually the bond or the PIN step.

Where it usually lives: a stale bond (the keyboard remembers another device), the adapter's driver or power state, or a Bluetooth service that stopped. If no Bluetooth device can pair on this PC, the adapter is the whole story.

1. Verify the adapter exists and is healthy in Device Manager (Bluetooth section) — a missing or warning adapter skips straight to the Bluetooth driver guide below.
2. Remove any existing entry for the keyboard, confirm the keyboard is out of bond with its previous machine (its manual's reset/pair procedure), and re-enter pairing mode fresh.
3. Add from Settings → Bluetooth & devices, and handle the PIN step deliberately: try the shown value, blank, then 0000 — keyboards differ and the manual states which.
4. Check the two Bluetooth services (Bluetooth Support Service and the GPIO/RFComm family) are running and set to automatic — a stopped service produces exactly "adapter present, pairing impossible."
5. Disable the adapter's Power Management "allow turn off" option and toggle the adapter off/on (Device Manager disable/enable) to clear a stuck radio state, then re-pair.

What it looks like: the mouse is paired (it shows in the device list) but won't connect, or connects and the cursor stays dead. Bluetooth mice are HID devices, so "connected" at the radio layer and "functional" at the input layer are separate states — the failure can sit in the connection attempt (range, power, the mouse's own state after a battery change) or in the HID function (the link is up but no input crosses it). The battery question comes before the software questions: a Bluetooth mouse on weak batteries will pair, connect, and still not track, because the radio and the sensor compete for the same dying power.

Where it usually lives: battery state, a stale bond after battery swap, range/interference, or the adapter's power management. A mouse that's dead here but fine paired to a phone is telling you the PC's adapter or stack, not the mouse.

1. Fresh batteries, then re-pair rather than just reconnect — battery swaps routinely break the bond on the mouse side, and reconnection alone can't rebuild it.
2. Close the distance for the test: the mouse at arm's length from the PC, no metal enclosure between them. A range-limited mouse "connects" at the edge and drops the instant it moves.
3. Keep the adapter away from USB 3.0 ports and hubs (shared 2.4 GHz band) and disable its Power Management "allow turn off" option.
4. Test the mouse paired to a phone or tablet: functional there → this PC's adapter/stack (continue with the adapter guide); dead there → the mouse.
5. Remove and re-add the mouse in Windows, then check its HID entry in Device Manager for a warning code — a Code 43 on the mouse's HID entry after a clean re-pair points at the adapter's radio, not the mouse.

What it looks like: the device shows "Connected" in Windows — the radio link is genuinely up — but it does nothing: no cursor from the mouse, no keys from the keyboard. This is the most diagnostically useful Bluetooth state, because it clears the entire radio layer from suspicion: pairing, range, interference, and the link itself all work. What remains is the function layer — the HID path between the connected device and Windows' input system — plus the device's own firmware state. A connected-but-dead device is usually a HID/driver problem or a device that needs a full power cycle to re-establish its input function.

Where it usually lives: the device's HID driver/entry, the device's internal state (fixed by a true power cycle, not just disconnect), or — when every connected device is dead — the adapter's HID handling. The phone test remains the cleanest isolation available.

1. Power-cycle the device fully (off, batteries out for a few seconds, back in) and reconnect — a stuck device state that survives "disconnect" is cleared by real power removal.
2. Check the device's HID entry in Device Manager for a warning code; a Code 43/10 there is the fault made visible, and that code's guide is the next step.
3. Verify the Bluetooth services are running (a stopped support service can leave links up while input dies), and restart the adapter (disable/enable in Device Manager).
4. Update the adapter driver from the vendor (the adapter guide below has the paths) — connected-but-dead HID is a classic adapter-driver signature.
5. Run the phone test: the device paired and functional on a phone with this PC's adapter also dead on a second PC confirms the adapter; functional on a phone and dead only here confirms this machine's stack.

What it looks like: a Bluetooth device connects, works for a while, drops, and reconnects — or drops and stays down until re-paired. Disconnects have the same cause family as wireless mouse drops (range, interference, power) plus two Bluetooth-specific ones: the adapter's own power management (Windows turning the radio off to save power), and band congestion — Bluetooth shares 2.4 GHz with Wi-Fi, and a busy router or a neighboring USB 3.0 device can degrade the link enough to cause periodic drops. The pattern still matters: drops that follow distance/movement are range; drops that follow idle are power management; drops that are constant in one spot and fine in another are interference.

Where it usually lives: adapter power management, USB 3.0 adjacency, range/obstacles, or Wi-Fi band congestion. A drop pattern that follows the PC's idle time is the power-management signature and the cheapest fix on the list.

1. Map the drop pattern for a day (distance, idle time, what else is plugged in) — the pattern names the cause class before any setting changes.
2. Disable the adapter's Power Management "allow turn off" option in Device Manager and test across idle periods — the idle-drop signature should disappear.
3. Relocate the adapter: a rear port, no adjacent USB 3.0 device, and (for a USB BT dongle) a short extension away from the case — USB 3.0's switching noise sits right in Bluetooth's band.
4. Reduce Wi-Fi congestion where possible: move the router's 2.4 GHz channel, or shift heavy Wi-Fi traffic to 5 GHz, and re-test the drop rate.
5. If drops persist with power management off and the adapter relocated, update the adapter driver (vendor) and re-test; a driver-level radio bug is the remaining software cause.

What it looks like: a Bluetooth peripheral that previously appeared in Windows is gone from the device list — or no Bluetooth device appears, and the "Add device" flow finds nothing. The first distinction is whether the problem is this device or all Bluetooth: one device missing is a bond/inventory problem (it can be removed and re-added); no devices found at all is an adapter problem (the radio, its driver, or its services). Windows also has a few state layers that hide devices: airplane mode, a disabled adapter, and the difference between "paired but forgotten" and "never paired here." Check the adapter's presence before touching the device — a missing adapter explains every missing device at once.

Where it usually lives: a disabled/airplane-mode state, the adapter driver, a stopped Bluetooth service, or (for a single missing device) a lost bond that a remove-and-re-add restores.

1. Check the obvious states first: airplane mode off, Bluetooth toggle on, and the adapter present and enabled in Device Manager (Bluetooth section, and under View → Show hidden devices for a disabled-but-present adapter).
2. If the adapter itself is missing or warning, go straight to the Bluetooth driver guide below — every device-level check is moot without a healthy adapter.
3. Confirm the Bluetooth services are running (Bluetooth Support Service at least), and restart the adapter via disable/enable in Device Manager.
4. For a single missing device: remove any stale entry, put the device in pairing mode, and re-add it — a lost or corrupt bond presents exactly as "device missing."
5. Run "Scan for hardware changes" in Device Manager after re-pairing; if the device still doesn't register while pairing succeeds on a phone, the adapter's pairing pipeline is the failure — driver update, then the dongle test below.

What it looks like: multiple Bluetooth peripherals fail in the same way — pairing breaks, devices connect-dead, the radio drops — which is the signature that the shared adapter, not any one device, is the fault. The adapter is a single point of failure for the whole Bluetooth family, and its driver is the usual suspect: a bad Windows Update driver, an outdated vendor driver (Intel, Realtek, MediaTek, and Qualcomm all ship adapter-specific packages), or a driver state that a clean disable/enable won't clear. The definitive isolation test for an internal adapter is a known-good USB Bluetooth dongle: if peripherals work through the dongle, the internal adapter (driver or hardware) is confirmed.

Where it usually lives: the adapter driver (update or rollback), the Bluetooth services, or the adapter hardware itself. When two unrelated Bluetooth devices fail identically on one PC and work on another, this guide is the path.

1. Identify the adapter (Device Manager → Bluetooth: the adapter's vendor/model) and its driver date — a date matching a recent Windows Update is the regression signature; use Roll Back Driver if offered.
2. Install the adapter vendor's current driver from the manufacturer's site (laptop vendor for built-in adapters, chipset vendor otherwise) — vendor packages beat the generic Microsoft driver for radio behavior.
3. Verify and restart the Bluetooth service family, and disable the adapter's power management option — a service stop plus a power-managed radio reproduces most "adapter flaky" reports.
4. Toggle the adapter off/on, then in UEFI check that the built-in wireless/Bluetooth isn't being disabled or set to a legacy mode by a firmware setting.
5. Run the dongle test: a known-good USB Bluetooth adapter in the same PC. Peripherals work through it → the internal adapter is the failed component (driver-unfixable at that point); they fail through it too → the PC's stack or the devices.

What it looks like: Bluetooth devices work, the PC sleeps or hibernates, and on wake one or all of them are gone or dead until re-paired or re-plugged (power-cycled). The Bluetooth radio's resume behavior is the weak point in this chain: the adapter returns from S3/hibernation, but the devices' links don't re-establish, or the adapter's driver loses its device table. The two configuration levers that change this behavior are the adapter's power management (whether Windows is allowed to deep-sleep the radio) and Fast Startup (which changes what "wake" involves by resuming a hibernated kernel). A device that fails after sleep but never during live use is, like the USB variant, telling you exactly which path is broken.

Where it usually lives: adapter power management plus a weak resume (most common), Fast Startup interaction, or the adapter driver's resume handling. Hibernation-only failures (fine after sleep, broken after hibernate) point more strongly at Fast Startup and the hibernated state.

1. Disable the adapter's Power Management "allow turn off" option and re-test across sleep and hibernate separately — note which sleep state breaks it; the answer narrows the cause.
2. Test with Fast Startup disabled (Power Options → power buttons → change settings currently unavailable) — hibernate-linked Bluetooth failures frequently clear with this, because the radio no longer resumes into a hibernated kernel state.
3. Update the adapter driver from the vendor — resume bugs in Bluetooth adapters are fixed in vendor packages more often than in generic updates.
4. As a behavioral workaround while the cause is sorted: disconnect the peripherals before sleep and reconnect after — it's not a fix, but it separates "resume always breaks them" from "resume usually survives."
5. If one specific device always fails resume while others survive, its own firmware is the weak link — check the vendor for a firmware update, and keep the disconnect-before-sleep habit for that device.

What it means: Windows tried to start the device and failed — the device is present, enumerated, and assigned a driver, but the start sequence broke. Code 10 is a "the machinery turned but the engine didn't catch" code, and its sub-messages split the causes: a dependency problem (the device waits on a parent that's failing), a power problem (the device was denied start by power policy — see Code 32's cousin behavior), a service problem (a service the driver needs is stopped), or a driver problem (the driver itself failed to initialize). Read the message under the code before choosing a path — it usually names the failing dependency.

Usual culprits: a failing parent (USB hub, controller), a stopped dependency service, or a driver that can't initialize on this hardware state. Peripheral Code 10s that follow a sleep/wake are power-state problems wearing a startup costume.

1. Read the full Code 10 message — "depends on a device that isn't working" names the parent to check; other phrasings point at the driver or a service.
2. Check the parent chain in Device Manager (the hub/controller above the device) for its own warning — a sick parent produces Code 10 children.
3. Look for the device's start failure in the System event log (PnP and driver sources around the time the code appeared) — the log line usually states the specific failure.
4. Restart the device (disable/enable in Device Manager) to clear a stuck start state, and verify any dependency services are running and set to automatic.
5. Reinstall the device's driver (uninstall + scan for hardware changes); if Code 10 persists across a clean driver install on multiple ports, weight hardware failure and cross-test the device.

What it means: the device is present and would work, but it's been disabled — deliberately or accidentally. Code 22 is the most "boring" code and the most fixable: the fix is Enable Device, and the investigation is finding what disabled it. The usual disablers are a user (including a past-you following an older tutorial), a driver that got disabled during a driver operation, a group policy on managed machines, or a power-management action that left the device in a disabled-looking state. Hidden and disabled devices accumulate in Device Manager over time, and a stale disabled entry can also block a clean re-enable — which is why the hidden-devices view is part of this code's workflow.

Usual culprits: an intentional disable that outlived its purpose, a driver operation side effect, or (on work/school machines) policy. The fix path is short; the value is in not re-breaking it the same way.

1. Right-click the device → Enable device. If the option isn't there or the device re-disables, the disabler is active — continue diagnosing rather than clicking.
2. Check the driver tab for a disabled driver state, and re-enable via the driver properties if present.
3. On a work/school-managed machine, check whether a policy disables the device class (Settings → Accounts → Access work or school, and your IT's documentation) — policy-disabled devices re-disable after manual enable.
4. Show hidden devices (View → Show hidden devices) and clean up stale disabled entries for this device, then re-enable the live one — stale twins are a recurring re-break cause.
5. If the device enables cleanly and stays enabled, note what you changed and why — Code 22 returns whenever the same operation is repeated, and the note is what prevents the loop.

What it means: the driver loaded but is misbehaving — Windows has evidence (a failed operation, a bad response from the driver) that the software controlling the device is faulty. Code 24 is the driver-layer's "your software is the problem" code, and its fix ladder is the standard driver ladder: roll back (if a previous version exists and the problem is new), then reinstall the driver cleanly, then install the vendor's package over the generic one. The timing question decides the first rung: if the malfunction started after a driver update, rollback is the fast path; if the device has always behaved this way, the current driver is simply wrong for this hardware and the vendor package is the move.

Usual culprits: a bad driver version (update regression), a generic driver where the vendor driver is required, or a corrupted driver registration. A Code 24 that survives a clean vendor reinstall is unusual and starts to implicate the hardware's response to the driver.

1. Check the driver date/provider and the problem's timeline. Problem is new → Roll Back Driver first; it's the least invasive fix and it's reversible.
2. If rollback isn't offered or doesn't help, uninstall the device (with "delete the driver software for this device" where offered) and Scan for hardware changes for a clean rebind.
3. Install the vendor's current driver package from the manufacturer — Code 24 on a generic driver is the classic "this device wants its real driver" situation.
4. Check the driver toolbox commands (pnputil /enum-drivers) for multiple or stray packages for this device's hardware ID; remove identifiable leftovers and rebind.
5. If a clean vendor driver still produces Code 24 on this PC but the device is clean on another, the hardware's interface is the failing party — the driver is being answered badly by the device.

What it means: Windows found the device but has no usable driver for it — no match in the driver store, or a match that failed to install. Code 28 is the honest "we don't have software for this" code, and the fix is installation, with the source depending on the device: Windows Update's catalog covers most common peripherals, while niche devices (specialty scanners, capture hardware, some industrial peripherals) need the vendor's package. The offline dimension matters: a machine without internet can't use the catalog path, and the vendor package installed from media is the route — the toolbox's pnputil add-driver command is how that works from the command line.

Usual culprits: a device newer than the catalog's coverage, a driver package that failed partway (leaving a Code 28 instead of a working device), or an offline machine. A Code 28 that appears after previously working is usually a store change — check what touched the driver store recently.

1. Try the built-in path first: right-click the device → Update driver → Search automatically (this uses Windows Update's catalog). Many Code 28s clear here.
2. If the catalog has nothing, download the vendor's driver package for the exact model and install it — for the command-line path, pnputil /add-driver "path\to\inf" /install (toolbox below).
3. On an offline machine, prepare the vendor package on another PC and install from local media — and note that the same machine will stay Code 28 for any catalog-only device until it's online.
4. If a previously working device is now Code 28, inspect the store (pnputil /enum-drivers) for a removed or broken package and restore it (rollback or re-add) — the store changed under the device.
5. Verify the device class is what you expect (a device showing under the wrong class won't match the right driver) — a misclassified device is a rare but real Code 28 cause, fixed by removing and re-scanning.

What it means: the device stopped working — either the system stopped it (usually a power policy decision) or the device reported a failure to the system. Code 31 sits between the software and hardware explanations, and the sub-message is the fork: "Windows has stopped this device because it has reported a problem" is the device telling on itself (hardware-leaning), while stop-due-to-power-settings phrasings point at the power layer (Code 32's territory). The event log is unusually valuable here — a Code 31 usually has a companion log entry that states the stop reason, which collapses the fork quickly.

Usual culprits: a power-management stop (fixable in settings), a driver that stopped the device after a failed operation, or a genuinely failing device reporting its failure. A Code 31 that follows the device across machines is the device; one that's port-specific is the path.

1. Read the Code 31 sub-message and find the companion System-log entry — the stop reason there decides between the power path and the hardware path.
2. For power-related stops: disable USB selective suspend and the relevant hub's power-off option, then re-test — the Code 31 should clear on the next device cycle.
3. For driver-reported stops: update or reinstall the driver, and check whether a specific operation (a sleep, a particular app) precedes the stop — the trigger is part of the diagnosis.
4. Cross-test the device on another machine. Code 31 follows the device → the device is failing and reporting it honestly; stays behind → this PC's path or stack.
5. For a confirmed failing device, note the Code 31 as the evidence — it's the device's own failure report, which matters when deciding repair vs. replace.

What it means: the device isn't running because a power setting told it to stop — this is the explicit, named version of the power-management stop. Code 32 is the least mysterious code in Device Manager: the cause is stated in the message, and the fix is the power settings that made the statement. For USB peripherals it's almost always USB selective suspend at the plan level or the "allow the computer to turn off this device" option at the hub level; for other device classes it's the equivalent power option on that device. The setting path is identical in Windows 10 and Windows 11, which makes this one of the most portable fixes in the library.

Usual culprits: selective suspend (USB), a per-device power option, or a power plan that was changed (a "battery saver" plan on a laptop is a common surprise source). The fix is safe and reversible — disabling a power-saving stop costs a little standby power and buys reliability.

1. Read which power setting the message names — it's usually specific enough to go straight to the control.
2. For USB devices: set USB selective suspend to Disabled in the active power plan (Power Options → Change plan settings → Show additional settings → USB settings), identical path in both versions.
3. On the device's parent hub (and the device itself where offered), uncheck "Allow the computer to turn off this device to save power" in Properties → Power Management.
4. Check which power plan is active — a battery-saver plan with aggressive USB settings explains a Code 32 that appears only on battery power; set the same USB options in that plan too.
5. Re-enable the device after changing settings (disable/enable in Device Manager) so it picks up the new policy immediately, and confirm the code is gone rather than just the icon.

What it means: the device (or its driver) reported a malfunction and Windows stopped it. Code 43 is Device Manager's catch-all — the most common code on failing peripherals and the one that most needs discipline, because it covers everything from a trivial driver state to a dead device. The message under the code is where the investigation starts: "a major fault or failure was detected," "the device has reported problems to the operating system," and "Windows has stopped this device because it has reported problems" are three different evidence types with different weights. The event log entry that accompanied the code's appearance usually names the specific fault, and the cross-test (device on another machine) is the arbiter when software fixes are exhausted.

Usual culprits, in frequency order: a driver state problem (cleared by clean reinstall), a power-management stop that surfaces as 43 (cleared by the Code 32 fixes), a failing device reporting itself (not clearable — replace), or device firmware at fault (vendor update). Treating Code 43 as "reinstall the driver and hope" is how people burn a week on a dead device; the ladder below is the ordered version.

1. Read the exact Code 43 message and pull the companion System-log entry — together they usually name the failing component (driver, power, or the device itself).
2. Clear the software states: disable/enable the device, uninstall + rescan, and a clean vendor driver reinstall. A Code 43 that clears here was a state/driver problem.
3. Apply the power fixes (selective suspend off, hub power options) and re-test — a surprising share of 43s are power stops in disguise.
4. Cross-test the device on another machine. Clean there → this PC's path/stack; Code 43 there too → the device or its firmware.
5. For a device that Code 43s everywhere: check the vendor for a firmware update (some devices ship 43-fixing firmware); if none exists or doesn't help, the device has reported its own end — replace it, with the code and log entries as the evidence.

What Code 45 means: "The device has been disconnected" or "isn't configured properly" — the connection layer lost the device, or the device came up in a state Windows can't use. Code 45 is the connection code: a marginal port or cable that drops the device, a power state that un-seats it logically, or a device that enumerates incompletely. Its fix family is physical and power: re-seat and re-cable, change ports, fix the power path — with a full power cycle of the PC (not just a reboot) to clear the PnP state when the connection is physically solid but Windows still insists. What Code 52 means: "A required registry or file is missing" — specifically, the driver package's INF file (the file that describes the driver) is absent or corrupt. Code 52 is not a "download a driver" code in the usual sense; it's a "the installed package is incomplete" code, and the fix is reinstalling the package so the INF returns to the store.

Usual culprits: for 45 — connection quality, power state, or a stuck PnP record; for 52 — a driver package that failed partway through installation, or a store operation that removed the INF while leaving the binding. Both are more mechanical than they look once you know which layer each one names.

1. Code 45: re-seat the device and cable, try a different (rear) port, and do a full shutdown power cycle (hold power off 30 seconds) before rebooting — a stuck PnP state clears with real power removal when the connection is physically fine.
2. Code 45: check the port path (hub, front header) and the device's power; a device that's under-powered enumerates partially and lands on 45.
3. Code 52: reinstall the driver package from the vendor (full package, not just "update driver") — the reinstall restores the missing INF to the store.
4. Code 52: verify with pnputil /enum-drivers that the package now lists its INF; a package that reinstalls but still lacks the INF is corrupt at the source — get a fresh copy of the package.
5. After either fix, confirm the device is clean across a reboot — both codes can return if the underlying cause (marginal connection, incomplete package) wasn't actually addressed.