I wanted to document an edge case I encountered in February 2025 that ultimately took many months to fully diagnose. I hope this helps Kaspersky support or anyone experiencing similar symptoms.

Summary of the problem

It started on a physical Windows 7 Professional x64 workstation.

The workstation contains critical old software I still use.

After performing, using a physical genuine Windows 7 DVD, an in-place repair installation (installing Windows 7 over an existing Windows 7 installation), Windows booted successfully, but the keyboard and mouse no longer functioned. No mouse and no keyboard actions were possible. I could not get past the screen that required entering the product key.

I tried multiple physical (used and band new) USB keyboards and mice. They did not work.

After exhausting all options I could think of, I concluded the PC hardware – 17 years old – has become faulty. Because I could not restore normal operation on the physical machine, I eventually converted the installation to a Hyper-V VHDX in an attempt to continue troubleshooting. The same keyboard and mouse problem remained in the virtual machine.

Sequence of events

The sequence was approximately:

1. Existing Windows 7 Professional x64 installation with Kaspersky installed.
2. Windows began reporting filesystem problems during integrity checks (chkdsk reported errors that could not be permanently resolved, among other problems).
3. The system was also experiencing NVIDIA graphics driver issues.
4. To repair both the Windows installation and the driver problems, I performed an in-place repair installation.
5. After the repair, Windows booted, but the keyboard and mouse no longer functioned.
6. After numerous unsuccessful attempts to repair the physical installation, I created a VHDX using Disk2VHD and migrated the system into Hyper-V.
7. After resolving the some storage-controller boot issues in Hyper-V, the exact same problem was still present.
8. This eventually led to examining the keyboard class driver stack in the offline registry.

During investigation I loaded the offline SYSTEM hive and examined:

HKLM\SYSTEM\CurrentControlSet\Control\Class\

{4D36E96B-E325-11CE-BFC1-08002BE10318}

The UpperFilters value contained:

kbdclass

0klmouflt.k4w-21-19

The same filter was also present in the fallback ControlSet.

Probable root cause

Windows repair installation left the Kaspersky keyboard filter registered in the keyboard device stack while something about the filter installation itself was no longer valid. Windows continued attempting to load the filter during keyboard initialization, resulting in the loss of keyboard and mouse.

Solution

A. Keyboard recovery — offline registry repair

1. Load the Windows SYSTEM hive

Identify the Windows installation drive. In my case it was D:.

reg load HKLM\TEMP D:\Windows\System32\Config\SYSTEM

2. Check the keyboard class driver's UpperFilters

reg query "HKLM\TEMP\ControlSet001\Control\Class\{4D36E96B-E325-11CE-BFC1-08002BE10318}" /v UpperFilters

Value:

kbdclass

0klmouflt.k4w-21-19

The second entry was the Kaspersky keyboard filter.

3. Remove the existing UpperFilters value

reg delete "HKLM\TEMP\ControlSet001\Control\Class\{4D36E96B-E325-11CE-BFC1-08002BE10318}" /v UpperFilters /f

Check the fallback ControlSet and removed its UpperFilters value if it contained the Kaspersky filter:

reg delete "HKLM\TEMP\ControlSet002\Control\Class\{4D36E96B-E325-11CE-BFC1-08002BE10318}" /v UpperFilters /f

4. Recreate UpperFilters with only kbdclass

For ControlSet001:

reg add "HKLM\TEMP\ControlSet001\Control\Class\{4D36E96B-E325-11CE-BFC1-08002BE10318}" /v UpperFilters /t REG_MULTI_SZ /d kbdclass /f

For ControlSet002, if applicable:

reg add "HKLM\TEMP\ControlSet002\Control\Class\{4D36E96B-E325-11CE-BFC1-08002BE10318}" /v UpperFilters /t REG_MULTI_SZ /d kbdclass /f

5. Unload the SYSTEM hive

reg unload HKLM\TEMP

Reboot Windows.

Result: The keyboard began working normally.

---

B. Mouse recovery — offline registry repair

Similar approach.

reg load HKLM\TEMP D:\Windows\System32\Config\SYSTEM

reg query "HKLM\TEMP\ControlSet001\Control\Class\{4D36E96F-E325-11CE-BFC1-08002BE10318}" /v UpperFilters

Value:

mouclass

0klmouflt.k4w-21-19

reg delete "HKLM\TEMP\ControlSet001\Control\Class\{4D36E96F-E325-11CE-BFC1-08002BE10318}" /v UpperFilters /f

reg delete "HKLM\TEMP\ControlSet002\Control\Class\{4D36E96F-E325-11CE-BFC1-08002BE10318}" /v UpperFilters /f

For ControlSet001:

reg add "HKLM\TEMP\ControlSet001\Control\Class\{4D36E96F-E325-11CE-BFC1-08002BE10318}" /v UpperFilters /t REG_MULTI_SZ /d mouclass /f

For ControlSet002, if applicable:

reg add "HKLM\TEMP\ControlSet002\Control\Class\{4D36E96F-E325-11CE-BFC1-08002BE10318}" /v UpperFilters /t REG_MULTI_SZ /d mouclass /f

reg unload HKLM\TEMP

Rreboot Windows.

Result: The mouse function was restored.

C. Physical-machine recovery

I’d imagine the same approach would work on the physical machine. For now, I’m going to stick to the VM, and repurpose the PC for something else.

If anyone from Kaspersky has seen this behavior after an in-place Windows repair installation, I would be interested in knowing whether this is a known issue with the keyboard filter driver or whether there is an official recovery procedure.

 

@LQQ

Windows 7 is EOL , but Kaspersky Technical Support experts are available to help you.

14 часов назад, LQQ сказал:

I would be interested in knowing whether this is a known issue with the keyboard filter driver or whether there is an official recovery procedure.

This is a well known old rare issue. Please see this post.