What does Windows error code 6639 (ERROR_LOG_CONTAINER_READ_FAILED) mean?

ERROR_LOG_CONTAINER_READ_FAILED

Log service encountered an error when attempting to read from a log container.

ERROR_LOG_CONTAINER_READ_FAILED belongs to Common Log File System (CLFS). 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 6639 (0x000019EF) in Common Log File System (CLFS). 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

• opening existing log records after service restart.
• scanning containers during recovery or archive validation.
• reading a container stored in an NTFS stream.
• replaying transaction records from a dedicated CLFS log.

State boundary to prove

This result applies to reading a CLFS log container 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 the selected container can be read consistently through the file system and storage stack. Use container path or stream name, read offset and requested byte count, and underlying NTSTATUS or storage error 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 container file or stream is inaccessible.
• a storage or file-system read failed.
• container metadata points to an invalid extent or offset.
• security or sharing state changed after the log was opened.
• media corruption prevents a complete read.

Diagnostic sequence

1. capture error 6639 immediately at the API boundary and record the operation that was attempted.
2. identify the exact owner of reading a CLFS log container, including object generation, server, path, session, replica, or client context.
3. collect container path or stream name before restarting a service or changing configuration.
4. compare read offset and requested byte count with the documented or observed precondition.
5. correlate underlying NTSTATUS or storage error with the owning application log, CLFS-related System events, storage events, and any transaction or recovery trace.
6. determine whether side effects occurred and verify recovery after changing one responsible condition.

Evidence to collect

• container path or stream name.
• read offset and requested byte count.
• underlying NTSTATUS or storage error.
• volume health and recent disk events.
• CLFS base-log metadata that selected the container.

Correlate it with the owning application log, CLFS-related System events, storage events, and any transaction or recovery trace. Keep the first detailed status even when a later wrapper translates it to error 6639; 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 preserve the affected log, verify the volume and container metadata, restore a known-good copy when required, and avoid deleting containers until recovery requirements are understood.

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 log_container_read_failed_api for the producing function or management operation.
• record log_container_read_failed_target for the file, log, session, replica, object, or server identity.
• record log_container_read_failed_state_before and log_container_read_failed_requested_transition.
• record log_container_read_failed_first_status for the earliest lower-level diagnostic.

For support escalation involving it, retain decimal 6639, hexadecimal 0x000019EF, 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, clfs clients can run in user mode or kernel mode, so the same win32 result may be returned through an application wrapper, a service, or a driver-facing management path.

Difference from nearby results

ERROR_LOG_CONTAINER_OPEN_FAILED occurs before a usable container handle exists; this code reports failure after the container was selected for reading.

Practical validation scenario

A transaction service restarts and cannot replay a specific container. The failing offset maps to a damaged disk extent, and restoring that container from the coordinated backup allows replay to continue without discarding later logs. 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 preserve the complete CLFS set—base log, containers, security metadata, and application checkpoint state—before repair. Developers should never delete or recreate a container merely because its path appears in the error; the owning recovery protocol determines whether that data is still required. Code that exposes it through RPC, JSON, REST, PowerShell, or another protocol should preserve the Win32 domain, decimal 6639, hexadecimal 0x000019EF, and original component diagnostic.

References

• Microsoft: Win32 system error range containing this code — official context relevant to it.
• Microsoft: Common Log File System — official context relevant to it.
• Microsoft: Creating a Log File — official context relevant to it.
• Microsoft: Introduction to CLFS — official context relevant to it.

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