After Windows 10 Update My Program Can't Open FTDI USB Serial Convertor

[imk]

Hello,
Been working on a little Win10 App that talks to an Arduino and AM2320 Meteo sensor via serial, however FTDI USB devices will no longer Open?

I have been developing a Win10 application with Visual Studio Community Edition 2019 that basically opens a COMM port with
hComm = CreateFileA(CommPortName, GENERIC_READ | GENERIC_WRITE, FILE_SHARE_READ | FILE_SHARE_WRITE, 0, OPEN_EXISTING, 0, 0);

Now i do a little work on this app every few days and have been making steady progress to the point that it is just about finished.
This evening I sat down to do another couple of hours at it but the when I try to open a FTDI or Prolific USB Comm Port CreateFileA returns INVALID_HANDLE_VALUE
It opens a 16550 UART port Com1: just fine, but it won't open any of the various USB to Serial convertor adaptors I have.

I think a Win10 update came in a couple of days ago also some VS2019 updates have come in.
From Device Manager the various USB to serial ports i have tried all seem to have installed without error but CreateFileA won't open them.

Any ideas please as this was all working a couple of days ago and now CreateFileA just fails :-(

I have also tried the following DOS Command Prompt pipe command
Type My.TXT >> Com1: which works fine as is 16550 UART port
but Type My.TXT >> Com11: which is a FTDI device fails to work as i guess even windows can't open the port


Many thanks imk

[oPossum]

Call GetLastError() to determine why it is failing.

[Karel]

Use this: https://www.teuniz.net/RS-232/

[imk]

Thanks for input

GetLastError() returns 2 (0x2) ERROR_FILE_NOT_FOUND
Which is odd as com11 port called shows in device manage.

I take fairly regular snap shot of my system C: disk, last one was on  7 may 2021 and my project was working then.
So i am going to fall back to it, disable windows updates and retest, I'll Be Back :-)

imk

[SeanB]

Likely FDTI driver is broken, or the chip was detected as a fake and bricked. There is a thread about this in the blog, look for it, as it has both the fixes for the bricked chips, and also drivers that do not have the fake detection code and brick routines in them.

[oPossum]

Thanks for input

GetLastError() returns 2 (0x2) ERROR_FILE_NOT_FOUND

Make sure you are using \\.\ before the COM port name. Required for ports above COM4.

Code: [Select]

char *CommPortName = "\\\\.\\COM11";


[imk]

oPossum

twas the path \\\\.\\ required and many thanks.

Thing is I am working of two comm projects 1st one talking to a NexTion display via a FTDI usb/serial board it is marked on the back FDTI232 it defaults to COM3

The 2nd comm project talks to an Arduino and has been tested via the Arduino on board usb/serial port which was fine.
This arduino project almost complete so decided to test on another FDTI board over long rs232 wires, this FDTI is marked on the back YP-05 it defaults to COM11

As both project comms are the same i link in my CommPortHandler.cpp to both projects, one works other didn't when on YP-05  FDTI board.
So as been few days since i worked on either projects and windows update came in that refused to see my USB mouse and VS2019 updates.
Me suspects those changes rather than the open comm port error being reported.

Many thanks for the \\\\.\\ BTW i looked into which comm ports require full path and it seems  above com10 require it.
But \\\\.\\ works on com1 so have just appended comx to \\\\.\\ and now sorted many thanks imk

[SiliconWizard]

Actually, it's weird if it worked before without the "\\\\.\\" path prefix... I think this has been required for many Windows versions.

[oPossum]

It has been the proper way to specify a local device since Windows NT 3.1 (28 years ago). Some devices such as the lower COM ports will work without it, but that backwards compatibility could go away at any time.

[SiliconWizard]

It has been the proper way to specify a local device since Windows NT 3.1 (28 years ago).

Yeah. As I remember, it was properly specified in the Windows API doc for CreateFile(), a long time ago already. Not following the doc is a sure way of getting this kind of issues.

Hint: NEVER use any Windows API function without reading the official doc. And it's actually not bad at all. Do not take code excerpts from books and blogs, at least without checking first the former.