What does HRESULT 0x801F001A (ERROR_FLT_VOLUME_ALREADY_MOUNTED) mean?

 
Previous Next
ERROR_FLT_NO_DEVICE_OBJECT ERROR_FLT_ALREADY_ENLISTED

ERROR_FLT_VOLUME_ALREADY_MOUNTED

The volume is already in the mounted state

ERROR_FLT_VOLUME_ALREADY_MOUNTED is the failure HRESULT 0x801F001A (signed decimal -2145452006, unsigned decimal 2149515290). The severity bit is 1, the facility field is 31 (FACILITY_FILTER_MANAGER), and the facility-specific code field is 0x001A.

AllStat records the Windows SDK message as “The specified volume is already mounted.”

This result describes the lifecycle state of a Filter Manager volume, not the presence of a particular minifilter instance. Microsoft defines a minifilter instance as one attachment of a filter at an altitude on a volume. A volume can be mounted while no instance of the caller is attached, and an instance can fail to attach for reasons that have nothing to do with mounting. Preserve that distinction before deciding which component is at fault.

Public contract and ownership limits

Microsoft publishes the symbolic value and message in the Filter Manager HRESULT table, but the public documentation does not identify one universal API whose documented return contract is this HRESULT. Therefore the code alone is not enough to name the caller, callback, or internal database transition. The first diagnostic fact must be the exact routine or control request that returned it and whether the value was observed in kernel mode, converted from an NTSTATUS value, or surfaced by a user-mode Filter Manager operation.

How this differs from an attached instance collision

  • ERROR_FLT_INSTANCE_NAME_COLLISION means an instance with the requested name already exists on the specified volume.
  • ERROR_FLT_INSTANCE_ALTITUDE_COLLISION identifies an occupied stack position for the requested altitude.
  • ERROR_FLT_FILTER_NOT_READY means the minifilter registered but did not start filtering.
  • ERROR_FLT_VOLUME_NOT_FOUND and ERROR_FLT_NO_DEVICE_OBJECT indicate that Filter Manager cannot resolve the requested volume object.
  • ERROR_FLT_VOLUME_ALREADY_MOUNTED instead says that the volume-level mount transition being requested is already complete.

Situations that can produce the state mismatch

  • two initialization paths issue the same volume-mount or registration transition after one path has already succeeded;
  • a retry is scheduled after a timeout even though the original request completed asynchronously;
  • a service restart or driver reload overlaps with a still-valid Filter Manager volume object from the previous control path;
  • mount, dismount, surprise-removal, or remount notifications are handled by a state machine that does not reject stale events;
  • test automation treats an idempotent “already mounted” state as a new mount failure without checking the current volume inventory.

Evidence to capture before changing the driver

  • the exact API, IOCTL, callback, or service operation that returned the HRESULT, including the original NTSTATUS when available;
  • the target volume identity: volume GUID path, device object, filesystem type, storage device, and Filter Manager volume pointer;
  • timestamps for the first successful mount transition and the later request that received this result;
  • the active Filter Manager frames and minifilter instances on the target volume, rather than only the drive letter;
  • PnP, filesystem mount, teardown, and service load/unload events surrounding the duplicate transition;
  • whether the caller reused a stale volume handle or opaque pointer after teardown had begun.

Diagnostic sequence

  • Confirm that the volume is genuinely mounted and accessible; do not infer this only from a cached drive-letter mapping.
  • Identify whether the requested operation was supposed to mount a Filter Manager volume, attach a minifilter instance, or merely enumerate an existing volume. Those are separate contracts.
  • Find the earlier operation that established the mounted state. A missing success log is not proof that no success occurred.
  • Review synchronization around mount-state transitions and make one owner responsible for each volume lifecycle event.
  • Check cleanup paths for stale references. Filter Manager objects must not be used after the relevant teardown path has started.
  • Reproduce with one load/mount path enabled. Then reintroduce service recovery, hot-plug, or explicit attach operations one at a time.

Retry and recovery

Blind immediate retry is normally inappropriate because the requested state already exists. If the higher-level operation is idempotent, the caller may verify that the mounted volume is the intended object and treat the existing state as completion. If a dismount or replacement was intended, wait for documented teardown completion and reacquire the volume identity before issuing a new request. Do not force a dismount, remove a filesystem, or detach unrelated minifilters merely to clear this HRESULT.

What to log in production

Record the operation name, original status value, volume GUID, filesystem type, device identity, caller state-machine generation, and whether the volume was already present in the caller’s own inventory. For minifilter diagnostics, add the filter name, instance name, altitude, and whether filtering had started. This data lets an engineer separate duplicate volume lifecycle work from a normal instance-attachment collision.

Practical scenario

A storage service receives a device-arrival notification and mounts the Filter Manager representation of the volume. A delayed retry from the same arrival event runs after the first request succeeded and receives ERROR_FLT_VOLUME_ALREADY_MOUNTED. The correct repair is to cancel or deduplicate the stale retry and accept the verified mounted state, not to unload every minifilter attached to the volume.

Official Microsoft references

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