| Previous | Next |
| ERROR_RECEIVE_EXPEDITED | ERROR_EVENT_DONE |
ERROR_RECEIVE_PARTIAL_EXPEDITED
What ERROR_RECEIVE_PARTIAL_EXPEDITED means
A transport delivered only part of an expedited data indication. In practical terms, this status belongs to fragmented expedited transport data: urgent or prioritized data requires additional receives before the expedited unit is complete.
Typical causes
- The expedited payload exceeds the supplied buffer
- The transport split the indication across multiple completions
- The client consumed only part of the available urgent data
How to investigate
- Track expedited state separately from normal receive state
- Preserve ordering and completion flags for the urgent unit
- Exercise tests where expedited data is fragmented at every possible boundary
Developer guidance
The receiver must combine two concerns: partial delivery and expedited semantics. Losing either flag can corrupt protocol interpretation.
Operational interpretation
When ERROR_RECEIVE_PARTIAL_EXPEDITED appears, first determine whether the operation actually failed, completed with an informational condition, or transferred work to another component. Record the API name, returned value, affected process or object, and the immediately preceding event. For this code, the most useful boundary is the fragmented expedited transport data boundary; broad machine-wide remediation before that boundary is identified can hide the original evidence.
Example scenario
An incident begins when the expedited payload exceeds the supplied buffer. A responder investigating this result should not begin with a generic reboot that destroys the original context. A better first step is to track expedited state separately from normal receive state. That evidence connects it to its producing operation and reveals whether this particular result is repeatable, expected, or merely secondary.
Logging and telemetry
Telemetry for this Win32 error should preserve its numeric value, component version, process and thread identifiers, operation name, affected object or endpoint, elapsed time, and the first earlier failure in the same activity. Keep the result correlation identifier stable across callbacks so the status can be joined to the request that initiated this exact operation.
Recovery and validation
Apply recovery only after the responsible state has demonstrably changed. After changing that state, repeat one controlled this result scenario and verify both the returned status and the resulting system state. Absence of another log line is not sufficient: confirm that the intended fragmented expedited transport data action completed, that no resource remains pending, and that later cleanup does not produce a different secondary error.
References
Looking for a different code? Search another status or error code.