At the time, the cable was already “discontinued” but it was cheaper than the U1173B which changed the colour to bright orange. Little did I know that the colour was not the only change – it now says Support [for] Windows 10.
Having run my main workstation on Windows 7 until my recent upgrade, I was unaware that the U1173A would come to cause trouble.
I plugged the U1173A cable into my new Windows 10 box, expecting it to just “work” as it used to. Alas, I was wrong.
Instead, it decided to throw up a Code 10 error. Normally that would appear for counterfeit Prolific chips, but this was an Agilent Technologies product, so I was sure it was fine. I downloaded the latest driver (v1.19.0) and installed it, to no avail. Thinking the cable may be suspect, I grabbed the U1173B which came with the U1461A kit, and that worked just fine.
After a closer look at Prolific’s site, I came across this EOL Notification which includes the following text:
Due to EOL (End-of-Life) policy, please note that PL-2303HX (Chip Rev A) and PL-2303X (Chip Rev A) will not have compulsory driver support for the coming Windows 8 operating system as it is not a supported OS mentioned in the chip datasheet. So it is advisable to switch to the new PL2303TA chip which will include support for Windows 8.
The notification was not that strongly worded, so I got the impression that while they won’t be assured driver support, they wouldn’t be doing anything deliberate to stop it from working on Windows 8 (and presumably, Windows 10).
However, this proved to be an incorrect interpretation, as reading the Release Notes in the latest driver package, it says:
– PL2303HXA/XA EOL chip versions (discontinued) will NOT be supported in Windows 8/8.1/Server2012/Server2012R2 and Windows 10 onwards.
– Download latest PL2303 CheckChipVersion tool program to check chip version in Windows 7. (Or contact your cable vendor)
– Prolific recommends cables with PL2303HXD or PL2303TA chip.
Please be warned that counterfeit/fake PL-2303HX Chip Rev A (or PL-2303HXA) USB to Serial Controller ICs using Prolific’s trademark logo, brandname, and device drivers, are being sold in the China market. Counterfeit IC products show exactly the same outside chip markings but generally are of poor quality and causes Windows driver compatibility issues (Yellow Mark Error Code 10 in Windows 7 Device Manager). We issue this warning to all our customers and consumers to avoid confusion and false purchase. Only purchase branded cables that provide technical support and warranty service. Prolific does not manufacture nor sell end-product cables.
Based on this information, the driver will not support PL2303HXA or PL2303XA chips under Windows 8 and above. Coincidentally, the warning placed later in the document identifies these chips as the target of counterfeiting. This is true, as I had been a victim of this in the past. However, the warning about the Error Code 10 is deliberately worded to shift the blame away from Prolific. Those who have had fake chips in their hands know that there is absolutely no problem when running them using much older drivers which do not check for it and do not cause BSODs. Thus, it’s likely that this is caused by their deliberate choice to code the driver to only work with their own devices. I think that locking out counterfeits is fair in some sense due to their R&D investment and the need to maintain their competitive advantage. However, causing problems for those with older genuine chips is inexcusable. Maybe they found some clones they couldn’t disable/detect, and thus rendering all chips of that type unusable in Windows 8 and above was their solution.
Unfortunately, as the chip check tool only works up to COM15, I had to reallocate the COM port number. Ultimately, it delivered me the bad news – this was one of the chips affected by the discontinuation.
I’m pretty late to the party when it comes to this issue, since it was already around when Windows 8 started going mainstream. As a result, I could count on others having met the same issue and finding some solutions.
A quick search online seems to show that an older version of the driver is necessary. Removing the driver and replacing the ser2pl.sys or ser2pl64.sys files from an older driver would do the trick, although, sometimes files would be replaced automatically by Windows. There were a few sites offering older drivers for download, although I’m not sure how reliable they are. As for how old the driver has to be, it seems that there are differing opinions – some say any 3.3.x.x series driver should work, however it is known that 18.104.22.168 and 22.214.171.124 work. All reports seem to state that 3.4.x.x series drivers fail.
As a result, I wanted to know how far forward I could go before things would break, and I wanted to grab the drivers from a trustworthy source. As a result, I visited the Internet Archive’s trove of (more trustworthy) archived data from Prolific’s own site:
This package contains WDF WHQL driver v126.96.36.199.
This package contains WDF WHQL driver v188.8.131.52 just like the newer v130 file.
This package contains WDF WHQL driver v184.108.40.206. Probably old enough to work, as the release notes only mention Windows 7 and have no mention of chips being discontinued or counterfeit chips.
This package contains WDF WHQL driver v220.127.116.11. Probably old enough to work for much the same reason as above.
This package contains WDF WHQL driver v18.104.22.168. This driver brings support for “next gen” chips (Codename EA/TA/TB), but also now contains the counterfeit warning in the release note. It’s possible this driver might work if you have a genuine chip on Windows 10, but it’s uncertain.
From what I can see, it seems that v1417 is the most preferable package to install, as it has the last v3.3.x.x series driver. After installing the package, manually updating the drivers allows the choice of driver version.
Once the older version is installed …
… the port becomes workable. Unfortunately, it seems that Windows likes to try and update the drivers to the latest version at any unplug/reboot opportunity. One way around it is to use a registry file/group policy entry to prevent installation for that particular type of device, but then, you can only use the adapter on whichever port you have already installed it on. Plugging it into another USB port will result in a new device for which you are disallowed to install drivers for due to the group policy entry. To undo, you will need to remove the device IDs from HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\DeviceInstall\Restrictions\DenyDeviceIDs.
It’s amazing how competition in the USB to Serial bridge chip market has resulted in a number of stupid shenanigans. When FTDI started to brick counterfeit chips, I was concerned. The main alternative, Prolific, were not guilt free either as their drivers would frequently BSOD when encountering counterfeit chips, potentially causing data loss and more panic than absolutely necessary. Over time, this mellowed to a more “gentle” Code 10 error, but now, the code is being invoked to cause their older chips to be unusable under the latest OS. This is a form of forced obsolescence which is wasteful, and forcefully encourages consumers to fork out money to buy a new device. I suppose this may be a way of limiting any “undetectable” fakes.
Of course, this is merely a software restriction, as it can be bypassed by running older drivers. Unfortunately, this also causes problems – older drivers like to be automatically replaced with newer ones, meaning manual intervention may be necessary to keep things working through a reboot or unplug/replug cycle. But worse still, older drivers can contain bugs and lack support for some baud rates and newer chips (in case there is a mixed environment of new and old chips). Such restrictions are not an issue for Linux, and running an older OS inside a VM.
I’m disappointed. I own a number of older Prolific devices, all of which are genuine. They’re still perfectly physically functional. To leave me out in the cold for your own commercial interests wastes my time and effort to work-around. Your excuse that Windows 10 compatibility was not promised does not hold water when an older version of your own driver works absolutely fine for the most part, and under Linux, there has never been an issue per-se. The hardware didn’t suddenly become impossible to work under Windows 10 – you just chose to make the latest drivers “fail” to work with it.
But I suppose we aren’t left with many options. Winchiphead CH341-type chips are fairly cheap, but they’re not that reliable. The Silicon Labs CP210x is another alternative, but I haven’t had much experience with them. One that I haven’t seen is the Moschip MCS7720, although these are probably hit and miss too. There were formerly other alternatives, but I suppose they’re too expensive for the “cheap-as-chips” market of today.