Mathjk
## Summary On Windows, running RustScan in a process environment that lacks the `SystemRoot` variable (services, scheduled tasks, WMI-spawned processes, sanitized environments) **aborts** the process 鈥?even when scanning a literal IP that needs no DNS at all. ## Reproduction ```python subprocess.run(["rustscan.exe", "-g", "-a", "127.0.0.1", "-r", "80-81"], env={"PATH": r"C:\Windows\System32"}) # note: no SystemRoot ``` Verified on Windows 11: exit code `3221226505` (`0xC0000409`), with: ```text thread 'main' panicked at hickory-resolver-0.24.4/src/hosts.rs:165:40: Environtment variable SystemRoot not found ``` The same invocation with `SystemRoot` present exits 0. ## Root cause `src/address.rs:36` builds a hickory `Resolver` unconditionally in `parse_addresses`, before any address is inspected. On Windows, `Resolver::new` eagerly loads the hosts file when `use_hosts_file` is set (the default `ResolverOpts`), and `hosts_path()` does `env::var_os("SystemRoot").expect("Environtment variable SystemRoot not found")`. Under `panic = "abort"` that panic is a hard abort. So the panic happens at resolver *construction*, not at lookup: `-a 127.0.0.1` (a literal IP) detonates it too, and `Resolver::from_system_conf()` can't even be attempted 鈥?it hits the same `expect` inside `Resolver::new`. ## Upstream note The `expect` still exists in hickory-resolver **0.25.x** (`hosts.rs`; typo since corrected to "Environment"), so a dependency bump alone doesn't fix this 鈥?the defect is in hickory-dns, but the fatal outcome is triggered by our unconditional eager construction. ## Suggested fix At the call site: when `SystemRoot` is absent on Windows, skip `Resolver::from_system_conf()` (fall back to the existing `cloudflare_tls()` resolver, which is already the behavior when system config is unreadable) and build resolvers with `use_hosts_file = false` so `Resolver::new` itself can't panic. Implemented on `Mathjk/RustScan@fix/epipe-and-env-abort`; verified the env-wiped repro now exits 0.