PC Turns On but Keyboard or Mouse Does Not Work: USB Ports, Firmware, Windows, and Input Troubleshooting

Record the last stage where input works: immediately after power-on, firmware/UEFI, the boot menu, Windows Recovery Environment, the sign-in screen, or the normal desktop. Also record whether both keyboard and mouse fail, only one device fails, or a wired basic device behaves differently from a wireless receiver or hub-connected device. A device that works in firmware but stops when Windows loads points to a different boundary from a device that never works before the operating system starts.

Keep this separate from an intermittent peripheral that works normally and later disconnects during Windows use; that case belongs in the USB disconnect workflow. If the PC itself cannot complete POST or establish a usable display, use the no-POST workflow instead of treating missing input as the primary failure.

For a desktop, remove nonessential USB devices and test one known-good wired keyboard or mouse directly on a rear motherboard USB port when practical. Bypass front-panel extensions, monitors with USB hubs, docks, KVMs, external hubs, and adapters during this comparison. ASUS documents rear-port and wired-keyboard checks for systems that cannot accept keyboard input before the operating system loads.

Change one variable at a time. If one known-good device works directly but not through a hub or front-panel path, investigate that shared path. If the same device fails everywhere, compare another known-good device before concluding that every USB port or the motherboard has failed. Do not probe USB power, repin connectors, or improvise wiring.

If a wired keyboard can navigate firmware/UEFI reliably, the device and at least that USB path are functioning before Windows loads. ASUS documents keyboard navigation in its current UEFI support material, while its NUC guidance notes that Bluetooth keyboards may not be available before operating-system drivers load. Treat those as platform-specific examples, not a promise that every firmware supports every USB or wireless device identically.

If no known-good wired input works in firmware, consult the exact motherboard or system manual and support documentation. Do not invent a universal “legacy USB” setting or blindly toggle firmware options. Fast-boot behavior and available USB settings vary by platform. Restore documented defaults only when you understand the effect and can safely preserve any boot, storage, or encryption-related configuration that matters.

When firmware input is reliable but the keyboard or mouse stops at Windows startup or sign-in, preserve that distinction. Check whether another basic wired HID device behaves the same way and whether the failure began after a Windows, chipset, USB-controller, peripheral-software, or motherboard change. Use Windows Update and the exact PC, motherboard, or peripheral vendor support path for relevant drivers rather than installing generic driver bundles.

Avoid uninstalling every USB controller or input device as a first step. Broad removal can erase useful topology and driver evidence while making recovery harder without working input. Make only changes that are tied to the affected device or platform and that can be reversed.

A difference between normal Windows and a recovery environment can be useful evidence because the software and driver environment differs. If input works in WinRE or Safe Mode but not in normal Windows, focus on software, driver, service, or device-management changes associated with normal startup. If input fails in both Windows and recovery but works in firmware, the boundary is still after firmware and should be documented before deeper repair.

Do not assume recovery input will always work. Microsoft has documented Windows servicing issues that affected USB keyboard and mouse input in WinRE, so current Windows update history and known issues can matter. Do not follow unofficial recovery-image replacement scripts, registry edits, or destructive reset/reinstall instructions merely to restore input.

Wireless receivers, Bluetooth devices, gaming peripherals, docks, and monitor/KVM hubs add firmware, pairing, power, software, or hub dependencies that a simple wired USB keyboard may not have. Use a basic known-good wired device as a diagnostic comparison when available; success with it does not prove the original peripheral is defective, but it narrows the failing path.

Check batteries, receiver placement, vendor pairing state, and the exact device documentation where relevant. Do not infer that a Bluetooth keyboard must work in firmware or recovery just because it works after Windows loads. Likewise, do not assume a front-panel or hub-connected port is electrically or topologically equivalent to a direct rear motherboard port.

Once Windows can be controlled safely, inspect the affected keyboard, mouse, HID device, USB hub, and parent controller in Device Manager. Record problem status, driver provider/version, and whether multiple failing devices share a parent branch. This evidence is more useful than removing all controllers at once.

If the symptom becomes an ordinary disconnect/reconnect after Windows is usable, move to the dedicated USB disconnect article for selective suspend, USBView topology, event tracing, and workload correlation. This page intentionally stops at the startup/input-availability boundary rather than duplicating that deeper intermittent-disconnect workflow.

Escalate with a concise matrix: which keyboard and mouse were tested, wired or wireless, direct rear port versus hub/front-panel path, whether input works in firmware, WinRE, Safe Mode, sign-in, and normal Windows, plus relevant firmware/Windows/driver changes. That pattern helps distinguish peripheral, physical-path, firmware, recovery-environment, and normal-Windows branches without assigning a failed part from one symptom.

Stop if continued testing would require unsafe electrical work, destructive Windows recovery, firmware flashing without a documented reason, or changes that could jeopardize encrypted or important data. Preserve a working alternate-access path when one exists and use the exact system or motherboard support procedure for any firmware-level change.