What does Windows error code 592 (ERROR_DATA_NOT_ACCEPTED) mean?

ERROR_DATA_NOT_ACCEPTED

What this result means

ERROR_DATA_NOT_ACCEPTED is a Windows system result. This legacy TDI-oriented status describes a handoff failure between the network transport and its client. It often points to buffer ownership, receive-state, reentrancy, or teardown problems in a kernel networking component rather than to malformed remote data alone.

Likely causes

• the client had no receive capacity or returned an invalid acceptance length
• connection teardown raced with an incoming indication
• a filter or legacy driver mishandled buffer lifetime or callback context
• the protocol client rejected data because its state machine was out of sequence

Where this code is usually encountered

• A legacy TDI client rejects bytes during a receive indication.
• Teardown changes connection state while a transport callback is still in flight.
• A filter or protocol driver returns an acceptance length inconsistent with the supplied buffer.

Useful evidence

• indicated, accepted, and remaining byte counts
• connection state and teardown timestamps
• callback IRQL, thread, stack, and buffer ownership
• versions and filter order of all network drivers

Troubleshooting steps

1. Find the first receive indication that was only partially or not accepted.
2. Validate the client’s documented contract for ownership and continuation of unaccepted bytes.
3. Serialize teardown with in-flight callbacks and verify reference counts under stress.
4. Reproduce without third-party filters to isolate a protocol client from the transport stack.

Guidance for developers

TDI is obsolete; maintained drivers should migrate to WSK, WFP, or documented user-mode networking. Legacy code must bound queues, validate lengths, and hold connection and buffer references through callback completion.

Guidance for administrators

Collect a kernel trace or dump before changing adapter settings. Updating or removing the responsible legacy network component is more relevant than resetting TCP/IP.

How to interpret it correctly

The remote peer may have sent valid data. This result describes the local client’s inability or refusal to accept the indication.

Example failure pattern

A useful stress test combines high receive rate with connection cancellation and driver unload or filter detach. If accepted-byte counts change after teardown begins, or callbacks outlive their connection reference, the trace will show a local lifetime defect rather than a remote protocol violation.

Retry and recovery policy

Transport-level retransmission should not be triggered blindly by the client that rejected the indication. Restore a valid receive state first; otherwise retries increase queue pressure and widen the teardown race.

References

• Microsoft: System error codes 500–999
• Microsoft: System error codes