Keyboard and Mouse Dead in Windows 11 but Working in BIOS and Recovery? How to Repair Corrupt Input Drivers

When your keyboard and mouse work in the BIOS, in the Windows Recovery Environment (WinRE), and from a bootable USB installer, but go completely dead the moment Windows 11 itself starts — including Safe Mode — you are almost certainly dealing with corrupt or mismatched system driver files, not failing hardware. The good news is that this can usually be fixed in place, without reinstalling Windows or losing your data, settings, or programs.

Why the failure pattern points to drivers

The keyboard and mouse support built into the BIOS, WinRE, and the Windows setup environment is self-contained: those environments load their own minimal, known-good copies of the input and USB stack. Once the full operating system boots, it instead relies on driver files stored in C:\Windows\System32\drivers. If those files are damaged, replaced with incompatible versions, or corrupted by a failed update, every input device will stop responding the instant Windows takes over.

A useful confirmation sign: the Caps Lock indicator light never toggles. That light is controlled by the keyboard class driver in the loaded OS, so if the driver stack is broken, the OS never even processes the keystroke — the hardware itself is fine, which is also why the same devices work on other computers.

First steps: get a command prompt and map your drives

You do not need a working GUI for this repair. Boot into WinRE (it will respond to your keyboard normally) and open a command prompt, or use the command prompt from installation media.

Drive letters inside WinRE often do not match what you see in Windows. Your system drive might not even be mounted. Use diskpart to inspect and assign letters:

diskpart
list volume
assign letter=F
exit

Identify which volume holds your broken Windows installation (it contains a Windows folder) and which one is your installation media, and note the letters you assigned.

Check version compatibility before repairing

The replacement driver files must come from the same Windows build as your installed copy. Find out what your broken install is running:

dism /Image:F:\ /Get-CurrentEdition

Then check what your installation media contains:

dism /Get-WimInfo /WimFile:D:\sources\install.wim

The WIM file typically holds several editions, so note the index number matching your edition (Home, Pro, and so on). Compare the major and minor build numbers between the two. This matters more than most people expect: Microsoft only distributes the newest ISO for download, and if your installed build is an intermediate update that never got a full ISO release, the builds will not match exactly.

Attempt the automatic repair with DISM

If the major and minor build numbers match exactly, DISM can repair the damaged files using the image on your installation media. First create a scratch folder with at least 1 GB free:

mkdir C:\scratchdir
dism /Image:F:\ /Cleanup-Image /RestoreHealth /Source:wim:D:\sources\install.wim:3 /scratchdir:C:\scratchdir

Replace the drive letters and the index number with your own values. If DISM reports that it cannot find the installation data, the build numbers of the image and your installation are not identical — this is the common failure case described above, and it means you need the manual method instead.

Manual fix: replace the input driver files directly

Drivers across the same major build are generally compatible even when DISM refuses to run. Mount the WIM from an ISO of the closest matching build (or copy from another Windows 11 machine on the same major build), then overwrite the suspect driver files in your broken installation. The files involved in keyboard, mouse, and USB input handling are kbdclass.sys, mouclass.sys, kbdhid.sys, mouhid.sys, USBXHCI.sys, and usbhub3.sys.

mkdir C:\extracted
dism /Mount-Wim /WimFile:D:\sources\install.wim /Index:3 /MountDir:C:\extracted /ReadOnly
copy C:\extracted\Windows\System32\drivers\kbdclass.sys F:\Windows\System32\drivers\ /y
copy C:\extracted\Windows\System32\drivers\mouclass.sys F:\Windows\System32\drivers\ /y
copy C:\extracted\Windows\System32\drivers\kbdhid.sys F:\Windows\System32\drivers\ /y
copy C:\extracted\Windows\System32\drivers\mouhid.sys F:\Windows\System32\drivers\ /y
copy C:\extracted\Windows\System32\drivers\USBXHCI.sys F:\Windows\System32\drivers\ /y
copy C:\extracted\Windows\System32\drivers\usbhub3.sys F:\Windows\System32\drivers\ /y

Adjust the letters and index to match your setup, unmount the image when done, remove the installation media, and reboot normally. If input comes back, run Windows Update to let the OS reconcile the restored files with your installed build.

Prevention and fallback options

• Keep a recent full image backup (for example with wbadmin or a third-party imager) so a corrupt driver set costs minutes, not days.
• If a Windows update preceded the failure, check C:\Windows\Logs and update history once input is restored, and pause updates briefly to confirm stability.
• If the manual copy does not restore input, the corruption may extend beyond these six files; an in-place upgrade (running setup.exe from matching installation media while keeping files and apps) is the next least destructive step before considering a clean install.

Frequently Asked Questions

Why does Safe Mode not work either?

Safe Mode loads a reduced set of drivers, but it still loads the same core input and USB class drivers from System32\drivers. If those files are corrupt, Safe Mode is affected too — unlike WinRE, which carries its own independent copies.

Could this be failing hardware instead?

Very unlikely given the pattern. Devices that work in BIOS, on other computers, and in the Windows installer are physically healthy. The fault lies in the software layer that only the installed OS uses.

Do I need the exact same build number for the replacement drivers?

For DISM's automatic repair, yes — the major and minor build numbers must match exactly, or DISM will refuse the source. For manually copying the six driver files, staying within the same major build is generally sufficient.

Will this fix erase my files or programs?

No. Both the DISM repair and the manual file copy modify only driver files inside Windows\System32\drivers. Your data, settings, and installed applications are untouched. Back up anyway before any system-level repair.

Where can I get an ISO of an older build?

Microsoft's download page only offers the latest release, so for an intermediate build you may need a media-creation tool from that era, an existing ISO you saved, or a healthy machine running the same major build to copy the drivers from.

What if the keyboard works but the mouse does not (or vice versa)?

That narrows the fault further: keyboard-only failure implicates kbdclass.sys and kbdhid.sys, while mouse-only failure points at mouclass.sys and mouhid.sys. The USB host and hub drivers matter for both, so replace them if the affected device is a USB peripheral.