What does Windows error code 6851 (ERROR_VOLUME_DIRTY) mean?

Previous	Next
ERROR_COMPRESSION_NOT_ALLOWED_IN_TRANSACTION	ERROR_NO_LINK_TRACKING_IN_TRANSACTION

ERROR_VOLUME_DIRTY

The operation could not be completed because the volume is dirty. Please run chkdsk and try again.

ERROR_VOLUME_DIRTY belongs to Windows file-system and storage integrity handling. A diagnosis of this result must connect the condition to the producing API, current state, object identity, and first lower-level diagnostic.

This result is Win32 error 6851 (0x00001AC3) in Windows file-system and storage integrity handling. Interpret it at the call that produced it and use the system message above as the immediate condition rather than as a complete root cause.

Where the result appears

• mounting or servicing a volume after an unclean shutdown.
• performing an operation that requires a clean NTFS state.
• starting backup, resize, or repair work.
• accessing removable or virtual media after interrupted writes.

State boundary to prove

This result applies to an operation refused because the volume dirty bit is set and does not by itself prove that the entire server, directory, disk, session, or application is unavailable. The state boundary to prove for it is whether the file system has completed required consistency checking and cleared the dirty state. Use fsutil dirty query result, chkdsk scan or repair output, and System log disk and NTFS events as independent evidence. When evidence for it disagrees, preserve timestamps and investigate the transition instead of selecting the most convenient value.

Likely causes

• the system lost power during file-system updates.
• Windows detected metadata inconsistency.
• a previous chkdsk or repair did not complete.
• the storage path disappeared while writes were pending.
• the dirty bit was set for a scheduled consistency check.

Diagnostic sequence

1. capture error 6851 immediately at the API boundary and record the operation that was attempted.
2. identify the exact owner of an operation refused because the volume dirty bit is set, including object generation, server, path, session, replica, or client context.
3. collect fsutil dirty query result before restarting a service or changing configuration.
4. compare chkdsk scan or repair output with the documented or observed precondition.
5. correlate System log disk and NTFS events with the Windows System log, NTFS/ReFS events, storage-controller diagnostics, application integrity checks, and backup or replica logs.
6. determine whether side effects occurred and verify recovery after changing one responsible condition.

Evidence to collect

• fsutil dirty query result.
• chkdsk scan or repair output.
• System log disk and NTFS events.
• shutdown and storage-disconnect history.
• whether the volume is read-only, clustered, or in active use.

Correlate it with the Windows System log, NTFS/ReFS events, storage-controller diagnostics, application integrity checks, and backup or replica logs. Keep the first detailed status even when a later wrapper translates it to error 6851; the first status often distinguishes transport, authorization, storage, schema, state, and application-integrity causes that share the same final Win32 result.

Handling, retry, and recovery

The recovery objective is to schedule and complete the appropriate chkdsk mode, correct underlying storage faults, reboot when the volume cannot be repaired online, and verify that the dirty bit is cleared.

Retry it only after the recorded condition changes and completion state is known. Idempotent queries may be repeated after recovery, but mutations require a state check first; backoff cannot repair malformed input, corruption, missing structure, or policy rejection.

Telemetry and support fields

• record volume_dirty_api for the producing function or management operation.
• record volume_dirty_target for the file, log, session, replica, object, or server identity.
• record volume_dirty_state_before and volume_dirty_requested_transition.
• record volume_dirty_first_status for the earliest lower-level diagnostic.

For support escalation involving it, retain decimal 6851, hexadecimal 0x00001AC3, the API, UTC time, target identity, and first subsystem-specific status. Include the smallest reproducible request and evidence that distinguishes this condition from nearby codes. In the context of it, the code identifies a file-system result, but the decisive evidence often comes from the lower storage layer and from application-level validation of the affected data.

Difference from nearby results

ERROR_BAD_CLUSTERS identifies damaged allocation units; a dirty volume may be healthy physically but still require consistency verification.

Practical validation scenario

A maintenance tool refuses to resize a data volume after an unexpected host reset. An online scan identifies metadata work that requires an offline repair; after reboot and chkdsk, the dirty bit clears and resize succeeds. The negative test should preserve the responsible condition and reproduce it; the recovery test should change only the identified cause, repeat the same operation, and verify both success and the absence of an unintended partial side effect.

Developer and administrator guidance

Administrators handling it should prioritize data preservation and hardware evidence before repair. Developers should separate structural file-system success from application-level integrity, because a readable or repaired file can still be semantically incomplete. Code that exposes it through RPC, JSON, REST, PowerShell, or another protocol should preserve the Win32 domain, decimal 6851, hexadecimal 0x00001AC3, and original component diagnostic.

References

• Microsoft: Win32 system error range containing this code — official context relevant to it.
• Microsoft: chkdsk — official context relevant to it.
• Microsoft: fsutil dirty — official context relevant to it.
• Microsoft: Data Access and Storage API — official context relevant to it.

---

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