When an API routine in a server DLL is called from a client, the mechanism is that of sending sending a message and waiting for a reply (or at least for news that a reply is pending or is never coming). On the server side, the API routine is given the address of the received CSR_API_MSG as its input. This CSR_API_MSG is also ordinarily an output of the API routine in that it gets sent back to the client as the reply, at least with its ReturnValue set to the return value of the API routine, if not also with changes that were made by the API routine. The CSR_REPLY_STATUS enumeration is an extra output that is just for interpretation by CSRSRV for varying the ordinary reply.

The CSR_REPLY_STATUS is not documented. Neither is Microsoft known to have disclosed a C-language definition in any header from any publicly released kit for any sort of software development. It is not even known from type information in public symbol files. Microsoft’s only known public release of type information for the CSR_REPLY_STATUS enumeration is not in any symbol file but is instead in a statically linked library, named GDISRVL.LIB, that was published with the Device Driver Kit (DDK) for Windows NT 3.51. That type information surives in this library—especially since it has the detail of what would ordinarily be called private symbols—surely was an oversight, but published it is.

In the absence of an up-to-date public source, Microsoft’s name for one of the CSR_REPLY_STATUS values that are known to have ever been meaningful is unknown:

Value Symbol Versions
0 CsrReplyImmediate all
1 CsrReplyPending all
2 CsrClientDied all
3 unknown 5.0 and higher

The default is CsrReplyImmediate in two senses. First, the CSR_REPLY_STATUS whose address is given to the API routine is set to CsrReplyImmediate before calling the routine, such that it is the action to take if the routine does not explicitly say different. Second, an undefined value on return from the call is treated as CsrReplyImmediate.

The default behaviour is that the received CSR_API_MSG, now with whatever changes were made by the API routine and with its ReturnValue set from the return value of the API routine, is returned to the client as the reply. If the message came with a capture buffer in shared memory, the server itself and the API routine will have worked from a copy that the server captured to its own memory. This, with changes made by the API routine, is all copied back. Case 3 is a simplification that avoids the sight expense of a reply when none is wanted. The CSR_API_MSG is not returned, but changes to the capture buffer are.