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()

Common 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.exe

How 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.

Related guides