Arduino detected as Microsoft Serial Mouse

Development Boards Arduino
1

We have our students using the Sparkfun Inventor’s Kit as part of one of our classes, and have started seeing a lot of instances of the board being detected by Windows 7 as a “Microsoft Serial Mouse” if the sketch installed was writing to serial immediately after the board powered up. This causes users to lose control of their mouse, since the serial mouse driver is trying to interpret the incoming strings as pointer positions and clicks. This seems to be a fairly widespread problem for Windows Arduino users, as well as anyone using USB->Serial adapters which immediately output serial data, like GPS units, so I figured someone else might appreciate knowing how to fix it. We found two methods:

If you are an Administrator on your machine, you can open the Device Manager (devmgmt.msc in the quick-run bar), right click on the “Microsoft Serial Mouse” entry under “Mice and other pointing devices”, then click “Disable”. Uninstalling doesn’t seem to work, but disable does. This relies on you having enough control over your mouse while the Arduino is plugged in to actually navigate and click on things, which isn’t always the case.

As an alternative, you can use group policy to disallow the drivers that the serial mouse uses. This is the route we took, since we’re on an Active Directory domain and needed to apply the fix to around 100 machines.

Open the group policy editor (gpedit.msc in the quick launch bar), then navigate to:

“Computer Configuration\Administrative Templates\System\Device Installation\Device Installation Restrictions”

Open “Prevent installation of devices that match any of these device IDs”, enable it, and add all of the following in the menu opened by the “Show” button.

ACPI\PNP0F01

ACPI\PNP0F08

ACPI\PNP0F09

ACPI\PNP0F0A

ACPI\PNP0F0C

ACPI\PNP0F1E

SERIAL_MOUSE

*pnp0f01

*pnp0f08

*pnp0f09

*pnp0f0a

*pnp0f0c

*pnp0f1e

This worked 100% of the time for us. Even if the Arduino was detected as a serial mouse, the driver wasn’t installed and so we retained control of our mouse. It doesn’t interfere with USB mice, since they use a different device ID, though it might interfere with PS/2 mice. So far we haven’t had any trouble with the Arduinos themselves after applying the fix.

2

We use arduino with all kinds of FTDI USB to Serial products all the time…never come across any conflicts like these! but I am curious about this since we use these combinations so widely.

3

It only seems to happen if you have the Arduino firing out serial data the instant it gets past the bootloader, and if you continue to send data as fast as it can be sent. If there’s even a slight delay it isn’t detected as a mouse nearly as often. Some students saw the problem more often than others… seemed to depend on the board and the PC itself as well.

Once we put this fix in place the problem completely disappeared. I personally had never seen this happen before either in several years of playing with Arduino/FTDI; came as quite a shock when half a class suddenly couldn’t use their mouse.

4

A decades old bug in Windows has been that at bootup, windows tends to mis-identify serial ports that have data flowing at that time as a serial mouse or joystick. There are registry changes to preclude that. I recall doing it years ago with XP. Not sure about Win 7.

Microsoft published fixes/workarounds to be user applied but for some reason never actually fixed it in the OS.

5

stevech:
A decades old bug in Windows has been that at bootup, windows tends to mis-identify serial ports that have data flowing at that time as a serial mouse or joystick. There are registry changes to preclude that. I recall doing it years ago with XP. Not sure about Win 7.

Microsoft published fixes/workarounds to be user applied but for some reason never actually fixed it in the OS.

Thanks for that…if its not asking too much could you share a link or any info about this bug. I tried searching, but probably was not using the search phrase right.

6

http://www.taltech.com/support/entry/wi … g_com_port