windows 设备误检测为串行鼠标

Device misdetected as serial mouse

提问by doynax

I'm working on a device which communicates with a PC through a (virtual) serial port. The problem is that the data we are sending occasionally gets incorrectly identified by Windows as a bus mouse, after which the "Microsoft Serial Ballpoint" driver is loaded and the mouse pointer starts jumping around on the screen and randomly clicking on things.

我正在研究通过（虚拟）串行端口与 PC 通信的设备。问题是我们发送的数据偶尔会被 Windows 错误地识别为总线鼠标，然后加载“Microsoft Serial Ballpoint”驱动程序并且鼠标指针开始在屏幕上跳来跳去并随机点击事物。

A bit of Googling reveals that is an old and well-known problem with serial devices where the usual work-around is a bit of registry hacking to disable the offending driver. That it is a lot to demand from our users however and I'd rather not have our application messing around with the user's registry. Especially not when the fix is dependent on the Windows version and the user may well be using a bus mouse.

一点谷歌搜索表明这是串行设备的一个古老而众所周知的问题，通常的解决方法是一些注册表黑客以禁用有问题的驱动程序。然而，这对我们的用户有很多要求，我不想让我们的应用程序弄乱用户的注册表。尤其是当修复依赖于 Windows 版本并且用户很可能使用总线鼠标时。

Instead I'd like to avoid the problem by changing our protocol to not send any data which may get us misidentified as a mouse. The only problem is that I'm not quite certain what patterns to avoid. Apparently Microsoft's Mouse protocol consists of packets of four bytes where the MSB of the first is set and that of the last three is clear.

相反，我想通过更改我们的协议来避免这个问题，以不发送任何可能让我们误认为鼠标的数据。唯一的问题是我不太确定要避免什么模式。显然微软的鼠标协议由四个字节的数据包组成，其中第一个的 MSB 被设置，最后三个的 MSB 被清除。

Would sending only 7-bit ASCII suffice? Are there any other devices I need to worry about being detected as?

仅发送 7 位 ASCII 就足够了吗？是否还有其他设备需要我担心被检测到？

回答by Serdalis

I just encountered this problem myself on Windows 7 Professional x64, and a solution that worked for me was to go into the registry and edit the following value:

我自己刚刚在 上遇到了这个问题Windows 7 Professional x64，对我有用的解决方案是进入注册表并编辑以下值：

Location: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\sermouse  
Key: Start  
Value: 3

Change Valueto 4and it will stop this problem occurring.

更改Value为4，它将停止发生此问题。

Here is a list of all valid Start values:

以下是所有有效起始值的列表：

0 Boot (loaded by kernel loader). Components of the driver stack for the boot (startup) volume must be loaded by the kernel loader.

1 System (loaded by I/O subsystem). Specifies that the driver is loaded at kernel initialization.

2 Automatic (loaded by Service Control Manager). Specifies that the service is loaded or started automatically.

3 Manual. Specifies that the service does not start until the user starts it manually, such as by using Device Manager.

4 Disabled. Specifies that the service should not be started.

---

---

A reg edit command would be as follows:

reg 编辑命令如下：

REG ADD "HKLM\SYSTEM\CurrentControlSet\Services\sermouse" /V Start /T REG_DWORD /F /D 4

You then need to restart the computer, which should now start correctly and not attempt to discover a serial mouse.

然后您需要重新启动计算机，它现在应该可以正确启动并且不会尝试发现串行鼠标。

good luck.

祝你好运。

回答by doynax

It turns out that mouse detection in Windows is normally handled by the serenum.sysfilter driver. This driver implements support for legacy serial mice along with serial plug-and-play. Microsoft has even provided the sourcecode as a WDK sample.

事实证明，Windows 中的鼠标检测通常由serenum.sys过滤器驱动程序处理。该驱动程序实现了对传统串行鼠标以及串行即插即用的支持。Microsoft 甚至提供了源代码作为 WDK 示例。

During detection the ports switches to 1200-7-N-1 mode while asserting DTR+RTSto which a response is expected within 200 ms, with a couple of retries in case of failure. Unfortunately for a legacy mouse a single Mor Bcharacter suffices as identification.

