In an effort to minimize the chance of drivers getting installed onto people's machines that do nefarious things, Windows added the concept of driver signing. If a driver wasn't signed, you'd get a notification that you were about to install something that wasn't trusted. However at that time, you still had the ability to agree and install it anyway. People installing the old FTDI driver for Moates QH might have encountered this.
This has been a gradual thing Microsoft's been pushing, and each time, developers of drivers have had to keep up. It affects this wireless Innovate effort via the open source com0com driver. This affected the com0com project being it generates COM ports via a Windows driver that produces COM ports...the only way they can be generated that I'm aware of. The com0com developer(s?) looked into this and for com0com v3, they figured out that there's an open source Signed Drivers project that would allow people to get driver's signed such that they would be trusted by Windows. And that worked for a while.
My guess is this Signed Drivers open source effort allowed people to circumvent the whole point of signing drivers in the 1st place. So Windows, as of Win10 v1607, only allows drivers that were built via the Microsoft Dev Portal to be installed and operate...with some caveats:
Microsoft Driver Signing Policy
They didn't want to break old software or completely cripple Windows from being able to boot if newer "signed" drivers were installed, so there are some exceptions:
When I updated to v3, I did disable Secure Boot in my bios, but this didn't seem to help. Windows still disabled the driver at runtime.Signing Policy wrote:Exceptions
Cross-signed drivers are still permitted if any of the following are true:
To prevent systems from failing to boot properly, boot drivers will not be blocked, but they will be removed by the Program Compatibility Assistant.
- The PC was upgraded from an earlier release of Windows to Windows 10, version 1607.
- Secure Boot is off in the BIOS.
- Drivers was signed with an end-entity certificate issued prior to July 29th 2015 that chains to a supported cross-signed CA.
Since com0com v2.2 falls into the pre- 07/29/2015 category, it still works. But I haven't been able to get v3 to work at all since this Windows update was pushed. Thus I've had to revert back to running v2.2 to keep my tuning solution completely wireless.
Supposedly you can still get drivers signed today using Microsoft's Hardware Lab Kit and submitting your driver for signing. The policy I linked to doesn't indicate anything further about that as to whether you have to pay money, submit source, or anything like that. If it is an automated mechanism, then Microsoft is just running some kind of code analysis over the submitted driver (something similar to a virus scanner). Then automating the build of signing the driver. It seems this must be done for every version of Windows which just sounds like such a major PITA especially if every sub-version has to be handled, not just major Windows versions (i.e. Win7, 8, 8.1, 10, etc).
And of course, there are ways to disable this for development and testing, but even this isn't convenient, and I guess it shouldn't be so people/companies don't try to release software and as part of the install, automate Windows to run in "developer mode."
What I don't know is if com0com is still actively maintained and has enough user base for the developer to get this working with latest versions like it did prior to this driver policy change. Looking at sourceforge's indication of download history, there are people downloading it each week. But the numbers are in the 1-5 downloads/per week range. I'm honestly surprised it's that many given COM ports are just not commonly developed for given how ubiquitous USB is today.