File in Use: The Action Can't Be Completed

The message “The action can’t be completed because the file is open in another program” is not a permission error. It is a sharing violation. A process has opened a handle to the file, and the sharing mode it used when opening the handle does not permit the operation being attempted. Windows enforces this at the file-system layer: before a delete, rename, or move can proceed, every existing handle to the file must have been opened with a sharing mode that allows it. If any handle was opened without FILE_SHARE_DELETE, the delete fails with ERROR_SHARING_VIOLATION, which Explorer renders as the message above.

The distinction matters because the repair is different. An access-denied error (“You need permission to perform this action”) is evaluated against the security descriptor: the access check compares the caller’s token, including group membership and integrity level, against the discretionary access control list on the object. A sharing violation is evaluated against the open handle table: it does not care who the caller is, only how the existing handles were opened. Taking ownership changes the security descriptor and has no effect on a sharing violation. It is the wrong tool for this error and, applied to a system folder, it is a change that outlasts the problem it was meant to solve.

Confirm it is a sharing violation, not access denied

Before doing anything, read the exact wording. The two errors are visually similar and lead to different repairs.

If the message names a program (“open in Microsoft Word”), the handle is held by that process. If it does not name one, the holder is a background process: an indexer, an antivirus scanner, a sync client, or Explorer itself.

Find the process holding the handle

Resource Monitor is the built-in tool for this. It enumerates handles by process and lets you search them by file name.

1. Open Resource Monitor: press Win+R, type resmon, press Enter.
2. Select the CPU tab.
3. In the Associated Handles section, type the file name into the search box.
4. The Image column shows the process name; the PID column shows the process ID.

If the search returns nothing, the handle may be held by a process running under another user account or by a kernel component. Run Resource Monitor elevated (right-click, Run as administrator) and search again.

Once the PID is known, identify the process before acting:

tasklist /FI "PID eq 1234"

The output lists the image name, PID, session, and memory use for that PID. Confirm the image name matches what Resource Monitor reported. If it does not, the PID has been reused since the search and the handle has already been released.

To close a process that is holding a handle, use Task Manager or:

taskkill /PID 1234

This terminates the process. Unsaved work in that process is lost. For a document editor, save from within the application first; for a sync client, let it finish its current upload or download before terminating it, or the partial transfer is left on disk.

Explorer’s own handles

The most common holder that does not name itself is Explorer. The preview pane and the thumbnail cache both open handles to files in the folder being viewed. A file that cannot be deleted while its folder is open in Explorer, but deletes normally from a command prompt, is being held by Explorer’s preview handler.

To release it, close the preview pane (View > Preview pane), switch the folder view to Details or List so thumbnails are not generated, or close the Explorer window entirely and retry. If the file is a media file or an Office document, the preview handler registered for that type is the specific holder; disabling the preview pane for that folder is sufficient.

Antivirus and sync clients

Real-time antivirus scanners open files with a sharing mode that permits reading but not deletion, so a scan in progress blocks a delete. The handle is released when the scan completes. Waiting, or pausing real-time protection briefly, releases it. Do not disable real-time protection permanently to work around this; the correct fix is to let the scan finish or to exclude the specific folder if the scanner is repeatedly scanning a file it should not.

Cloud sync clients (OneDrive, Dropbox, Google Drive) hold handles to files they are uploading, downloading, or have pinned for offline use. The handle is released when the transfer finishes. Pausing sync from the client’s own menu lets the current transfer stop without terminating the client.

A file open on another machine

If the file is on a shared folder, the holder may be a session on another computer. The handle is not visible in Resource Monitor on the local machine because it is held by the Server service on the machine hosting the share.

On the host, open Computer Management (compmgmt.msc), then System Tools > Shared Folders > Open Files. The list shows every file currently open through a share, the user, and the number of open handles. To close a specific handle, right-click the entry and choose Close Open File. This forcibly closes the handle; the remote application will see the file as disconnected and may lose unsaved changes. Confirm with the user before doing it.

To see the same information from a command prompt on the host:

openfiles /query /fo table

The output lists the opened file, the accessing user, and the lock count. Files opened through a share are listed without extra setup. Files opened locally are listed only after openfiles /local on and a restart, a setting that is off by default because it costs performance.

Why forcing the handle closed can corrupt the file

Closing a handle by terminating the process or by using Close Open File does not give the application a chance to flush its buffers. A document editor that has written changes to a temporary file and not yet renamed it into place will leave the original unchanged and the temporary file orphaned; a database or mail client that has written part of a transaction will leave the file in a state its recovery logic must repair on next open. The sharing violation exists precisely to prevent this. Treat termination as a last resort and prefer asking the holding application to close the file through its own interface.

What people get wrong

The natural response to “access denied” and “file in use” is the same: take ownership of the file and grant Full Control. This is a natural mistake because the two errors look alike, both appear when an operation is refused, and ownership is the fix that works for the permission case. It is also the fix most often repeated in forum answers, because it does appear to work when the holding process happens to release the handle at the same time.

On a system folder, taking ownership is actively harmful. Files under C:\Windows, C:\Program Files, and C:\ProgramData are protected by a combination of ACLs and, for some, by Windows Resource Protection. Changing the owner to the current user and granting Full Control can break the trust relationship the servicing stack relies on, causing future updates to fail or the component store to report corruption. The change persists after the original problem is resolved and is not undone by a reboot. The correct repair for a sharing violation never involves the security descriptor.

A second common error is to assume the file is locked by the application whose name appears in the folder. The holder is frequently a background process: the search indexer, the thumbnail cache, a backup agent, or a scanner. Resource Monitor’s Associated Handles search is the reliable way to identify it; guessing from the file type is not.

If the file still will not delete

If no handle appears in Resource Monitor, even when it runs elevated, restart the machine and delete the file before opening the program that normally uses it. A restart closes every handle, including those held by services, so a file that is still refused afterwards is held by something that starts with Windows.

If the volume itself reports errors, run a read-only check first:

chkdsk C: /scan

The scan reports file-system inconsistencies without modifying the volume. If it reports errors, schedule a repair with chkdsk C: /spotfix at the next restart; the repair can lose data in damaged sectors, so back up the volume first if the data matters.

A file that cannot be deleted even after all handles are released, and that returns a sharing violation from a command prompt with no process holding it, is usually held by a filter driver (antivirus, encryption, backup). Running fltmc filters from an elevated prompt lists the loaded file-system filter drivers, which shows which products have one installed; the repair is to update or remove the driver, not to change permissions on the file.