Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unplug serial device cause system shutdown on windows #157

Open
ArthurZhou opened this issue Feb 4, 2024 · 8 comments
Open

Unplug serial device cause system shutdown on windows #157

ArthurZhou opened this issue Feb 4, 2024 · 8 comments

Comments

@ArthurZhou
Copy link

Once the connection is built, power off the serial device will cause the system to shutdown.

My serial device is an NodeMCU ESP32S. It communicate with my computer through Bluetooth.

Windows Bluetooth config:
image

Windows version:

Edition	Windows 10 Enterprise LTSC
Version	21H2
Installed on	‎8/‎15/‎2023
OS build	19044.3693
Experience	Windows Feature Experience Pack 1000.19053.1000.0

My rust code:

// #![windows_subsystem = "windows"]

use std::{env, fs};
use std::io::Read;
use std::path::{Path, PathBuf};
use std::time::Duration;

fn main() {
    let path = &env::current_dir().unwrap();
    let port_name = "COM6"

    let baud_rate = 115200;

    loop {
        start(path, port_name, baud_rate);
    }
}

fn start(path: &PathBuf, port_name: &str, baud_rate: u32) { // this is the receiver function
    let port = serialport::new(port_name, baud_rate)
        .timeout(Duration::from_secs(5))
        .open();

    match port {
        Ok(mut port) => {
            let mut serial_buf: Vec<u8> = vec![0; 1000];
            println!("Receiving data on {} at {} baud:", &port_name, &baud_rate);
            loop {
                match port.read(serial_buf.as_mut_slice()) {
                    Ok(t) => {
                        let s: String = String::from_utf8_lossy(&serial_buf[..t]).to_string();
                        // execute some command, ignoring the "ALIVE" message
                    },
                    Err(_) => { // the device will send an "ALIVE" message every 2 secs. if not, the device might be disconnected. 
                                    // and we shall restart the receiver function and wait for next connection
                        println!("COM port disconnected");
                        break;
                    },
                }
            }
        }
        Err(e) => {
            println!("Failed to open \"{}\". Error: {}", port_name, e);
        }
    }
}
@sirhcel
Copy link
Contributor

sirhcel commented Feb 5, 2024

Hello @ArthurZhou, does this mean your application exists or that your operation system shuts down and turns the lights off?

I would expect that the application quits due to the serial port getting closed by the operating system when your Bluetooth device gets powered off. But not the latter. Are you getting the message COM port disconnected when powering off the Bluetooth device?

@ArthurZhou
Copy link
Author

The fact is that my operation system shuts down. I know that this sounds unbelievable, but it just happened yesterday. So far, I have tried to reproduce this bug 8 times, and this happened 3 times. I'm wondering if this is a system driver bug.

Some related(maybe) logs from Windows Event Viewer:
logs.zip

image

@TiemenSch
Copy link

I was testing the disconnection behavior on my system, too (Surface Pro 8) and it gave me a blue screen repeatedly when disconnecting a USB device. And with disconnection I meant pulling the cable to see what happens.

@ArthurZhou
Copy link
Author

I was testing the disconnection behavior on my system, too (Surface Pro 8) and it gave me a blue screen repeatedly when disconnecting a USB device. And with disconnection I meant pulling the cable to see what happens.

Maybe a windows bug, as I cannot reproduce it on Ubuntu desktop and arch linux.

But this doesn't happened when I use Python to do this on windows

Weird🤔

@TiemenSch
Copy link

Yeah, never had any troubles with the same executable on my Ubuntu desktop either.

My Windows BSOD sequence:

  1. good connection and operation
  • I re-open the connection periodically to receive some data and then close again.
  1. pull plug
  2. plug back in
  3. BSOD

Where at step 2 and 3 I often receive some disconnect error or a subsequent "no rights" kind of error for the replugged device. I wouldn't mind an error or even a panic, but a full BSOD is kind of heavy hitting.

Could it be related to the x86_64-pc-windows-gnu target? I don't know the ins and outs of the target-specific dependencies/implementations.

@TiemenSch
Copy link

Is there any progress on this? What can I do to help pinpoint the problem?

@sirhcel
Copy link
Contributor

sirhcel commented Jul 29, 2024

Is there any progress on this? What can I do to help pinpoint the problem?

Not from my side due to way lower hanging fruits.

A log or screenshot of the BSOD and an minimal working example could (like in exapmples/ in a fork of this project) could be a good start. Additionally the Python counterpart of this example. And finally some insights in how to trace "syscalls" on Windows for comparing setup and actions in both cases.

@ArthurZhou
Copy link
Author

Is there any progress on this? What can I do to help pinpoint the problem?

Not from my side due to way lower hanging fruits.

A log or screenshot of the BSOD and an minimal working example could (like in exapmples/ in a fork of this project) could be a good start. Additionally the Python counterpart of this example. And finally some insights in how to trace "syscalls" on Windows for comparing setup and actions in both cases.

currently i am unable to reproduce this bug after i updated my windows.

i've tried to reproduce this bug on Windows 10 LTSC 2021, with latest system bug fixes installed (2024/08/03)

i will try to collect and post the bsod info and other detailed info here if this happens again

(sorry for my poor english

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants