SerialPort.list() crashes Node when used with brother device

[rb-serin]

SerialPort.list() crashes Node ( used on electron) when a Brother printer is attached

(Please answer all 3)

• What are you trying to do?
  Listing all devices attached to the machine

• What happens?
  Node crashes leaving a blank page on electron renderer process

• What should have happened?
  Getting a list of devices or an exception

Code to Reproduce the Issue

const SerialPort = require('serialport')
SerialPort.list()

Versions, Operating System and Hardware

• SerialPort@ 7.x and 9.x
• Node.js v14.15.4
• Windows? Linux? Mac? Windows
• Hardware and chipset? (Prolific/FTDI/Other) Intel core i5 with Brother printer attached

This is the same problem as #1518
See also https://www.gitmemory.com/issue/serialport/node-serialport/2155/771687008

[GazHank]

Hi @rb-serin

Would you be able to confirm the specific version(s) of electron and serial port that you are using?

Also, could you confirm if you are facing the issue of the device not being assigned a COM port per the prior issue you referenced?

If the COM port isn't being assigned by windows you might want to manually configure the COM port within device manager (there are some instructions here: https://www.virtual-serial-port.org/articles/com-port-on-windows-10/#assign ). Although even if that does resolve your issue it sounds like the error handling/ fault tolerance could be improved.

[GazHank]

This might be related to #2155 as both seem to relate to unexpected behaviour; in both cases I think we need more info to be able to investigate and debug

[nyholmjan]

I can reliably reproduce this issue. The key part is to query for ports while windows is installing usb to serial drivers. It can be reproduced simply by removing the usb to serial drivers of the device from device manager and then unplugging the device and plugging it in again, the crash will happen when serialport.list() is called while the drivers are being reinstalled.

Versions, Operating System and Hardware

• serialport: 9.2.0
• electron: 13.2.1
• os: windows 10
• hardware: u-blox EVK-M101

Code to reproduce

const serialport = require("serialport");
window.setInterval(() => {
    serialport.list().then(ports => {
        console.log(ports)
}, 1000);

[GazHank]

I wonder if this is due to changes being made to the data stored in the windows registry as we are executing the list(). Since much of the data returned by the list operation comes from the registry if it's content changes mid process it could causes this breakage. I can't see any unhandled exceptions based on a quick scan of the code, but that does feel like the most likely issue.

I had previously thought about avoiding direct registry access, and using the windows APIs more fully to provide us a little more abstraction, in the hope that the APIs would provide better fault tollerance and handling of weird edge cases. I'll try to take a look at this again when I get some time. If anyone wants to take a look at the code in question and perform some debugging, the EIO_List and associated methods it calls can be found @ https://github.com/serialport/node-serialport/blob/master/packages/bindings/src/serialport_win.cpp#L782

[GazHank]

thanks @pseudorandomseed that's great news!

I mean that you have access to a device that exhibits this issues... I'm really sorry that this is causing crashes for you (and your customers).

Would you be able to try adding print statements to the EIO_List method per @reconbot suggestion: #2155 (comment)

This would allow us to see at which step of the process the crash is occurring? (let me know if you would like any help or support to make the changes, or to setup your windows machine to be able to build the code)

[reconbot]

That's about right

[caffeinatedbits]

@reconbot see #2325

[reconbot]

Can someone test serialport@10.0.0 to make sure this is still good?

[nyholmjan]

Can someone test serialport@10.0.0 to make sure this is still good?

It hasn't been verified that the similar issue with the u-blox devices described above has the same cause, but I have tested that one with serialport@10.0.0 and the issue still persists.

[GazHank]

Can someone test serialport@10.0.0 to make sure this is still good?

It hasn't been verified that the similar issue with the u-blox devices described above has the same cause, but I have tested that one with serialport@10.0.0 and the issue still persists.

Are you also experiencing the u-blox device issue with the latest v9 release too? If so I wonder if we have a different defect we need to address for that device

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in a week no further activity occurs. Feel free continue the discussion or ask for a never-stale label to keep it open. If this is a support issue, consider sharing it on stack overflow to get more eyes on your problem.