# hidusbf: a USB filter driver that raises a mouse polling rate on Windows

> hidusbf is a Windows USB filter driver, HIDUSBF.SYS, that lets you raise the polling rate of a selected USB mouse above 125 Hz, with a batch-based setup program and a registry-switched patching scheme for modern Windows. The judgement is that the project is unusually well documented for a driver of this kind, and that its own warning about disabling Memory Integrity is the price of admission.

**LordOfMice/hidusbf** — USB Mice Overclocking Software (for Windows)

- Repository: https://github.com/LordOfMice/hidusbf
- Stars: 1,403 · Forks: 265
- Language: Batchfile
- License: not declared
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/lordofmice-hidusbf

## What the driver does, and the two warnings above it

hidusbf is a driver and program for overclocking USB mice under Windows, and the README opens with a scope statement and then two warnings that you should read before anything else.

The scope is broad in one direction and narrow in another. It is intended to overclock USB mice, or other devices, under Windows 98, 98SE, ME, 2000, XP, 2003, Vista, 7, 8, 8.1, 10 and 11, including x64 versions. It may also be used for downclocking, and the documentation is clear that downclocking shall work always, which is a useful reassurance given the failure modes described later.

The first warning is about scope of hardware. Overclocking may not work for Low Speed USB devices controlled by a non-Microsoft USB stack, such as OEM USB 3.x drivers on Windows 7 or with the newest Microsoft drivers. The second is the one that matters most for a modern machine: you shall disable Memory Integrity to load the patching versions of the HIDUSBF driver under recent versions of Windows 10 x64 or Windows 11.

That second warning is a genuine security trade, not a formality. Memory Integrity, the part of Windows that enforces code integrity on drivers, is turned off so the patched driver can load. The project says so explicitly and does not bury it.

The last scope statement in the introduction is the reassuring one. The program changes the rate on selected devices only, not touching other devices on USB. So the blast radius of a mistake is one mouse, not the whole bus.

## Installation: which driver variant you need depends on what you want

The installation instructions branch on a single question, which is whether you want downclocking or overclocking, and that choice determines which driver files you use.

