What does Windows error code 6849 (ERROR_BAD_CLUSTERS) mean?

Previous	Next
ERROR_CANNOT_ABORT_TRANSACTIONS	ERROR_COMPRESSION_NOT_ALLOWED_IN_TRANSACTION

ERROR_BAD_CLUSTERS

The operation could not be completed due to bad clusters on disk.

Windows assigns decimal 6849 and hexadecimal 0x00001AC1 to ERROR_BAD_CLUSTERS. The decisive subject is an operation blocked by bad disk clusters; the value alone does not reveal which object, server, file, session, or transition failed.

The native Value is 6849 (0x00001AC1). Preserve this result immediately after the failing Windows call because later logging, cleanup, LDAP, RPC, or file operations can replace the last-error value.

Where the result appears

• reading or moving a file whose extents intersect damaged sectors.
• running volume maintenance.
• extending a file on degraded media.
• repairing a volume after hardware errors.

State boundary to prove

This result applies to an operation blocked by bad disk clusters and does not by itself prove that the entire server, directory, disk, session, or application is unavailable. The state boundary to prove for this Win32 error is whether all physical clusters required by the file or volume can be read, remapped, or replaced without losing required data. Use physical disk and volume identity, failing logical offsets or cluster numbers, and SMART, controller, and System log events as independent evidence. When evidence for this Win32 error disagrees, preserve timestamps and investigate the transition instead of selecting the most convenient value.

Likely causes

• the device reported uncorrectable sectors.
• previously marked bad clusters contain required data.
• media degradation exceeded controller recovery.
• a virtual disk or storage path returned persistent read errors.
• the file system cannot relocate data from a damaged extent.

Diagnostic sequence

1. capture error 6849 immediately at the API boundary and record the operation that was attempted.
2. identify the exact owner of an operation blocked by bad disk clusters, including object generation, server, path, session, replica, or client context.
3. collect physical disk and volume identity before restarting a service or changing configuration.
4. compare failing logical offsets or cluster numbers with the documented or observed precondition.
5. correlate SMART, controller, and System log 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

• physical disk and volume identity.
• failing logical offsets or cluster numbers.
• SMART, controller, and System log events.
• chkdsk output and bad-cluster map.
• backup or replica availability for affected files.

Correlate this result 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 6849; 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 stop unnecessary writes, copy recoverable data, run the supported volume and hardware diagnostics, replace failing media, and restore any unrecoverable files from backup.

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 bad_clusters_api for the producing function or management operation.
• record bad_clusters_target for the file, log, session, replica, object, or server identity.
• record bad_clusters_state_before and bad_clusters_requested_transition.
• record bad_clusters_first_status for the earliest lower-level diagnostic.

For support escalation involving it, retain decimal 6849, hexadecimal 0x00001AC1, 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_VOLUME_DIRTY signals that consistency checking is required; this code identifies clusters already known to be physically or persistently unreadable.

Practical validation scenario

A backup job repeatedly fails at the same file offset. Disk diagnostics confirm an uncorrectable sector, so the volume is evacuated and the file is restored from another replica. 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 6849, hexadecimal 0x00001AC1, 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.