What does Windows error code 564 (ERROR_INVALID_LDT_DESCRIPTOR) mean?

Status / error code:		Category:

Constant name:
Source:		Operating System:
Description: An x86 LDT entry contains invalid fields or an unsupported descriptor combination.

Previous	Next
ERROR_INVALID_LDT_OFFSET	ERROR_TOO_MANY_THREADS

ERROR_INVALID_LDT_DESCRIPTOR

The user supplied an invalid descriptor when trying to set up LDT descriptors.

ERROR_INVALID_LDT_DESCRIPTOR is Windows system result 564 (0x00000234). Microsoft defines it as “The user supplied an invalid descriptor when trying to set up LDT descriptors.” The value should be captured immediately at the producing boundary because later diagnostics, cleanup, or retry code can overwrite a thread-local last-error value or collapse a richer native status.

How to classify the result

This result represents an x86 descriptor-content validation failure. The correct interpretation depends on the individual LDT_ENTRY fields, selector purpose, privilege assumptions, and target architecture.

The most important boundary for it is whether the operation reached a documented final state.

Where it can appear

This result can appear in legacy x86 process compatibility.
This result can appear in debugger-assisted descriptor restoration.
It can appear in an emulator or runtime configuring segmented-addressing state.

When it is found only in a log, preserve the logger, event provider, process, thread, and translation path.

Typical causes

base, limit, type, or present fields form an invalid descriptor.
reserved bits are nonzero.
the descriptor requests an unsupported privilege or system segment.
the caller copied a descriptor from a different architecture or process mode.
bitfield layout or endianness assumptions corrupted the packed entry.

These causes are starting points for it, not substitutes for evidence.

Evidence to preserve

Record selector number and raw descriptor bytes for it.
Record decoded base and effective limit for it.
Record type, privilege, present, granularity, and operand-size bits for it.
Record process architecture and compatibility mode for it.
Record first native diagnostic or debugger exception for it.

Also retain decimal 564, hexadecimal 0x00000234, UTC time, machine build, component version, and a correlation identifier.

Recovery and retry

The recovery objective for it is to Build a descriptor from documented fields rather than patching raw bytes, then verify the entry after the update through a supported inspection API.

Do not repeatedly submit the same descriptor. A retry is justified only after correcting a specific field and ensuring the target state was not partially modified.

Difference from related results

ERROR_INVALID_LDT_SIZE and ERROR_INVALID_LDT_OFFSET describe the range envelope. It means the range is acceptable but at least one entry is not.

Keep the original constant in telemetry rather than replacing it with a nearby result that seems more familiar.

Practical validation scenario

A compatibility runtime copies a packed compiler-specific bitfield into LDT_ENTRY. Comparing raw bytes with the SDK layout reveals a reserved bit set by the alternate packing rule; explicit field construction fixes the request.

A useful test report for it includes the failing call, exact input, state before the call, raw output, expected state, and observed state after recovery.

Telemetry and support fields

Record invalid_ldt_descriptor_operation for the producing API, callback, wait, driver, packaging phase, or service transition.
Record invalid_ldt_descriptor_target for the stable session, selector, device, pin, content, resource, service, or validation identity.
Record invalid_ldt_descriptor_state_before and invalid_ldt_descriptor_requested_state using explicit units and enum names.
Record invalid_ldt_descriptor_raw_status, the original result domain, and any later HRESULT or Win32 conversion.
Record invalid_ldt_descriptor_attempt, elapsed time, process and thread IDs, server or device instance, and correlation ID.

Alerting for it should reflect the classification above.

Developer and administrator guidance

Prefer SDK structures and static assertions over homemade bitfields. Security-sensitive code should reject descriptors with unexpected privilege or present-state combinations before calling the system.

Developers should preserve it at module boundaries and document whether ownership of buffers, handles, mutexes, callbacks, or transition contexts changes on return.

References

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