Sửa lỗi 'The process cannot access the file because it is being used by another process' trên Windows

Tình huống

Đang deploy, đang build, hoặc chỉ đơn giản là muốn xóa một file log — và Windows ném ra lỗi:

The process cannot access the file because it is being used by another process.

Có gì đó đang giữ một handle mở tới file đó. Windows sẽ không cho bạn đụng vào file cho đến khi handle đó được đóng lại. Tìm ra thứ đang khóa file, rồi đóng nó đúng cách hoặc kill tiến trình đó. Vấn đề chỉ đơn giản vậy thôi.

Quy trình debug

Cách 1: Resource Monitor (không cần cài thêm gì)

Có sẵn trong mọi bản cài Windows. Đủ dùng cho hầu hết các trường hợp.

• Nhấn Win + R, gõ resmon, nhấn Enter.
• Chuyển sang tab CPU → mở rộng phần Associated Handles.
• Gõ tên file (hoặc một phần tên) vào ô tìm kiếm.
• Danh sách hiện ra PID và tên tiến trình đang giữ handle đó.

Nhấn chuột phải vào kết quả bất kỳ để kết thúc tiến trình ngay tại đó.

Cách 2: Process Explorer (Sysinternals)

Tìm được những handle mà Resource Monitor bỏ sót — đáng tải về nếu bạn hay gặp lỗi này.

• Tải về tại learn.microsoft.com/sysinternals/downloads/process-explorer
• Chạy với quyền Administrator.
• Nhấn Ctrl+F để mở hộp thoại Find Handle or DLL.
• Gõ tên file. Mọi tiến trình đang giữ file đó sẽ hiện ra trong danh sách.
• Double-click vào mục đó → nhấn chuột phải vào handle → chọn Close Handle.

Close Handle giải phóng khóa mà không cần kill toàn bộ tiến trình. Rất tiện khi tiến trình đang khóa file là một luồng nền bên trong một service mà bạn không muốn restart.

Cách 3: Handle.exe (CLI, có thể dùng trong script)

Cũng từ Sysinternals. Chạy trong PowerShell hoặc CMD, lý tưởng cho script và phiên làm việc từ xa.

# Download: https://learn.microsoft.com/sysinternals/downloads/handle
# Chạy với quyền Administrator
handle.exe C:\path\to\locked\file.txt

Kết quả trả về dạng:

node.exe        pid: 14832  type: File  C:\path\to\locked\file.txt
java.exe        pid: 9120   type: File  C:\path\to\locked\file.txt

Đóng một handle cụ thể bằng hex ID:

handle.exe -c 1A4 -p 14832 -y

Cờ -y bỏ qua bước xác nhận. Hex handle ID lấy từ cột đầu tiên của kết quả trước đó.

Cách 4: PowerShell (không cần công cụ bên thứ ba)

Không cần Sysinternals — nhưng cách này chỉ xác định được tiến trình nào đang sở hữu file. Bạn không thể đóng từng handle riêng lẻ theo cách này.

$lockedFile = "C:\path\to\locked\file.txt"

Get-Process | ForEach-Object {
    $proc = $_
    try {
        $proc.Modules | Where-Object { $_.FileName -eq $lockedFile } | ForEach-Object {
            [PSCustomObject]@{ PID = $proc.Id; Name = $proc.Name; File = $_.FileName }
        }
    } catch { }
} | Format-Table -AutoSize

Cách này bắt được các khóa ở cấp DLL. Với các file handle thông thường trên network share, openfiles là một lựa chọn khác:

# Bật trước (cần khởi động lại):
openfiles /local on

# Sau đó truy vấn:
openfiles /query /fo table | findstr /i "filename.txt"

Thủ phạm thường gặp

