Site icon EfmSoft

What does Windows error code 6629 (ERROR_COULD_NOT_RESIZE_LOG) mean?

 
Previous Next
ERROR_LOG_FULL ERROR_LOG_MULTIPLEXED

ERROR_COULD_NOT_RESIZE_LOG

The log could not be set to the requested size.

Windows assigns decimal 6629 and hexadecimal 0x000019E5 to ERROR_COULD_NOT_RESIZE_LOG. The decisive subject is a Common Log File System log resize request; the value alone does not reveal which object, server, file, session, or transition failed.

The native Value is 6629 (0x000019E5). 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

State boundary to prove

This result applies to a Common Log File System log resize request 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 requested physical log size can be represented by the current container layout and log policy. Use current and requested log sizes, container count, container sizes, and container paths, and restart-area and base-log metadata 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

Diagnostic sequence

  1. capture error 6629 immediately at the API boundary and record the operation that was attempted.
  2. identify the exact owner of a Common Log File System log resize request, including object generation, server, path, session, replica, or client context.
  3. collect current and requested log sizes before restarting a service or changing configuration.
  4. compare container count, container sizes, and container paths with the documented or observed precondition.
  5. correlate restart-area and base-log metadata 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

Correlate this result 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 6629; 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 recalculate a supported size from current CLFS metadata, release unnecessary reservations, archive or advance the base log, and repeat the resize only after the blocking state changes.

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

For support escalation involving it, retain decimal 6629, hexadecimal 0x000019E5, 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_PINNED means reclamation is blocked by active records; this code instead reports that the requested resize itself could not be established.

Practical validation scenario

An administrator requests a smaller log while an application still pins records needed for recovery. Inspecting reservations and the base log shows that removing a container would discard required ranges, so the resize is deferred until the client advances its base sequence number. 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 6629, hexadecimal 0x000019E5, and original component diagnostic.

References


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

Exit mobile version