Uncaught Exception During Write (getOverlapped Result): Unknown error code 433

[Dardin-dale]

SerialPort Version

10.4.0

Node Version

16.14.0

Electron Version

19.0.11

Platform

Microsoft Windows NT 10.0.19045.0 x64

Architecture

x64

Hardware or chipset of serialport

STM32f103

What steps will reproduce the bug?

When there is a power disruption during write, i.e. EMI or occasionally physical disconnection there is an uncaught exception.

self.port in this context is the SerialPort instance

async function async_call(self, resolve, reject, command){
try {
    self.port.once('error', err => reject(err));
    let timer = setTimeout(() => {
      // self.close()
      self.port.removeAllListeners('error');
      reject(
        "Device timed out. CMD: " +
          command.toString().trim() +
          " failed. Com: " +
          self.com
      );
    }, 5500);

    await self.port.write(command, (err) => {
        if(err) {
            self.port.removeAllListeners('error');
            reject(err);
        }
    });
    
    ///resolves on 'data' event from parser

catch (err) {
    reject(err)
}
}

and even this doesn't capture the error:

process.on("unhandledRejection", (reason, p) => {
  Logger.log("error", "Unhandled Rejection at: "+ p + " reason: " + reason)
  console.log("Unhandled Rejection at: ", p, "reason:", reason);
  // application specific logging, throwing an error, or other logic here
});

What happens?

Results in a pop-up:

A JavaScript error occurred in the main process

Uncaught Exception:
Error: Writing to COM port (GetOverlappedResult): Unknown error code 433

I think I've seen error code 31 as well for a physical disconnect 433 seems to show up from an EMI event. This exception blocks the entire process and I can't seem to catch it.

What should have happened?

The device is able to reset both on the board and it appears to reset in windows after an EMI event through the Windows Device Manager but my application will completely stop until that pop-up is acknowledged which is a problem when I am trying to collect data from multiple devices overnight.

I see in the documentation that errors can occur on the stream with an 'error' event instead of through the callback. I'm going to try again with a catch on the parser instead of the port? The 'error' event does not appear to be present on the port nor in the write callback.

Additional information

I have EMI shielding but there's only so much I can do. I only run into this after the port has already made 1000+ calls after hours of running with no issues. I can occasionally trigger it with unplugging my device at the "right" time since I have an interval checking for the listed devices.

[GazHank]

I wonder if this could be similar to the issue in this thread there seem to be suggestions to disable the "USB Selective Suspect" setting, or rollback a problematic windows hotfix

[Dardin-dale]

Could be related, I definitely have USB selective suspend disabled in both the device manager as well as the windows power plan. There could be more settings/registry keys in Windows that I'm missing but the issue was only with the EMI exposed device. I tried playing with my error handling else where in the code base but my test device got fried from the EMI before I was able to find a mitigation on the software side.

Edit: read through my notes and didn't see a fix. fixing my error handling only fixed the manual disconnection error not the unexpected EMI failure.