FTDI and CH340 driver blue screens in 2024

[Georgy.Moshkin]

Had two blue screens in 2023 with CH340 usb to serial adapter. One blue screen with FTDI usb to serial adapter today: Windows 11, experimenting with Web Serial API. Right after I disconnected serial cable, blue screen #BugCheckCode 0x000000000000001A caused by ftser2k.sys. Both chip manufacturers should do something about it, rewrite drivers from scratch. Why it should be so fragile for so many years?

[Postal2]

Firstly, it is not a “serial cable” in the RX-TX sense, but a USB that has been removed. Secondly, you need to be careful that RX is in an inactive state when you remove the USB. Thirdly, if it is impossible to ensure that RX is inactive, disable the adapter in the device manager, then turn it on again and immediately remove the USB.

[Georgy.Moshkin]

Official websites state that products are "robust and simple-to-use" (ftdichip.com) and there is constant research for "optimizing their integration, improving overall performance" (wch-ic.com). I am pointing to a great opportunity for both companies to prove these words. FTDI can make their products more "robust and simple-to-use" and WCH can conduct more research on "optimizing their integration" into Microsoft Windows.

EDIT: Thanks, haven't heard about this method. One of the reasons why I perform backups is because of serial converters   

Thirdly, if it is impossible to ensure that RX is inactive, disable the adapter in the device manager, then turn it on again and immediately remove the USB.

[RoGeorge]

...Both chip manufacturers should do something about it...

Or, maybe you should do something about it.  It's not the 90's any more.  Still using Windows in 2024? 

Try Linux, and both the CH340 and the FTDI will just work.  I don't recall installing any drivers for them in Linux, and don't recall them ever crashing the OS.

[TizianoHV]

I'm on windows 11 too and I use a lot of CH340C's with my projects. I often disconnect them from usb ports, even during transmission and it never gave me errors. (driver installed with CH341SER.EXE)
Isn't something with your pc?

[Georgy.Moshkin]

...Both chip manufacturers should do something about it...

Or, maybe you should do something about it.  It's not the 90's any more.  Still using Windows in 2024? 

Try Linux, and both the CH340 and the FTDI will just work.  I don't recall installing any drivers for them in Linux, and don't recall them ever crashing the OS.

It will only help if I provide each client with a laptop or tablet with a pre-installed Linux system and application. But this doesn't solve the problem in general; the bug still exists. In modern world some products should be compatible with Linux, MacOS, Android AND Windows. E.g., USB microphone. A very small amount of microphone users will change their operating system and production. They will probably leave a bad review, request a refund and buy a new microphone.

I need to note that last winter I've spent almost one week to download Visual Studio and KMDF (kernel mode driver framework) example from Microsoft's GitHub and modified it to receive serial stream from STM32's USB endpoint. Figured out how to put Windows in "test mode" and everything worked with no blue screens. Of course, there should be endpoint with CTS/RTS/etc. signals and other "garbage" which I did not implement, and I have no time for this and money to sign the driver. I just want to understand, what "a piece of serial" code with complex memory management is implemented in those FTDI and CH340 Windows drivers... and why this bug should not be mentioned (I had 50 dislikes on a video with 1k views) and why the only solution is to change operating system?

I had no blue screens since Windows 10. And I was really happy with both FTDI and CH340 until I wrote a serial loopback test program last year. E.g., in this video I use 5 (five) usb-to-serial adapters:

That's when I've got few blue screens from CH340. And now FTDI too!

I'm on windows 11 too and I use a lot of CH340C's with my projects. I often disconnect them from usb ports, even during transmission and it never gave me errors. (driver installed with CH341SER.EXE)
Isn't something with your pc?

With FTDI you should perform the following:
1) Open notepad, paste all your valuable information like passwords, crypto-wallet keys, 2FA secrets, etc.. The more the better!
2) Delete all backups (to make it more fun!)
3) Start sending data from external device to serial converter. In this particular case it's [55 55] [64 bytes] [55 55] [64 bytes] and so on sent at 115200bps, default settings.
4) Open port using terminal program, in this case it was opened using Web Serial API from browser, but I think anything that activates the driver using CreateFile() and performs repeating calls to ReadFile() will be enough to experience this driver bug.

p.s. I even had a video mentioning this problem which received something like 50 dislikes and 3 likes. And everyone had an urge to share with me how everything works with on-board serial chips of Arduinos, esp32, etc. Unfortunately, I deleted that video along with comments. I don't understand why this mapped differently in human brain (the "serial" thing). Here is a thought experiment. Let's replace "serial converter" words with "usb flash drive". I can imagine an awkward situation when a Linux guy shares his USB flash drive which "gives blue screens of death". And some office workers tell stories about viruses that coming from Linux and other nonsense. You can't just install the Linux and solve all the problems. Moreover, problem is not in Linux, and not in Windows. Problem is in a buggy driver 

[Postal2]

Isn't something with your pc?

No.

Problem is in a buggy driver 

Yes.

I experimented with CP2102 (most reliable usb-uart). Driver from 2004 works well. All new drivers made by stupids.

[SiliconWizard]

The FTDI drivers have been very robust, so I don't know what's up here. Never had a single crash with FTDI drivers on Windows that I can remember of. And they come with Windows already, there is rarely a need to install them manually, but if you want to do so, obviously make sure they are downloaded from FTDI and nowhere else.

Regarding drivers provided by other vendors, such as for the CPxxxx, that's a different story.

[Postal2]

.... Never had a single crash with FTDI drivers on Windows that I can remember of. ...

