| Previous | Next |
| SEC_I_NO_RENEGOTIATION | SEC_I_CONTINUE_NEEDED_MESSAGE_OK |
SEC_I_MESSAGE_FRAGMENT
SSPI returned only a fragment of the message
SEC_I_MESSAGE_FRAGMENT is HRESULT 590692 (0x00090364) from winerror.h. AllStat describes it as “The returned buffer is only a fragment of the message; More fragments need to be returned.” The severity bit indicates a nonfailure result, but the value carries a specific condition that must not be collapsed into plain S_OK.
In the SSPI authentication or message-protection state machine, this result means that the returned buffer is only a fragment of the message; More fragments need to be returned. The application should preserve it until it has validated the exact condition represented by this return value.
Where the status is encountered
- InitializeSecurityContext or AcceptSecurityContext loops; log the exact method and object state instead of interpreting the constant outside that contract.
- Schannel or another security package; log the exact method and object state instead of interpreting the constant outside that contract.
- Message signing, fragmentation, or asynchronous SSPI processing; log the exact method and object state instead of interpreting the constant outside that contract.
Because it is informational, a language binding may expose it as success and hide the symbolic distinction. Keep the original HRESULT available until the code-specific branch has run.
Evidence and telemetry
- preserve fragment length and offset.
- preserve expected framing or total length.
- preserve SecBuffer types.
- preserve conversation and sequence identifiers.
- preserve assembly timeout and maximum size.
Also record sec_i_message_fragment_operation, sec_i_message_fragment_state_before, sec_i_message_fragment_state_after, UTC time, process and thread identifiers, component version, and a correlation ID. Use redacted telemetry for it, retaining only the stable technical identifiers that distinguish the operation.
What must be true before accepting it
Verify that the caller accumulates fragments according to the package framing contract without parsing incomplete data as a full token. The documented condition must be demonstrated so it is not mistaken for an unrelated success state.
Any state transition preceding it must be included in rollback, continuation, and retry planning.
Correct handling and recovery
Retain the fragment, obtain additional input or output, and call the documented SSPI routine again. Enforce size and timeout limits while assembling the complete message.
Retry it only when a documented input or state has changed. Use the code-specific next action for it; avoid treating all informational HRESULT values as retry signals.
Difference from nearby results
It must be distinguished from ordinary S_OK and from failure-severity values in the same API family; its documented state changes control the next action.
Comparing it with related statuses protects the caller from applying failure recovery to normal state.
Practical scenario
A datagram security handshake yields one token fragment. The transport stores it with the conversation ID, obtains the remaining fragment, and only then advances the handshake.
A regression test should reproduce it, assert the relevant outputs and state, then change only the decisive condition and verify the expected neighboring result or ordinary completion.
References
- Microsoft: SSPI status codes — official Microsoft material used to interpret it.
- Microsoft: SSPI context semantics
- Microsoft: InitializeSecurityContext
- Microsoft: DecryptMessage
- Microsoft: HRESULT values
Looking for a different code? Search another status or error code.