HRESULT 0x8004537A (FSRM_E_FILE_IN_USE): meaning and diagnosis

Status / error code:

Category:

Constant name:

Source:

Facility:

Operating System:

Description:

FSRM could not access a selected file because another process currently holds an incompatible open handle.

Previous	Next
FSRM_E_CANNOT_DELETE_SYSTEM_PROPERTY	FSRM_E_ERROR_NOT_ENABLED

FSRM_E_FILE_IN_USE

FSRM_E_FILE_IN_USE is the failure HRESULT 0x8004537A (signed decimal -2147200134, unsigned decimal 2147767162). Its severity bit is 1, facility is 4 (FACILITY_ITF), and the facility-specific code field is 0x537A.

Another application is using the file

File Server Resource Manager selected a file for classification or a file-management operation but could not obtain the access required because another application is using it. The conflict is a live file-handle condition. It is not the same as an NTFS permission denial and does not by itself indicate that the file is damaged.

AllStat records the official condition as: “The file is being used by another application and cannot be accessed at this time.” The wording should be interpreted at this FSRM stage, not as a generic file-system or COM failure.

Where the failure boundary lies

The failure occurs after policy selection, when FSRM or one of its modules attempts to open, inspect, copy, modify, protect, or move the actual file. The exact required share mode depends on that operation. A reader that permits shared access may coexist with FSRM, while an editor, backup agent, scanner, or application using restrictive sharing can block it.

Likely causes to separate

A user application has the document open with a share mode that denies the access requested by FSRM.
Antivirus, backup, indexing, synchronization, or content-processing software temporarily holds the file.
A custom file-management action keeps a handle open while a later stage attempts to move or replace the same file.
The file is actively being uploaded, renamed, or transactionally updated when the scheduled job reaches it.

Evidence worth preserving

Log the file path, job or rule name, action stage, requested operation, and first related Win32 sharing error.
Identify the process and handle that owns the file at the failure time using supported handle or process-monitoring tools.
Preserve file size and last-write time to determine whether content was still changing during the attempted action.
Check the job report for whether only one file failed or a particular application-generated file set is consistently locked.

Diagnostic sequence

Reproduce with the application closed, then with it open, while keeping the FSRM job and file unchanged.
Separate a short-lived lock from a persistent service handle by observing the handle lifetime rather than guessing from the process name.
Review custom actions for handles that survive process launch, callbacks, or error paths.
Do not change ACLs unless an independent access-denied error shows that permissions are also wrong.

Retry and recovery

A retry is safe only after the conflicting handle is released and the file has reached a stable state. Use bounded backoff and revalidate selection conditions before moving or modifying the file, because its content or classification may have changed while it was locked. For persistent application files, schedule the job for a maintenance window or exclude the active path deliberately.

What this HRESULT does not establish

This HRESULT does not name the locking process and does not prove that every open handle is incompatible. It also does not guarantee that closing an interactive application releases background preview, sync, or antivirus handles.

Difference from nearby FSRM results

FSRM_E_CANNOT_CREATE_TEMP_COPY concerns failure to create a working copy and can occur even when the source file is not locked. FSRM_E_CANNOT_REMOVE_READONLY concerns an attribute transition rather than handle sharing.

Practical scenario

A continuous file-management job selects a spreadsheet seconds after a user saves it. The spreadsheet process still holds the file during its temporary-file replacement sequence, so FSRM receives this code. The job retries after the handle closes, rechecks the property condition, and then performs the action once.

Guidance for software and telemetry

Record sharing violations as per-file outcomes instead of failing the entire batch. Avoid infinite rapid retries, and make custom actions close source and destination handles before returning control to FSRM.

Official Microsoft references

Looking for a different code? Search another status or error code.