Have you crashed FX2LP driver (as I remember, you are a boss with FX2LP-drivers)?

[SiliconWizard]

.... Never had a single crash with FTDI drivers on Windows that I can remember of. ...

Have you crashed FX2LP driver (as I remember, you are a boss with FX2LP-drivers)?

Not sure what driver you are refering to. I suppose drivers that are provided by Cypress?
Yes, I've used the FX1 and FX2, but never with the Cypress drivers. They were indeed a piece of crap, and at the time (that was over 15 years ago), Cypress clearly stated that the drivers were just for testing purposes and not production-ready (so you pretty much had to either develop your own driver, or buy it - some companies sold Windows drivers at the time!)

I've heard that the drivers Cypress provides are better these days, but haven't tested any of that in years, so I can't say. I still wouldn't be hugely surprised if they weren't fully stable.

But if you're designing a custom USB device that you'll use in bulk mode only, Windows comes with WinUSB (has been since Win 7 AFAIR), which allows you not to have to write any driver - just the .inf file. Have a look at it, it's a real time-saver. It gives you the equivalent of libusb on Linux.

Otherwise, if it's not bulk, you can implement a HID device, which won't require any driver. Good if the max throughput you can get with HID fits your requirements.
I also think recent Windows now come with a native USB-serial driver (that wasn't the case for a long time, explaining why vendors *had* to provide custom drivers just for that), so that's something to look at if you don't care about supporting older Windows versions.

[amwales]

I'm using windows 10 and cant say I remember the last time I saw a blue screen and I use ch340 quite often pretty happy with them.

edit *** oops didn't watch your video, looks like you con reproduce it too, sadly looks like not enough people doing that to cause anyone to bother fixing it

[Postal2]

Yes, I've used the FX1 and FX2, but never with the Cypress drivers. They were indeed a piece of crap, ....

Not right. Drivers from Cypress are good and stable (for any system), but you must have to deal with DeviceIOcontrol. When you have good software, the driver works well.

In any case, your opinion is valuable.

FX2LP is mentioned because Cypress provides the sys driver and you work directly with it. And now you can see how many people do not know how to work with it - that is, they cannot make a DLL interface for it. And these same people wrote interfaces for FTDI and everything else - the result is predictable.

[coromonadalix]

@  Georgy.Moshkin   you rant is absolutely unfounded,  i use original ftdi cloned ftdi,  cypress, microchip, CH340 and 341, prolific      usb to serial interfaces, usb to spi   ....   the list goes on


Only time it crashes if when you try to open COM port at the same time, or some software who can not handle very well,  i use termite and tons of other serial terminal and specially crafted ones, or your windows device COM ports settings are set by default at 9600 bauds and you request higher speeds ....

absolutely nothing bad to say, even when FTDI gate happened, recovered  all my cloned ftdi  without problems,  if you lock windows drivers updates  you should have known  the good ones before that and the one who may mess with the clones

do some homework   and if you are still ranting  DO WRITE your own drivers ...

windows 8 was good for any non signed drivers,  win 8.1 complicated things a lot,  win10  nothing to say,  win 11  up tp 22h2  was ok


NOW Msoft  on 23h2 it began a bit,  and now 24h2 may or will block drivers   if they find them problematic, even if they worked fine in win 10     ...

you'll have to dig  further in win 11 to find where they are flagged bad,  you'll get only driver exclamation error in device manager,  but to see them flagged as bad you have to search

[Georgy.Moshkin]

@  Georgy.Moshkin   you rant is absolutely unfounded,  i use original ftdi cloned ftdi,  cypress, microchip, CH340 and 341, prolific      usb to serial interfaces, usb to spi   ....   the list goes on

I had 3 blue screens pin 6 months. It's one blue screen per two months on average. Windows gives an error, creates a memory dump and even provides debug information pointing to serial drivers. Not sure how stability of cypress, microchip and prolific drivers can contribute to ch340 and ftdi though...

do some homework   and if you are still ranting  DO WRITE your own drivers ...

okay

According to documentation on Microsoft website (link),

Code: [Select]

Bug Check 0x1A: MEMORY_MANAGEMENT
Parameter 1 is 0x1010 - The caller is unlocking a pageable section that's not currently locked. (This section was either never locked or it's being unlocked twice.)So, what may be happening here? I don't know how these drivers work, just an idea.
I think that driver may have two problematic callbacks:
1) USB removed - removal_callback() is called and unlocks some memory
2) Data transmission - transmission_callback() is being called. This function unlocks some memory, performs some work and then locks it right before returning.

Because of some driver imperfectness, transmission_callback() is called AFTER removal_callback() Because  removal_callback() already unlocked some memory, error occurs. In such case this bug can be fixed relatively easy. E.g., by adding some flag that will prevent transmission_callback() code from running ("if (flag) {return;}") if removal_callback() set this flag to true..

In other words, correct operation
[unlock] [do smthng] [lock] ... [unlock] [do smthng] [lock] ...

and erroneous operation is
[unlock] [do smthng] [lock] ... [usb removal] [unlock] [free resources] ... [unlock] [do smthng] [lock] ...
when we have two unlocks in a row

[Postal2]

I had 3 blue screens pin 6 months. It's one blue screen per two months on average. ...

Blue screens are very annoying when Visual Studio has files open. You will lose these files, the first time I was very scared. The files were recovered from the pieces that Windows creates when scanning the disk.

Use method I describe above to remove usb adapters. You can only disable in device manager, but I can forget, therefore I enable it back before remove. You can write script for this instead of drivers.