| Previous | Next |
| STATUS_RING_NEWLY_EMPTY | STATUS_OPLOCK_SWITCHED_TO_NEW_HANDLE |
STATUS_RING_SIGNAL_OPPOSITE_ENDPOINT
The return value carries an action: notify the other side
STATUS_RING_SIGNAL_OPPOSITE_ENDPOINT is unusual because the information result describes what the caller should do next. A boundary condition in the ring indicates that the opposite endpoint should be signalled. Treating the value as a fatal error can drop the notification and leave a peer sleeping even though shared state has changed.
VMBus is a documented example of a channel with two shared-memory ring buffers and an opposite endpoint. Microsoft KMCL APIs send packets through the VMBus ring, process packets received from the peer, and can wait for a response from that peer. Linux VMBus documentation separately describes ring memory and synthetic interrupt signalling. These sources explain why a ring implementation may separate “data operation succeeded” from “peer notification is required,” without proving that this NTSTATUS is VMBus-only.
When diagnosing a hang, record the status before it is translated to a Win32 error, the ring transition that produced it, the endpoint identifier, and the result of the actual signal operation. Ensure the caller publishes ring metadata before signalling. Also check that status-normalization code does not collapse this nonnegative NTSTATUS to plain success before the action bit has been consumed.
What to inspect
- Preserve the native NTSTATUS until the ring caller handles the signal action.
- Publish shared ring state before notifying the opposite endpoint.
- Trace both the decision to signal and the signal delivery result.
References
- Microsoft Open Specifications: NTSTATUS values
- Linux kernel: VMBus and SynIC signalling
- Microsoft WDK: VmbPacketSend
- Microsoft WDK: VmbChannelSendSynchronousRequest
- Microsoft: Using NTSTATUS values
Looking for a different code? Search another status or error code.