• Antivirus / Windows Defender — quét file ngay khi vừa được ghi xuống. Cực kỳ phổ biến trong quá trình build và deploy. Thêm thư mục dự án của bạn vào danh sách ngoại lệ.
• Windows Search indexer (SearchIndexer.exe) — nhảy vào file mới ngay lập tức. Tắt indexing trên thư mục dev và build.
• Node.js / webpack watch mode — giữ handle trên mọi file trong cây thư mục được theo dõi. Tất cả đấy.
• Tiến trình Java — JVM khóa các file .jar và file tạm.
• IIS / w3wp.exe — khóa DLL trong thư mục ứng dụng. Dừng app pool trước khi deploy.
• Explorer.exe — quá trình tạo thumbnail có thể khóa file ảnh và video.
• VS Code — giữ handle trên các file workspace và git object khi dự án đang mở.

Giải pháp theo từng tình huống

Tình huống: Build/deploy thất bại vì file .dll hoặc .exe đang bị khóa

# Dừng IIS app pool trước
Import-Module WebAdministration
Stop-WebAppPool -Name "MyAppPool"

# Thực hiện deploy...

# Khởi động lại
Start-WebAppPool -Name "MyAppPool"

Hoặc dừng toàn bộ dịch vụ IIS trong lúc deploy:

iisreset /stop
# ... deploy ...
iisreset /start

Tình huống: Không xóa được file, không biết tiến trình nào đang khóa

# 1. Tìm PID bằng handle.exe
handle.exe locked-file.log

# 2. Kill tiến trình (nếu an toàn)
Stop-Process -Id 14832 -Force

# 3. Xóa file
Remove-Item locked-file.log

Tình huống: Đổi tên/di chuyển file thất bại trong script

Đôi khi khóa chỉ tồn tại trong vài mili giây — chẳng hạn antivirus vừa quét xong. Một vòng lặp retry xử lý việc này gọn gàng:

$maxRetries = 5
$retryDelay = 1  # seconds
$attempt = 0

while ($attempt -lt $maxRetries) {
    try {
        Move-Item -Path "source.tmp" -Destination "output.txt" -Force -ErrorAction Stop
        Write-Host "Moved successfully"
        break
    } catch {
        $attempt++
        Write-Warning "Attempt $attempt failed: $($_.Exception.Message)"
        Start-Sleep -Seconds $retryDelay
    }
}

if ($attempt -eq $maxRetries) {
    Write-Error "Failed to move file after $maxRetries attempts"
}

Tình huống: Antivirus là thủ phạm

Vào Windows Security → Virus & threat protection → Manage settings → Exclusions, rồi thêm thư mục build output. Cũng có thể dùng PowerShell:

Add-MpPreference -ExclusionPath "C:\projects\myapp\dist"
Add-MpPreference -ExclusionPath "C:\projects\myapp\node_modules"

Xác nhận đã sửa xong

Sau khi giải phóng khóa, kiểm tra xem có còn gì đang giữ file không:

handle.exe C:\path\to\file.txt
# Kết quả mong đợi:
# No matching handles found.

Thử lại thao tác ban đầu. Nếu lỗi xuất hiện trở lại ngay lập tức, tiến trình đó đã giành lại khóa. Đóng handle là chưa đủ — bạn cần dừng hẳn tiến trình đó.

Những điều cần ghi nhớ

• Resource Monitor đã có sẵn trên máy bạn. Dùng nó trước khi tải thêm bất cứ thứ gì.
• Giữ Handle.exe trong C:\tools\ thường trực. Chỉ cần một lần deploy gặp sự cố lúc 2 giờ sáng là bạn thấy ngay giá trị của nó.
• Windows Defender âm thầm phá vỡ build pipeline trên máy dev và CI agent. Thêm exclusion cho thư mục build output — chỉ mất 30 giây mà tiết kiệm được hàng giờ mò mẫm.
• Đóng handle qua Process Explorer hoặc Handle.exe có thể làm crash tiến trình chủ sở hữu. Ổn nếu chỉ mở khóa một lần; đừng tự động hóa điều này trong môi trường production nếu bạn chưa hiểu tiến trình đó đang làm gì.
• Nếu bạn kiểm soát được code ghi file: đặt FileShare tường minh và luôn đóng stream trong khối finally hoặc câu lệnh using. Hầu hết lỗi file-lock trong code tự viết đều bắt nguồn từ một stream bị bỏ mở sau khi có exception.