Windows 10 和 Windows 11 中的后台 Raw Input 监听器
本页内容
简短回答： 将后台监听器限制在约 125 Hz 已由我们在 Windows 11 24H2 上的物理测量确认。在系统 throttling 启用时，后台
WM_INPUT的平均间隔为 7,97 ms，即约 125,5 Hz；foreground 保持了 1,04 ms。关闭该机制后，background 恢复到 1,00 ms。在部分虚拟测试系列中，throttling 并未导致 raw packets 丢失：32 个中的 32 个以及 256 个中的 256 个事件均得以保留。
状态： 后台监听器的 throttling 与 coalescing 机制已由 Microsoft 记录在案。约 125 Hz 的频率由独立的公开测试工具使用物理 1000 Hz 鼠标在 Windows 11 24H2 上测得。该系统性分支同样在 Windows 11 25H2 中被观察到，而在配对的 Windows 10 22H2 中未被发现。
为什么 Microsoft 添加了该限制
Section titled “ 为什么 Microsoft 添加了该限制”Microsoft 直接描述了原因：high report rate 鼠标不仅向游戏发送输入，还向多个后台进程发送输入。处理这些请求占用了本可用于渲染的显著处理器时间，并且在配备 1000 Hz 鼠标的测试用 Surface Laptop Studio 上观察到了明显的卡顿。解决方案正是针对后台 Raw Input listeners 的 throttling、coalescing 和消息频率限制。
到该变更发布时，高速鼠标早已远超 1000 Hz。例如，Razer 于 2021 年发布了 8000 Hz 有线鼠标，并于 2022 年推出了 4000 Hz 无线技术。8000 Hz 设备每秒发送的报告数量可达 1000 Hz 设备的八倍。因此，4000–8000 Hz 鼠标的普及合理地放大了多个后台 listeners 问题的规模。
最后一句是我们对背景的解读，而非 Microsoft 的声明。Microsoft 并未称该更新是针对 4000 或 8000 Hz 鼠标的紧急反应，而在已发布的测试中使用的也是 1000 Hz 鼠标。此外，更准确的说法是 input requests 的投递与处理的总成本，而不应将全部效应仅归因于硬件中断。
相关的 BoosterX 设置
Section titled “相关的 BoosterX 设置”该材料与“降低后台 Raw Input 事件频率”设置相关。它限制的正是后台 listeners，不应被描述为对 foreground 输入的限制，也不应被描述为有保证的 FPS 提升。
可验证的论断
Section titled “ 可验证的论断”我们验证了五项论断：
- 在 Windows 11 中存在对高频后台 Raw Input listeners 的单独处理。
- 在所研究的 Windows 10 22H2 中不存在相同形式的处理。
- 在 Windows 11 24H2 中，当输入流约为 1000 Hz 时，后台监听器的有效频率确实约为 125 Hz。
- Throttling 可能因丢包、合并或拆分数据包而降低游戏
WM_INPUT流的完整性。 - 仅改变窗口模式本身就会产生不同的 Raw Input path。
- Windows 10 22H2 build 19045.6456；
- 配备物理 1000 Hz 鼠标的 Windows 11 24H2；
- Windows 11 25H2；
- 隔离的虚拟机；
- foreground 与 background consumers；
- 常规 Raw Input 注册、
RIDEV_NOLEGACY和RIDEV_INPUTSINK； - windowed、borderless 以及已确认的 exclusive presentation；
- 每组 32 个事件的对照系列以及单独的 256 个事件系列。
物理系列检查了 WM_INPUT 之间的间隔，但未包含真实对局、anti-cheat 或 overlay。虚拟系列未复现 USB polling、物理 GPU、显示器或 click-to-photon 链路。
在一项独立的公开实验中，RawMouseThrottleBufferTester 注册了一个 RIDEV_INPUTSINK 鼠标，并测量了 WM_INPUT 运动消息之间的 Stopwatch 间隔。同一个窗口在系统默认值下分别以 foreground 和 background 进行比较，然后在关闭 throttling 后再次比较。
所示平均值是根据最近 512 个已接收间隔的环形窗口计算的。零运动和 40 ms 以上的暂停被丢弃。截图中的 Samples 字段显示的是截至截图时已接收间隔的总数，而非统计窗口的大小。
此外，对 Windows 10 22H2 和 Windows 11 25H2 的系统组件进行了静态比较，以找出后台鼠标处理的单独分支，并将 Raw Input path 与 legacy cursor 及 presentation paths 区分开来。
随后，在相同的虚拟环境中，将受控的 mouse events 序列送入 foreground 或 background consumer。对于每个场景，记录了发送和接收的 raw packets 数量、丢失、合并、拆分、foreground state，以及单独的 legacy/cursor branch 事件。
每次只改变一个因素：consumer 的注册方式、foreground state、窗口模式或系统 throttling 配置文件。在场景之间，测试状态会恢复到记录的 baseline。
物理鼠标，Windows 11 24H2
Section titled “物理鼠标，Windows 11 24H2”| 状态 | 最近 512 个事件的平均间隔 | 等效频率 | 截图时的 Samples |
|---|---|---|---|
| Default, foreground | 1,04 ms | ≈962 Hz | 2 221 |
| Default, background | 7,97 ms | ≈125,5 Hz | 3 556 |
| Throttling 已关闭, foreground | 1,00 ms | ≈1000 Hz | 19 606 |
| Throttling 已关闭, background | 1,00 ms | ≈1000 Hz | 12 009 |
这证实了在所研究的 Windows 11 24H2 中，后台 RIDEV_INPUTSINK consumer 的频率约为 125 Hz。同一程序的 foreground 路径未被限制到 125 Hz。
受控虚拟场景
Section titled “受控虚拟场景”| 场景 | Windows 10 22H2 | Windows 11 25H2 | 结果 |
|---|---|---|---|
| Raw Input 基础投递 | 发送 32，接收 32 | 发送 32，接收 32 | 未发现丢失、merge 和 split |
无 RIDEV_INPUTSINK 的 Background |
32 中的 0 | 32 中的 0 | 未请求后台投递 |
带 RIDEV_INPUTSINK 的 Background |
32 中的 32 | 32 中的 32 | 后台投递在两个 OS 上均正常工作 |
| Windowed, borderless, exclusive | 每种模式下均为 32 中的 32 | 每种模式下均为 32 中的 32 | Presentation mode 未改变 packet integrity |
| Stress 配置文件 throttling | 不适用 | 所有状态下均为 256 中的 256 | legacy/cursor branch 发生了变化，但 WM_INPUT 的完整性未变 |
RIDEV_INPUTSINK 是已记录的后台投递开关。没有它，background consumer 不应收到与 foreground 应用相同的流。该行中的零结果并非 Windows 的数据丢失。
在 stress 系列中，系统 throttling 状态显著改变了 legacy events 的数量和系统光标的移动。与此同时，在所有状态下，Raw Input consumer 都收到了相同的 256 个数据包中的 256 个。因此，所发现的效应不能被准确地描述为“Windows 11 丢失 Raw Input”。
已确认的内容
Section titled “ 已确认的内容”- Microsoft 在 Windows 11 中为后台 raw mouse listeners 添加了 throttling、coalescing 和消息频率限制。
- 在所研究的 Windows 11 24H2 上，物理 foreground consumer 接收消息的间隔约为 1 ms，而 background consumer 的间隔为 7,97 ms，即约 125,5 Hz。
- 关闭 throttling 后，background consumer 的间隔恢复到 1,00 ms。
- 在所研究的 Windows 11 25H2 中观察到该处理的单独分支；在精确配对的 Windows 10 22H2 中未发现该分支。
RIDEV_INPUTSINK在两个所研究的 OS 上都会改变WM_INPUT的后台投递。- 在所有列出的场景中，raw packets 的完整性均以 1:1 保持。
- Throttling 的变化体现在所测量的 legacy/cursor branch 中，而非表现为 raw packets 的丢失。
未确认的内容
Section titled “ 未确认的内容”- 每个 Windows 11 版本上的每个 background listener 总是被精确限制到 125,0 Hz。已确认的结果仅适用于所描述的 Windows 11 24H2 及注册方式。
- 该机制在任何计算机上总是降低 FPS、latency 或 stutter。
- 关闭系统 throttling 能改善鼠标操控。
- DWM 在所有游戏和 Windows 11 版本中管理
WM_INPUT的完整性。 - 相同的 packet integrity 保证相同的物理 click-to-photon latency 或主观瞄准手感。
- 虚拟机的结果可推广到每一款物理鼠标、游戏、anti-cheat 或 overlay。
公开的物理截图不包含 Windows 11 24H2 的确切 build 号、鼠标型号、所有间隔的 CSV 或自动化的状态切换顺序。平均值反映的是最近 512 个事件，且鼠标移动是手动完成的。因此，该结果可靠地确认了观察到的约 8 ms 的集群，但并未为任何系统设定精确的常数。
虚拟机允许复现软件路径，但无法复现 USB polling、鼠标微控制器、物理 GPU、显示器以及完整的游戏循环。32 和 256 个事件的系列足以检查特定路径的可观察完整性，但不足以评估低概率的罕见丢失。
Windows 11 25H2 是与一个精确的 Windows 10 22H2 版本进行比较的。该结果不应自动推广到早期的 Windows 11、Windows Server 或未来的更新。
如何复现观察的动态部分——参见如何自行验证。
BoosterX 开发 GameModeX 和 ProcessX，而这项研究及其工具（包括公开的 RawMouseThrottleBufferTester）均属于 BoosterX 开发者，因此其与结果存在直接利益关系。方法和适用范围已在上文描述，结论可通过公开数据核实：该工具的公开代码、测量截图以及所列来源。关于 WM_INPUT 丢失的零结果、约 125 Hz 的确认以及不存在通用保证均一并发布。
在 Windows 11 上，请将后台 raw mouse listeners 的系统 throttling 保持在默认状态。Microsoft 引入它是为了在使用 high report rate 鼠标时减少后台应用的工作量，同时保持 foreground 游戏的精确输入。
对于游戏 PC，BoosterX 建议将兼容的 background listeners 限制在约 50 Hz。BoosterX 自身对该间隔的测量尚未发布；该数字本身与公开的独立测量一致：根据 PC-Tuning 和 Noverse 的检查，约 20 ms 的间隔对应兼容 listener 约 50–60 Hz 的频率。这些材料作为额外对照列在来源中，而本文中测得的值是约 125 Hz 的系统限制，而非手动设置后的频率。增大间隔会减少鼠标移动时投递的后台事件数量和处理程序启动次数。在已验证的路径中，foreground 窗口保持全速输入。
本地优化的方向已得到确认：降低后台事件的投递频率既减少了此类投递的次数，也减少了处理程序启动的次数。对于任意一组程序，未测量总 CPU load、FPS 或 frametime 变化的最终幅度。应用对鼠标的后台响应可能变得不那么流畅，因此对于确实需要在 background 中保持高频率的 listener，有理由恢复 Windows default。实际说明和确切的注册表状态见“降低后台 Raw Input 事件频率”页面。
如果某个特定的后台应用导致卡顿或输入冲突，请先更新或关闭它。不要在没有可复现对比的情况下关闭系统优化或暂停进程。
GameModeX 中限制后台 listeners 的 legacy 功能主要面向 Windows 10，并非 Windows 11 系统机制的替代品。对于新配置，建议使用受 Windows 11 和 ProcessX 支持的方案。
研究在隔离的虚拟环境中进行。可变的测试状态在场景之间恢复到记录的 baseline；完成后使用虚拟机的初始状态。在用户计算机上，本文不建议更改系统参数，因此无需单独的恢复操作。
公开的一手来源
Section titled “ 公开的一手来源”- RawMouseThrottleBufferTester — 公开程序、源代码、静态观察、WinDbg 检查以及四张 Windows 11 24H2 物理测量截图。
- Default, foreground 和 default, background — 1,04 ms 对 7,97 ms。
- Throttling off, foreground 和 throttling off, background — 均为 1,00 ms。
- Microsoft: Reduced game stutter with high report rate mice — 针对 background raw mouse listeners 的 throttling、coalescing 和 cap。
- Microsoft: KB5027303, OS build 22621.1928 — 首个包含 high report rate 鼠标改进的稳定 preview 更新。
- Microsoft: Windows 11 Insider Preview Build 23424 — 游戏期间 high report rate mouse 改进的早期公开描述。
- Razer: 发布 Viper 8KHz — 2021 年 1 月 28 日 8000 Hz 鼠标的官方发布以及报告量与 1000 Hz 的对比。
- Razer: 4000 和 8000 Hz 的发展 — 有线与无线 high polling rate 设备的官方时间线。
- PC-Tuning: background listener 间隔检查 — 公开的间隔观察方法及
RawMouseThrottleDuration范围。 - Noverse: 对两个 background listeners 的独立检查 — 在间隔为 20 ms 时，兼容 listener 测得约 60 Hz，而采用 bypass 注册的 listener 保持了约 1000 Hz。
- Microsoft: RAWINPUTDEVICE —
RIDEV_INPUTSINK和RIDEV_NOLEGACY的用途。 - Microsoft: About Raw Input —
WM_INPUT的注册与投递模型。
公开来源和表述已核实：2026-08-24。
- 2026-09-20: 约 50 Hz 的建议已重新表述：该数字明确与公开的独立测量进行对照，并指出缺少自身已发布的间隔测量；利益冲突免责声明补充了研究与工具的归属，并在方法中增加了自行验证的链接。
- 2026-08-25: 建议在游戏场景中使用 50 Hz，作为对后台处理减少的确认；对总 CPU 和 FPS 数值影响的边界单独保留。
- 2026-08-24: 添加了已记录的 CPU load 背景、关于 4000–8000 Hz 鼠标结论的边界，以及将 background listeners 手动限制在约 50 Hz 的谨慎场景。
- 2026-08-24: 添加了 Windows 11 24H2 的公开物理测量，确认 background listener 约为 125 Hz；保留了这不是每个版本和注册方式的通用常数的边界。
- 2026-08-24: 发布了 Windows 10 22H2 与 Windows 11 25H2 的首次比较。