Windows "process cannot access the file because it is being used by another process" in CI
Windows refused to open or delete a file because another process still holds an open handle to it. Unlike Linux, Windows enforces sharing locks, so this surfaces constantly in CI.
What this error means
A build, copy, or cleanup step fails with a sharing violation. It is often intermittent: it passes when the prior process released the handle in time and fails when an antivirus or indexer is still scanning the file.
System.IO.IOException: The process cannot access the file
'C:\actions-runner\_work\repo\bin\app.exe' because it is being used by another
process.
at System.IO.FileStream..ctor(...)
at Build.CopyOutput()Diagnose it: which runtime is actually on PATH?
Runners ship multiple versions of most runtimes and select one through a version manager. When a setup action and a version file disagree, the resulting error is about your code rather than the version.
which -a <runtime>
<runtime> --version
echo "PATH=$PATH" | tr ":" "\n" | head -20
# does a version file in the repo disagree with the workflow?
cat .tool-versions .nvmrc .ruby-version .python-version 2>/dev/nullCommon causes
A previous process has not released the handle
A test host, watcher, or the build server can keep a binary open briefly after it appears to exit, causing a sharing violation on the next access.
Antivirus or the search indexer is scanning the file
On Windows runners, real-time protection opens new files to scan them, holding a transient lock that races your build.
Two parallel steps touch the same file
Concurrent jobs or matrix legs writing the same output path collide on the lock.
How to fix it
Retry the file operation with a short backoff
Most lock races clear within a second or two, so a bounded retry usually succeeds.
$ok = $false
foreach ($i in 1..5) {
try { Copy-Item bin/app.exe dist/ -Force; $ok = $true; break }
catch { Start-Sleep -Seconds 2 }
}
if (-not $ok) { throw 'file stayed locked' }Find which process holds the handle
Identify the offending process so you can fix the root cause rather than just retrying.
# requires Sysinternals handle.exe on the image
handle.exe bin\app.exeHow to prevent it
- This is a transient class of failure. On Latchkey managed runners, self-healing auto-retries transient file-lock errors, so a one-off sharing violation does not fail the job; still, ensure prior processes exit and avoid two steps writing the same path. Windows runner minutes also bill at roughly 2x Linux, so moving lock-prone file work to a Linux job saves both flakiness and cost.