| Previous | Next |
| ERROR_TIERING_CANNOT_PIN_OBJECT | ERROR_NOT_A_TIERED_VOLUME |
ERROR_TIERING_FILE_IS_NOT_PINNED
Why this is narrower than a generic disk error: tiering file is not pinned
Windows returns ERROR_TIERING_FILE_IS_NOT_PINNED, value 0x80830008, at the tiering boundary. It means that an unpin or pin-state query targeted a file that has no explicit tier assignment for it. Preserve the exact handle and generation of file-to-tier placement metadata for the addressed volume before any rescan changes the evidence.
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 while diagnosing this result. This object model determines which identifiers, counts and ownership state are meaningful for it.
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.
Storage facts that change the diagnosis
| Storage diagnostic field | Value |
|---|---|
| Closest comparison | ERROR_TIERING_CANNOT_PIN_OBJECT |
| Owning object | file-to-tier placement metadata for the addressed volume |
| Rejected invariant | an unpin or pin-state query targeted a file that has no explicit tier assignment |
| 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 | apply the operation to a regular file on a verified tiered volume, then compare with the original object type and pin state |
Do not overwrite this result with a close, detach or rollback error. Preserve the causal order so the original storage contract remains visible.
A/B test for this HRESULT
- serialize the failing request and the enumeration from which its identifiers came.
- 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.
- Repeat the operation using this controlled change: apply the operation to a regular file on a verified tiered volume, then compare with the original object type and pin state.
- Close and reacquire the relevant objects, then run once more to test lifecycle correctness after this result.
Use ERROR_TIERING_CANNOT_PIN_OBJECT as the nearest comparison. It is specific to an unpin or pin-state query targeted a file that has no explicit tier assignment; the neighboring result belongs to another validation or lifecycle branch for it. Keeping both names prevents a generic storage label from hiding the actual owner.
Mechanism-specific note
The file can still reside on a tier due to heat-based optimization even though it has no explicit pin. Query desired placement separately from current physical placement. An unpin workflow should treat this state as idempotent rather than moving data or inventing a pin record to remove while diagnosing it.
Corrective action and regression check
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 while diagnosing it. After correcting it, reopen the pack, volume, tier, snapshot or virtual disk so no cached generation participates in the validation run.
- The original request now reaches success or a documented later status with the intended layout and access mode.
- A new enumeration reports internally consistent IDs, counts, geometry and ownership for the object corrected after it.
- The passing state survives the lifecycle transition relevant to it, such as reopen, remount, owner change or detach/attach.
- The application still distinguishes it from
ERROR_TIERING_CANNOT_PIN_OBJECTand has no unbounded retry loop.
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 for it.
Technical references
- Microsoft: MSFT_FileStorageTier class — primary API or object-model reference for the boundary.
- Microsoft: Set method of MSFT_FileStorageTier — use this source to verify tiering state and parameters for it.
- Microsoft: Optimize-Volume — documents the supported management path relevant to it.
- Microsoft: fsutil tiering — defines the tiering objects used to interpret it.
Looking for a different code? Search another status or error code.