在检测期间，端口切换到 1200-7-N-1 模式，同时断言DTR+ RTS，预计在 200 毫秒内响应，在失败的情况下重试几次。不幸的是，对于传统鼠标，单个M或B字符就足以识别。

In our case the protocol was reworked to avoid these characters and now appears not to be misidentified anymore.

在我们的例子中，协议被重新设计以避免这些字符，现在似乎不再被错误识别。

However we were using a virtual USB serial port and for a traditional serial port this approach may be somewhat difficult as anything sent at a different baud rate is liable to look like line noise. In this case I suppose the easiest workaround is probably, as has already been suggested, to avoid making any unsolicited transmissions.

然而，我们使用的是虚拟 USB 串行端口，对于传统的串行端口，这种方法可能有些困难，因为以不同波特率发送的任何内容都可能看起来像线路噪声。在这种情况下，我认为最简单的解决方法可能是，正如已经建议的那样，避免进行任何未经请求的传输。

Alternatively with the serial control signals actually hooked up, or intercepted by a USB CDC device, processing the DTRor RTSsignals and holding off on output. Actually implementing the plug-and-play protocol would be an even niftier option. Supposedly there are cheap RS232 cables around without a full complement of control signals though so this approach might still fail.

或者，串行控制信号实际连接或被 USB CDC 设备拦截，处理DTR或RTS信号并延迟输出。实际上实现即插即用协议将是一个更漂亮的选择。据说周围有便宜的 RS232 电缆，但没有完整的控制信号，因此这种方法可能仍然失败。

回答by Reed Hedges

I also encountered this problem, fixed it by disabling "serial enumerator" in the advanced properties of the FTDI driver (properties of COM ports in Device Manager). This is described in http://www.ftdichip.com/Support/Documents/AppNotes/AN_107_AdvancedDriverOptions_AN_000073.pdf.

我也遇到了这个问题，通过在 FTDI 驱动程序的高级属性（设备管理器中的 COM 端口属性）中禁用“串行枚举器”来修复它。这在http://www.ftdichip.com/Support/Documents/AppNotes/AN_107_AdvancedDriverOptions_AN_000073.pdf 中有描述。

回答by Lundin

I have encountered this Windows bug myself. Here is my own research on the topic:

我自己也遇到过这个 Windows 错误。这是我自己对这个主题的研究：

Microsoft acknowledges this bug: http://support.microsoft.com/kb/819036Start with downloading their tool and see if it solves the issue.

Microsoft 承认此错误：http: //support.microsoft.com/kb/819036首先下载他们的工具，看看它是否能解决问题。

• Download & install their program.
• Run it from the command prompt from C:\program\Microsoft comdisable\
• Write comdisable /listwhen executing the program.
• All ports on the computer will be shown.
• Write comdisable /disable COMxwhere x is the port number.
• Do this for all ports on the computer.
• Reboot.

• 下载并安装他们的程序。
• 从 C:\program\Microsoft comdisable\ 的命令提示符运行它
• comdisable /list执行程序时写入。
• 将显示计算机上的所有端口。
• 写出comdisable /disable COMx其中 x 是端口号。
• 对计算机上的所有端口执行此操作。
• 重启。

This should hopefully work as an universal solution.

这应该有望成为一个通用的解决方案。

Alternatively, you can hack in boot.ini but I don't believe this works in Vista/Win 7. I have some app note from Cisco systems describing how to do this. If the above doesn't solve your problem, please let me know.

或者，您可以在 boot.ini 中进行 hack，但我不相信这在 Vista/Win 7 中有效。我有一些来自 Cisco 系统的应用说明，描述了如何执行此操作。如果以上方法不能解决您的问题，请告诉我。

回答by Werner

Maybe this helps: We had the same problem with FTDI FT232RL.We found out, that it was a hardware issue of our PCB.

也许这会有所帮助：我们在 FTDI FT232RL 上遇到了同样的问题。我们发现，这是我们 PCB 的硬件问题。

FTDI-Datasheet says about #RESET-Pin: Active low reset pin. This can be used by an external device to reset the FT232R. If not required can be left unconnected, or pulled up to VCC.

FTDI 数据表说明了#RESET-Pin：低电平有效复位引脚。外部设备可以使用它来重置 FT232R。如果不需要，可以悬空，或上拉至 VCC。

