Device misdetected as serial mouse

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:

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

Change Value to 4 and it will stop this problem occurring.

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 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.

It turns out that mouse detection in Windows is normally handled by the serenum.sys filter 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.

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

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.

Alternatively with the serial control signals actually hooked up, or intercepted by a USB CDC device, processing the DTR or RTS signals 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.

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.