中文
devexamples
← Debugging Guides

阅读中文版本

Windows: The process cannot access the file because it is being used

Diagnose the Windows file-in-use error by finding the locking process with handle or Resource Monitor, and releasing or retrying safely.

beginnerdebuggingwindowsfilesystem

Symptoms

  • The process cannot access the file because it is being used by another process
  • Deleting or moving a file fails on Windows
  • Builds intermittently fail because a file is locked

Possible causes

  • Another process holds an exclusive handle on the file
  • Antivirus or a search indexer is scanning the file
  • A build tool or editor still has the file open
  • A previous crashed process left a stale lock

Diagnosis steps

Find the process holding the handle

handle.exe <filename>  # Sysinternals

Interpretation

The output names the PID and process, which you can then close or investigate.

Use Resource Monitor for a GUI view

resmon -> CPU -> Associated Handles

Interpretation

Searching the filename shows which process holds it without extra tools.

Check whether antivirus or indexer is involved

Interpretation

Excluding build directories from real-time scanning removes intermittent locks.

Root cause

Windows enforces share modes: when a process opens a file without sharing write or delete access, other processes receive a sharing violation rather than being allowed to proceed. The file is not corrupt; another handle exists. Antivirus and indexers frequently hold such handles briefly, causing intermittent failures.

Fix

Identify and close the holding process, then retry. Add retry-with-backoff for file operations in build and deploy scripts, exclude build and cache directories from real-time antivirus scanning, and open files with appropriate sharing flags in your own code so concurrent readers are not blocked.

Verify the fix

Retry the delete, move, or build; it succeeds, and handle.exe or Resource Monitor no longer lists the file as held by another process.

Symptoms

Windows reports the file is in use by another process. The error is a sharing violation, not corruption, and it often clears after closing a program or waiting for antivirus to finish.

Diagnosis

Find the holder:

handle.exe C:uildoutput.dll
# or use Resource Monitor -> CPU -> Associated Handles

Fix

Close the holder and add retries:

$attempts = 0
while ($true) {
  try { Remove-Item C:uildoutput.dll -Force; break }
  catch { if (++$attempts -gt 5) { throw }; Start-Sleep -Milliseconds 200 }
}

Exclude build directories from real-time scanning.

Verification

Retry the operation; it completes, and handle.exe shows no remaining holder for the file, confirming the lock is released and the retry logic guards future intermittent locks.

Designing Around Sharing Violations

Windows grants access based on the sharing mode the first opener requested, so two processes that both intend to read a file still conflict if one opened it exclusively. Well-behaved tools open files with sharing flags that permit concurrent readers, and build systems retry transient violations rather than failing immediately. Antivirus and indexing services are the most common unexpected holders because they open files shortly after they are written, which is exactly when a build wants to rename them. Excluding generated and cache directories from real-time scanning removes most of this class of intermittent failure without weakening endpoint protection on user data.