win: Repeated use of file dialog in asynchronous context causes access violation

[KingRainbow44]

I have a CLI tool which runs a prompt loop in an asynchronous Tokio context.

/// This gets called from `async main()`.
pub async fn prompt_loop() -> anyhow::Result<()> {
    loop {
        let selection = Select::with_theme(&*THEME)
            .with_prompt(...)
            .items(MenuOption::options())
            .default(0)
            .interact_opt()?;
        clearscreen::clear()?;

        match MenuOption::from_index(selection) {
            // ...
            Some(MenuOption::ImportSet) => import().await?,
            // ...
            _ => {}
        }
    }
}

async fn import() -> anyhow::Result<()> {
    info!("Select a folder of JSON files to continue...");

    let directory = FileDialog::new()
        .set_title("Select a folder of JSON files to import")
        .pick_folder()
        .ok_or_else(|| anyhow::anyhow!("No directory selected"))?;
    info!("Selected directory: {}", directory.display());

    // ...

    Ok(())
}

With this loop, I can access the file dialog once, but attempting to opening it again prints a cryptic:

10000 46000000
error: process didn't exit successfully: `executable.exe` (exit code: 0xc0000005, STATUS_ACCESS_VIOLATION)

which is thrown when calling let directory = FileDialog::new().

[PolyMeilex]

Does this reproduce the segfault? For me it does not (with tokio with full feature flag).

#[tokio::main]
async fn main() {
    loop {
        import().await;
    }
}

async fn import() {
    FileDialog::new().set_title("abc").pick_folder();
}

[KingRainbow44]

Hello! Sorry for the late reply, but I have managed to reproduce the exception with the snippet from above.

use rfd::FileDialog;

#[tokio::main]
async fn main() {
    loop {
        import().await;
    }
}

async fn import() {
    FileDialog::new().set_title("abc").pick_folder();
}

with my Cargo.toml looking like:

[package]
name = "rfd-segfault-repro"
version = "0.1.0"
edition = "2024"

[dependencies]
tokio = { version = "1", features = ["full"] }
rfd = "0.16.0"

It's interesting to note that I wasn't able to reproduce the segfault until I started playing with adding additional dependencies that could have potentially been problematic. When the segfault showed up, I was able to remove them from Cargo.toml and do a full cargo clean with the segfault still occurring. Operating system issue?