Downclocking of all devices and drivers, or overclocking of Full Speed USB devices, is possible always and there is no need to patch system code. If that is your use, take the drivers from the `DRIVER\NTX86[_AS]\NOPATCH\` and `DRIVER\AMD64[_AS]\NOPATCH\` directories and replace the drivers from `DRIVER\NTX86[_AS]\` and `DRIVER\AMD64[_AS]\`.

For the case where you do need to overclock a Low Speed device, the system driver matters. For operating systems beginning from Windows XP, successful overclocking of Low Speed USB devices requires the presence of an original, not altered by other programs, version of the system driver USBPORT.SYS at `%sytemroot%\system32\drivers\usbport.sys`. Windows 8 and later also work with USBXHCI.SYS at `%sytemroot%\system32\drivers\usbxhci.sys`, and under Windows 7 the Intel xHCI driver IUSB3XHC.SYS is supported, with additions in HIDUSBFN.ZIP.

There are two exemptions. Because Windows 2000 has no restrictions on overclocking Low Speed USB devices in the driver code for OHCI and UHCI controllers, you can use the driver from `DRIVER\NTX86\NOPATCH\`. Windows 98 and ME also have no such restrictions, so there is no patch version of the driver for those operating systems at all.

There is one more special case. If you use your device with a pure EHCI controller, without companion UHCI or OHCI controllers and with an integrated USB 2.0 hub, or with any EHCI controller through a USB 2.0 hub on Windows 2000, then you just use the ordinary version of the driver, with patch. And there is a special unofficial version of USBPORT.SYS for Windows 98 and ME without any polling rate restrictions for such cases.

## Installing the service, then attaching the filter to one device

The actual install is a two-step process, and the separation matters because the two steps can fail independently.

First you install the driver service. The instruction is to execute SETUP.EXE, and there should also be .INF and .SYS files unzipped. You click Install Service. The documentation notes you may see a quick flash of the installation process, or you may not see anything, because the process is really fast. It does not matter, since the subsequent installation of the filter does verify that the service is actually installed, so you can move on to the next step.

That verification is the design point. Rather than making you read a log to know whether the service installed, the next step fails if it did not.

There is a fallback if SETUP.EXE did not install the service. You can use the operating system's standard route: right click HIDUSBF.INF or HIDUSBF_AS.INF and choose Install. By default, HIDUSBF.INF applies to all operating systems up to Windows 8 and HIDUSBF_AS.INF applies from Windows 8.1 onwards, and it is enough to install the service once for each operating system instance.

Then you attach the filter to a device. Choose the row with your device, put a checkmark in Filter On Device, and check that the Filter? column says Yes. After that, choose the desired refresh rate and push Restart. The documentation then tells you to check whether the refresh rate has really changed, for example with the program Mouse Rate Checker.

The troubleshooting path is specific, and it is the reason the project is worth reading. If your rate did not change, you should either reboot, plug out and plug in the mouse cable, or stop and then start your mouse in Device Manager. If the rate does not increase more than 125 Hz, try decreasing it to 31 Hz or 62 Hz. And if the rate does decrease, the driver functions properly, but either your mouse is not overclockable, or USBPORT.SYS and USBXHCI.SYS were altered or are simply too new and so unknown to the program.

## Uninstalling a filter that is still attached breaks the mouse

The uninstall section contains the most important warning in the README, and it is stated as a consequence rather than a precaution.

If you have deleted a driver but not unlinked it from the mouse, then the mouse will stop working. To make the mouse work again, you can delete the device corresponding to the mouse in Device Manager and then scan for new devices. Or use SETUP.EXE, go to All, or with Problem, or with HIDUSBF devices, confirm that Filter On Device is unchecked, and press Restart.

The order of operations is therefore fixed. First, unlink the driver from the mouse through SETUP.EXE with Filter set to Unchecked. Second, remove the service and the driver file, either through SETUP.EXE with Install Service and then UnInstall Service, or by right clicking HIDUSBFU.INF and choosing Install in Explorer.

That the driver files are named differently for install and uninstall is a small hint about how old this project is. HIDUSBF.INF and HIDUSBF_AS.INF install the service, and HIDUSBFU.INF is the one used to remove it, with the U standing for uninstall.

The mechanism behind the counter-intuitive failure is not hard to infer. A filter driver sits in the device stack, so removing the driver out from under an attached filter leaves the stack pointing at code that is no longer there, and the device stops enumerating. Unlinking first is not politeness, it is the only order in which the removal works.

## Registry switches decide how aggressively the driver patches

The 2025-11-05 history entry introduced the most interesting configuration in the project, and it is the mechanism to reach for if you want to control how far the patching goes.

The patching versions of drivers are now compatible with USBPORT.SYS on Windows 11 22H2 and later, for the old UHCI, OHCI and EHCI USB controllers. For the patching versions of drivers on modern operating systems, the AMD64_AS and NTx86_AS variants, it is now possible to disable the patching of different drivers separately by registry parameters, USBXHCI.SYS for xHCI USB controllers and USBPORT.SYS for UHCI, OHCI and EHCI USB controllers.

The registry keys are:

```text
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HIDUSBF\Parameters]
```

or:

```text
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\HIDUSBF]
```

And the values are `PatchUSBPort` as a dword and `PatchUSBXHCI` as a dword. `PatchUSBPort` has 0 and 1 values, where 0 disables patching and 1 enables it. `PatchUSBXHCI` has 0, 1, 2 and 3 values: 0 disables patching, 1 is 1k patching, 2 is 2k-4k patching, and 3 is 4k-8k patching.

The documentation then draws a distinction that matters for anyone reasoning about the risk. Strictly speaking, the 1k, 2k-4k and 4k-8k versions of the driver are different now by the `PatchUSBXHCI` default value only.

So the 1k, 2k-4k and 4k-8k versions of the driver differ only by the `PatchUSBXHCI` default value.

## A 2003 driver, still extended in 2026

The repository contents are small and the history is long, and both facts are worth knowing.

The top-level entries are `README.md`, `check_hidusbf_running.cmd`, `hidusbf.zip` and `hidusbfn.zip`. The two zip archives are the driver packages, and the batch file is a check for whether the driver is running. The `DRIVER` directory tree that the installation instructions refer to, along with `SETUP.EXE` and the `.INF` and `.SYS` files, lives inside those archives rather than as separate top-level directories.

The history in the README is where the age shows. The most recent entry is dated 2026/10/03, and it adds Yeo Kheng Meng's driver for xHCI controllers, from the `yeokm1/xhci98` project, tested and refined sufficiently to support ordinary, up to 1000 Hz, overclocking, with the Setup program's list of known drivers extended to include it.

The second most recent entry, 2025/11/05, is the registry scheme described above, and it thanks Battle Beaver Customs again for help. The credit to an outside company for testing and refining is unusual, and it points at who actually uses this.

The testing history in the introduction is a list of the operating systems the author has personally tested it under: Windows 98SE, 2000 SP2 and SP4, XP RTM through SP3, XP x64 SP2, 2003 x86 SP2, Vista 32 bit RTM and SP2, Vista 64 bit RTM, 7 x86 SP1, 7 x64 SP1, 8 x64, 8.1 x64, and 10 x64 at builds 1803, 1809, 1909, 20H2, 21H1, 21H2 and 22H2, plus 11 22H2. The first testing on an x64 platform was performed by Dark_Cloud under Windows XP x64 SP1.

The last push to the repository was on 2026-10-03, and the repository is not archived, so the work is current. There are no GitHub releases, so the version history lives entirely in the README's history section, and the newest version is linked from the repository itself.

## Conclusion

hidusbf fits a Windows user with a mouse whose polling rate is capped at 125 Hz by the USB stack, who wants a higher rate and is prepared to install a kernel filter driver and, on recent Windows, to weaken a security setting. It does not fit a machine where Memory Integrity, virtualisation-based security or driver signature enforcement must stay on, and it does not fit a user with a mouse whose controller is not recognised. Verify first that your system USB driver version is one the program recognises, that the driver you install matches the architecture and Windows version of the machine, since the project ships separate x86, x64 and AS variants, and that you can restore the polling rate afterwards, because the whole mechanism is a filter attached to a device and a broken uninstall leaves the mouse unusable.

## FAQ

### What is HIDUSBF.SYS and what does hidusbf do?

hidusbf is a Windows USB filter driver, HIDUSBF.SYS, for overclocking USB mice and other devices above the standard 125 Hz, and it can also downclock, which the documentation says shall work always. The program changes the rate on selected devices only, not touching other devices on USB.

### Do I have to disable Memory Integrity to use hidusbf?

For the patching versions of the driver on recent Windows 10 x64 or Windows 11, yes. The README states plainly that you shall disable Memory Integrity to load them, and that the patching versions are what you need to overclock Low Speed USB devices.

### How do I install the hidusbf driver on a Windows mouse?

Execute SETUP.EXE and click Install Service, then choose your device's row, tick Filter On Device, confirm the Filter? column says Yes, pick the refresh rate and press Restart. The documentation notes the installation may flash by too fast to see, and that the filter install step verifies the service was installed.

### What should I do if the mouse stops working after removing hidusbf?

Delete the mouse device in Device Manager and scan for new devices, or use SETUP.EXE to uncheck Filter On Device for the affected device and press Restart. The documentation is explicit that deleting the driver while it is still linked to the mouse is what breaks the mouse.

### How do I control how much the hidusbf driver patches?

Registry values under `HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HIDUSBF\Parameters` or `HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\HIDUSBF` let you set `PatchUSBPort` to 0 or 1, and `PatchUSBXHCI` to 0 for no patching, 1 for 1k patching, 2 for 2k-4k, and 3 for 4k-8k.

## Sources

- [Issues](https://github.com/LordOfMice/hidusbf/issues)
- [LordOfMice/hidusbf on GitHub](https://github.com/LordOfMice/hidusbf)
- [README](https://github.com/LordOfMice/hidusbf/blob/master/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/lordofmice-hidusbf