RESET-Pin was not required in our application, so we connected it to Vcc via 1k Pull-Up. It seemed that the pull-up of #RESET-Pin caused an undefined start-up of the FT232RL, at least every second converter, we connected to a USB-socket caused a serial-ball-point in the devive manager. We removed the pull-up-resistor at #RESET-Pin, therewith the #RESET-Pin is unconnected. Since then every interface worked proberly and didn't any longer create serial-ball-points in the Windows device manager.

我们的应用中不需要 RESET-Pin，因此我们通过 1k 上拉将其连接到 Vcc。似乎#RESET-Pin 的上拉导致了 FT232RL 的未定义启动，至少每隔一秒转换器，我们连接到 USB 插座就会导致设备管理器中的串行球点。我们在#RESET-Pin 处移除了上拉电阻，因此#RESET-Pin 未连接。从那时起，每个接口都可以正常工作，并且不再在 Windows 设备管理器中创建串行圆珠点。

回答by Jubatian

If you have a "true" serial port, or an USB dongle (RS-232, RS-485, it does not matter) this problem can be worked around by first opening the serial port in question with a terminal, or whatever application you want to monitor it with, and only then plugging the device in. For your own sake, you should also pay attention to remove the device before terminating the connection.

如果你有一个“真正的”串口，或者一个 USB 加密狗（RS-232、RS-485，没关系）这个问题可以通过首先用终端打开有问题的串口来解决，或者你使用的任何应用程序想要监控它，然后才插入设备。为了你自己，你也应该注意在终止连接之前移除设备。

With FTDI chips soldered on the device itself, you are busted. It took a few rounds for me to explain the management that a device communicating on it's own paired with an FTDI chip soldered on the PCB meeting Windows computers won't likely pass for user-friendliness, no matter how slick an USB socket may look like on the cabinet... (Thankfully, all these conditions coming together are quite rare and unusual)

将 FTDI 芯片焊接在设备本身上，你就失败了。我花了几轮来解释管理，一个独立通信的设备与焊接在 PCB 上的 FTDI 芯片配对 Windows 计算机不太可能通过用户友好性，无论 USB 插座看起来多么光滑在柜子上......（谢天谢地，所有这些情况都非常罕见且不寻常）

回答by Ben Burger

I had this problem since 2010 with serial scale heads connected to the pc. Usb to serial converter or not.. I use onkly SILABS device's CP2102 or the like.. I worked around it by simply allowing the driver to install and then in device manager look for the ballpoint driver under mouse/HIDA and then simply DISABLE the driver, DO NOT UNINSTALL IT simply disable it. Then when you reboot even with the driver instaled it seems windows ignores the comport as serial mouse and uses the data from the input. You will also find that if the ballpoint driver is active then that COMport is in use and sometimes returns a COM PORT not accessible... hope this helps some one out there :) Tx Ben

自 2010 年以来，我遇到了这个问题，串行秤头连接到电脑。USB到串行转换器与否..我使用onkly SILABS设备的CP2102或类似设备..我通过简单地允许安装驱动程序然后在设备管理器中查找鼠标/HIDA下的圆珠笔驱动程序然后简单地禁用驱动程序来解决它, 不要卸载它只是禁用它。然后，即使在安装了驱动程序的情况下重新启动时，Windows 似乎也会忽略作为串行鼠标的通信并使用来自输入的数据。您还会发现，如果圆珠笔驱动程序处于活动状态，则该 COMport 正在使用中，有时会返回一个无法访问的 COM PORT...希望这对那里的人有所帮助:) Tx Ben

回答by David Refoua

In my development environment, I've simply disabled Microsoft Serial Mousefrom the Device Manager.

在我的开发环境中，我只是从设备管理器中禁用了Microsoft 串行鼠标。

This seems to solve the culprit of my problem. Before doing so, the CH340Gchip I've used in my design used to lower the DTRfive times before initiating the connection, effectively rebooting my Arduino-based board and render it useless.

这似乎解决了我的问题的罪魁祸首。在这样做之前，CH340G我在我的设计中使用的芯片DTR在启动连接之前会降低五次，有效地重新启动我的基于 Arduino 的板并使其无用。