| Previous | Next |
| ERROR_TIERING_NOT_SUPPORTED_ON_VOLUME | ERROR_TIERING_STORAGE_TIER_NOT_FOUND |
ERROR_TIERING_VOLUME_DISMOUNT_IN_PROGRESS
Identify the owner before touching the layout: tiering volume dismount in progress
ERROR_TIERING_VOLUME_DISMOUNT_IN_PROGRESS (0x80830002) is emitted by the tiering path when tier metadata was requested while the volume was leaving the mounted state and its tier-management context was being torn down. The deciding object for it is file-to-tier placement metadata for the addressed volume, so the first investigation belongs there rather than in a generic “disk failure” bucket.
Storage tiering operates above a tiered Storage Spaces virtual disk and records desired placement separately from normal file allocation. Optimization may move data according to heat, whereas pinning expresses an explicit placement preference for a supported file or volume object for it. This object model determines which identifiers, counts and ownership state are meaningful.
Diagnosis of this result should begin with the object model and generation current at the failure. A later successful enumeration may describe a replacement object and cannot retroactively validate the rejected request for it.
Minimum diagnostic set
| Storage diagnostic field | Value |
|---|---|
| Closest comparison | ERROR_TIERING_ALREADY_PROCESSING |
| Owning object | file-to-tier placement metadata for the addressed volume |
| Rejected invariant | tier metadata was requested while the volume was leaving the mounted state and its tier-management context was being torn down |
| Identity and generation | volume GUID path, storage-space and tier IDs, file ID plus file-system identity, cluster owner node, optimization job state and requested pin target |
| Narrow experiment | query the volume tier inventory and repeat the exact call on a known tiered Storage Spaces volume without changing the file or policy |
Keep this HRESULT as the primary result if rollback or cleanup reports another code; those later values describe recovery, not the first rejected invariant.
Reproduce without destructive cleanup
- serialize the failing request and the enumeration from which its identifiers came while diagnosing this result.
- Preserve volume GUID path, storage-space and tier IDs, file ID plus file-system identity, cluster owner node, optimization job state and requested pin target while every handle is still valid for it.
- Repeat the operation using this controlled change: query the volume tier inventory and repeat the exact call on a known tiered Storage Spaces volume without changing the file or policy.
- Close and reacquire the relevant objects, then run once more to test lifecycle correctness after this result.
Use ERROR_TIERING_ALREADY_PROCESSING as the nearest comparison. This result is specific to tier metadata was requested while the volume was leaving the mounted state and its tier-management context was being torn down; the neighboring result belongs to another validation or lifecycle branch. Keeping both names prevents a generic storage label from hiding the actual owner while diagnosing it.
Mechanism-specific note
Dismount invalidates the tier-management context and can race with background optimization. Capture mount-state transitions and the component initiating dismount while diagnosing it. Wait for remount and re-enumerate tiers; retaining the old volume or file handle across dismount is not a supported retry strategy.
Restore the contract
Re-enumerate the volume, its storage tiers and the file object on the owner node; serialize optimization jobs and apply pinning only to supported objects on a live tiered volume. The result repair is incomplete until a fresh enumeration and new handle observe the corrected state.
- the first retry uses newly enumerated identifiers rather than cached handles.
- The durable metadata or provider state agrees with the success returned after it.
- A second run after close/reopen does not recreate the rejected the condition.
- the nearby
ERROR_TIERING_ALREADY_PROCESSINGpath remains separately testable and separately logged.
Do not use it as a reason to edit dynamic-disk sectors, VHDX metadata, RCT sidecars or snapshot support files directly for it. Unsupported edits can turn a recoverable state mismatch into persistent corruption.
Technical references
- Microsoft: MSFT_FileStorageTier class — defines the tiering objects used to interpret it.
- Microsoft: Set method of MSFT_FileStorageTier — primary API or object-model reference for the boundary.
- Microsoft: Optimize-Volume — use this source to verify tiering state and parameters for it.
- Microsoft: fsutil tiering — documents the supported management path relevant to it.
Looking for a different code? Search another status or error code.