Windows – Having Windows 8 use a real GPS (NMEA) for Location Services

Since people are going to find this using Google WWWW, here's a slightly generalized answer.

Serial ports can be connected to many different things. They don't just talk to modems. They could also talk to mice, for example, or graphics tablets. There's a whole specification, the Plug and Play External COM Device Specification, dealing with how Plug&Play enumeration works over serial ports. Unfortunately, your GPS receiver isn't a proper Plug&Play serial device and the continuous data stream that it sends to the host confuses the serial port Plug&Play enumeration protocol.

Your USB adapter cable itself could be doing the Plug&Play autodetection.

USB devices have types, so called device classes, that they report to the host. An adapted device might be, in the USB world view, a serial port device type (a Communications Device Class device class) or a mouse device type (a Human Interface Device device class). Several USB↔RS-232 adapter cables are known to decide what USB device class they report themselves as to the host based upon what they detect connected to their RS-232 interface. They will attempt to communicate with the device, auto-detect what kind of serial device it is, and change their own device class accordingly. If a GPS receiver looks like a mouse to them, they'll report themselves as a USB HID device.

In which case, your correct first course of action is to replace the adapter cable with one that doesn't do this autodetection. You can see whether this is what is happening by looking at the USB device in the Windows Device Manager, and seeing whether it is a USB HID or a USB CDC device.

From what I can see from the vendor's manual, the Sabrent USB↔RS-232 adapters aren't this intelligent; although it is unclear what the difference between the "K" and "M" flavours is, and this might be a factor. In which case, however, you are not out of the woods, because there's a second round of autodetection:

Windows could be doing the Plug&Play autodetection.

Windows, when it discovers that it has a serial port, attempts to find out what's connected to the port; handshaking with the device and determining its type. It then invokes the appropriate device driver.

There are two ironies here. First: This means that a "smart" USB↔RS-232 adapter, that has already itself done the handshaking and determined that it is a CDC device and not a HID device, can go through a second round of handshaking, as Windows itself attempts to determine what this serial port is connected to. Second: Even in machines that don't have their RS-232 motherboard logic in their Super I/O chip wired up to an I/O connector, the Windows serial port device driver is gamely trying to check what's physically connected to the port.

There are several ways to address this:

• Disable the sermouse driver entirely. This is a simple matter of changing its start class, wither by tweaking the registry directly or using the Windows service manager, from Automatic to Manual. The sermouse driver is invoked when the serenum bus driver detects a mouse connected to a serial port. If the sermouse driver is set to Manual, it won't start up automatically, and it won't create a "mouse" device object for the new "mouse" that has been (erroneously) autodetected. The autodetection, done by serenum will still occur; and Device Manager may report that the inability to drive the device since the driver does not start. Also, the port will of course not be fully recognized and listed as a communications device. The system, after all, thinks that it's a mouse.

• Do what Microsoft has been saying to do since the days of Windows NT 5. Microsoft KnowledgeBase article 283063 describes exactly this situation, and points out that Microsoft updated its serenum driver ten years ago, all of the way back in 2001, to include a bypass facility. One needs to locate, in the registry, the device parameters information for that particular instance of the serial device, and add a SkipEnumerations value to it, to stop serenum from trying to enumerate it. Full details, including where to look in the registry for serial devices on systems with different HALs, are in the KnowledgeBase article.

  Yes, these things are in the registry, and are not "virtual". if you are looking for "virtual COM ports" you are looking for the wrong things. Read the article and follow the instructions.

• Use the tool that Microsoft has been providing to fix this since the days of Windows NT 5.2. This tool is the slightly misleadingly named COMDisable, and instructions for obtaining and using it are in Microsoft KnowledgeBase article 819036. It essentially does the same registry modification as above, to change the behaviour of the serenum device driver, without one having to laboriously locate where the device parameters are in the registry.

It does it automatically, based on best-signal

When is GPS data provided to the Location API?

As in Windows 7, the Location API is built on the Sensors API, and the information in location reports comes from location sensors. The Location API determines the most accurate location sensor for a given report type. This simplifies programming because the Location API will only provide one report of a particular type, even when there are multiple location sensors available. When the Windows Location Provider and GPS both exist on the system and are providing data, the Location API will use the sensor with the most accurate data. In most cases when both WiFi and GPS are available, the GPS will be more accurate and its data will be passed to the application.

source