none
Questions on RPC return status RRS feed

  • Question

  • Few miscellaneous questions about RPC return status.

    1. For RPC's that return status like the 'long' returned by "long __stdcall EcDoRpcExt2([in, out, ref] CXH * pcxh, ...)" the return status is sent on the wire as the last 4 bytes of the MAPI stub data. I found this by checking packet trace decodes. Is this described anywhere in DCERPC or Microsoft specs? I looked but did not find anything.
    2. In MS-OXCRPC, the description of EcDoConnectEx, EcDoRpcExt2, etc say that 'the return value is implementation-specific or one of the protocol-defined error codes in the table below'. I guess the implementation-specific values will depend on the vendor implementing an Exchange server. Are the implementation-specific values defined by Microsoft listed somewhere for each Exchange RPC?
    3. In MS-OXCDATA, sections 2.4, 2.4.1 and 2.4.2 list error codes. Are these error codes returned only within ROPs in responses or can they also be returned as the RPC's return value (as described in #1 above)?
    4. When a server is busy, it can do one of 3 things:
      • Return nca_server_too_busy fault response
      • Fail by returning RPC_S_SERVER_TOO_BUSY (0x000006BB) return status (as described in #1)
      • Return RopBackoff (Exchange 2007 & 2010 only)
      Is it described somewhere which option the server should choose? I have seen Exchange 2007 return nca_server_too_busy fault.

    Thanks,

    Hari

    Wednesday, September 28, 2011 9:55 PM

Answers

  • Hi Hari, I will try to address each of your questions individually.

     

    1.       This functionality is covered in the C706 DCE 1.1 specification. In section 14.4 it states "If an operation returns a result, the representation of the result appears after all parameters in the output stream".

    2.       'Implementation-Specific' means that a 3rd party implementation of the Exchange Protocols could potentially return a custom value specific to that implementation. A complete list of the possible values defined by Microsoft can be found in MS-OXCDATA section 2.4 and subsections.

    3.       The values found in MS-OXCDATA section 2.4 and subsections are usually returned in the ROP success or failure response buffers. However, it is possible to see one of those as the ReturnValue for EcDoRpcExt2 as well.

    4.       Please take a look at MS-OXCROPS section 3.2.4.2 which describes the behavior which determines whether the server will return RopBackoff or RPC_S_SERVER_TOO_BUSY.


    Josh Curry (jcurry) | Escalation Engineer | US-CSS DSC Protocols Team
    Thursday, October 6, 2011 2:22 PM
    Moderator
  • Hi Hari, nca_server_too_busy and RPC_S_SERVER_TOO_BUSY are functionally equivalent. Take a look at the table in MS-RPCE section 3.1.1.5.5. That shows a mapping between the Win32 error codes and the status codes defined in the C706 specification.

     

    This is what is happening…

    1. Exchange Server returns RPC_S_Server_TOO_BUSY (0x000006BB).
    1. The RPC runtime on the server converts that to nca_server_too_busy (0x1C010014) before sending the data across the wire to the client.
    1. The RPC runtime on the client converts nca_server_too_busy back to RPC_S_SERVER_TOO_BUSY before passing the data back to the client application.
    1. The client sees RPC_S_SERVER_TOO_BUSY as the return value from the RPC method call.

     

    If you capture a network trace while also debugging on the client you should see nca_server_too_busy over the wire but the client app should see RPC_S_SERVER_TOO_BUSY.


    Josh Curry (jcurry) | Escalation Engineer | US-CSS DSC Protocols Team
    Wednesday, October 12, 2011 7:13 PM
    Moderator
  • Hi Hari, any Win32 error that is mapped to an RPC status code in the table in MS-RPCE section 3.1.1.5.5 will be converted to an RPC status code before being sent across the wire. If the Win32 error code can not be mapped it will be returned unchanged.


    Josh Curry (jcurry) | Escalation Engineer | US-CSS DSC Protocols Team
    Monday, October 17, 2011 6:26 PM
    Moderator

All replies

  • Hi Hari,

    Thanks for your questions.  One of the Open Specifications team will respond shortly to assist you.

    Best regards,
    Tom Jebo
    Escalation Engineer
    Microsoft Open Specifications

    Thursday, September 29, 2011 1:40 PM
  • Hi Hari, I am the engineer who will be working with you on this issue. I am currently researching the problem and will provide you with an update soon. Thank you for your patience.

     


    Josh Curry (jcurry) | Escalation Engineer | US-CSS DSC Protocols Team
    Friday, September 30, 2011 2:52 PM
    Moderator
  • Hi Hari, I will try to address each of your questions individually.

     

    1.       This functionality is covered in the C706 DCE 1.1 specification. In section 14.4 it states "If an operation returns a result, the representation of the result appears after all parameters in the output stream".

    2.       'Implementation-Specific' means that a 3rd party implementation of the Exchange Protocols could potentially return a custom value specific to that implementation. A complete list of the possible values defined by Microsoft can be found in MS-OXCDATA section 2.4 and subsections.

    3.       The values found in MS-OXCDATA section 2.4 and subsections are usually returned in the ROP success or failure response buffers. However, it is possible to see one of those as the ReturnValue for EcDoRpcExt2 as well.

    4.       Please take a look at MS-OXCROPS section 3.2.4.2 which describes the behavior which determines whether the server will return RopBackoff or RPC_S_SERVER_TOO_BUSY.


    Josh Curry (jcurry) | Escalation Engineer | US-CSS DSC Protocols Team
    Thursday, October 6, 2011 2:22 PM
    Moderator
  • Hi Josh,

    Thanks for digging up the info. For #4, I have seen Exchange 2007 return nca_server_too_busy fault. It could have returned RPC_S_SERVER_TOO_BUSY or RopBackoff (if it was a EcDoRpcExt2 request), so why did it chose to send a fault response?

    Thanks,

    Hari

    Friday, October 7, 2011 4:39 PM
  • Hi Hari, nca_server_too_busy and RPC_S_SERVER_TOO_BUSY are functionally equivalent. Take a look at the table in MS-RPCE section 3.1.1.5.5. That shows a mapping between the Win32 error codes and the status codes defined in the C706 specification.

     

    This is what is happening…

    1. Exchange Server returns RPC_S_Server_TOO_BUSY (0x000006BB).
    1. The RPC runtime on the server converts that to nca_server_too_busy (0x1C010014) before sending the data across the wire to the client.
    1. The RPC runtime on the client converts nca_server_too_busy back to RPC_S_SERVER_TOO_BUSY before passing the data back to the client application.
    1. The client sees RPC_S_SERVER_TOO_BUSY as the return value from the RPC method call.

     

    If you capture a network trace while also debugging on the client you should see nca_server_too_busy over the wire but the client app should see RPC_S_SERVER_TOO_BUSY.


    Josh Curry (jcurry) | Escalation Engineer | US-CSS DSC Protocols Team
    Wednesday, October 12, 2011 7:13 PM
    Moderator
  • Hi Josh,

    As a man in the middle, I'm interested in what happens on the wire (I don't write client applications), but it's interesting to know how the server & client runtime work. Is this true for failure return codes other than RPC_S_Server_TOO_BUSY? i.e. if an RPC returns failure on the server, does the server runtime always convert it into an equivalent fault response?

    If you were to implement an Exchange server equivalent, I guess you would be ok to follow any of the 3 ways listed previously to indicate the server is busy (except that for RopBackoff which you cannot send if the client does not support it).

    There is actually a 4th way to return busy - the server can return status code ServerBusy (0x480) in the response rop. I have seen e2k7 return this for FastTransferSourceGetBuffer.

    Thanks,

    Hari

    Thursday, October 13, 2011 11:01 PM
  • Hi Hari, any Win32 error that is mapped to an RPC status code in the table in MS-RPCE section 3.1.1.5.5 will be converted to an RPC status code before being sent across the wire. If the Win32 error code can not be mapped it will be returned unchanged.


    Josh Curry (jcurry) | Escalation Engineer | US-CSS DSC Protocols Team
    Monday, October 17, 2011 6:26 PM
    Moderator
  • Hi Josh,

    My question was more along the lines of the kind of response that Microsoft Exchange servers return upon failure:

    • Is a fault response always sent?
    • The 'long' return value from MAPI RPCs can be sent 'after all parameters in the output stream' as described in C706 DCE 1.1 specification, section 14.4. Does that ever happen? If so, I guess the client would simply return that status to the application (after possible conversion) & not even bother decoding the ROP output buffer - is that correct?

    Thanks,

    Hari

    Tuesday, October 18, 2011 6:23 PM
  • Hi Hari, would you mind e-mailing me at dochelp (at) microsoft (dot) com? I would like to take this discussion offline to get more details about your scenario and try to understand exactly what information you are looking for.

     

    Thanks.


    Josh Curry (jcurry) | Escalation Engineer | Open Specifications Support Team
    Friday, October 21, 2011 4:06 PM
    Moderator