`cargo-wdk` integration tests fail intermittently when Rust Analyzer is enabled (cargo clean can’t delete build-script)

[svasista-ms]

Summary

When Rust Analyzer (VS Code) is enabled for the cargo-wdk test fixture projects, cargo-wdk integration tests intermittently fail. The failure happens during a cargo clean step inside the test flow: Cargo cannot remove a generated build-script executable because it’s locked by another process. This reproduces on main. This looks like a Windows file-locking / concurrent-cargo access issue between the test runner and Rust Analyzer’s background cargo invocations. However, incorrect locking when build and artifact directories are same were fixed in upstream in cargo.

Environment

OS: Windows 11
VS Code: 1.108.1
rust-analyzer extension: Version 0.3.2761, Server Version 0.3.2761-standalone (080e70378c 2026-01-18)
Toolchain (latest stable where reproduced):

cargo 1.92.0 (344c4567c 2025-10-21)
rustc 1.92.0 (ded5c06cf 2025-12-08)

Repro steps

1. Open the repo in VS Code with Rust Analyzer enabled.
2. Ensure Rust Analyzer is enabled for the test fixture projects under crates/cargo-wdk/tests
3. Run the integration test repeatedly until it fails:

cargo test -p cargo-wdk --test build_command_test -- --nocapture

4. Eventually, the test fails with an error from cargo clean indicating it cannot delete a build-script executable (Windows “file in use” / access denied).

Integration tests should be reliable regardless of Rust Analyzer being enabled in VS Code. Even if tests serialize per-fixture work (mutex keyed by fixture path), Rust Analyzer is an external concurrent actor and can still race the fixture directory.

Suspected scenario: Rust Analyzer triggers background cargo operations (check/build/build-scripts) in the same fixture directories while tests run cargo clean, leaving an open handle on a build-script exe.

ProcMon capture filtered to the locked build-script-build.exe or Output from Sysinternals handle.exe at the moment of failure to identify which process holds the file lock (likely rust-analyzer, cargo, rustc, or code.exe) are useful diagnostics that can help resolve this issue.

Originally posted by @svasista-ms in #494 (comment)

[wmmc88]

ProcMon capture filtered to the locked build-script-build.exe or Output from Sysinternals handle.exe at the moment of failure to identify which process holds the file lock (likely rust-analyzer, cargo, rustc, or code.exe) are useful diagnostics that can help resolve this issue

@svasista-ms Can you clarify this. did you use procmon or handle.exe to try to debug this? or is this a suggestion on debugging routes?

[wmmc88]

@svasista-ms There are also missing important details from this bug report. What is exact failure message? Can you attach the full failure log to this bug? Does this happen when running tests with --test-threads 1 ? Which build script is conflicting?

I think this is probably not a bug caused by this repo. Could you create a minimal example and report it to the cargo repo? under the hood this should just be running cargo clean concurrently in a workspace (containing a build.rs) that is running cargo check or rust-analyzer.

[svasista-ms]

@wmmc88, please find the log file of a failure run attached. The error is as follows:

thread 'umdf_driver_builds_successfully' (35816) panicked at C:\Users\svasista\.rustup\toolchains\stable-x86_64-pc-windows-msvc\lib/rustlib/src/rust\library\core\src\ops\function.rs:250:5:
Unexpected failure.
code=101
stderr=``````
error: failed to remove file `C:\\Users\\svasista\\Documents\\Rust\\svasista-ms\\windows-drivers-rs\\crates\\cargo-wdk\\tests\\umdf-driver\\target\\debug\\build\\serde-5949ff65e3f9b0fc\\build_script_build-5949ff65e3f9b0fc.exe`

Caused by:
  Access is denied. (os error 5)

command=`"cargo" "clean"`
code=101
stdout=""
stderr=```
error: failed to remove file `C:\\Users\\svasista\\Documents\\Rust\\svasista-ms\\windows-drivers-rs\\crates\\cargo-wdk\\tests\\umdf-driver\\target\\debug\\build\\serde-5949ff65e3f9b0fc\\build_script_build-5949ff65e3f9b0fc.exe`

Caused by:
  Access is denied. (os error 5)

note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

build_command_test.log

IIRC, I saw the error even when --test-threads 1. The conflicting build script is not consistent; it is different each time (cc, syn, wdk-sys) and I could not see any pattern.

I have captured the ProcMon session when one such failure happened. I am yet to go through the log and filter the handle (build_script_build-....exe). I also tried using handle.exe by querying the handle as soon as the test fails. However, I had some problems with the timing. I will continue on this once I have some bandwidth. I added these details to share my findings and also as next steps for debugging.

I have setup a minimal repro example at: rust-analyzer-with-cargo-clean-in-tests. I'll re-run the tests, gather more info and report it to cargo/Rust-analyzer.

[gurry]

An issue was opened in Rust Analyzer which got closed with comments saying the behaviour is as designed.

We are leaning towards a fix where we copy out test projects into a temp dir before running cargo commands on them which should keep Rust Analyzer from interfering.