none
mstsc.exe always crash when the first rail channel data (Handshake PDU -TS_RAIL_ORDER_HANDSHAKE ) arrive. RRS feed

  • Question

  • I write my own RemoteApp server and use mstsc.exe as client.

    I have already added "Remote Programs Capability Set " and "Window List Capability Set " to Demand Active PDU in "Connection Sequence".

    After "Connection Sequence", mstsc.exe always crash when the first rail channel data (Handshake PDU -TS_RAIL_ORDER_HANDSHAKE ) arrive. 

    Does any implicit preparation exist to start a RAIL session?

    MessageBox of mstsc.exe crashed On Win2008R2:

    Unhandled exception at 0x000007feeb68c3c1 in mstsc.exe:0xC0000005:Access violation reading location 0x0000000000000010.

    • Edited by fowieojfow Monday, July 22, 2013 9:34 AM
    Monday, July 22, 2013 6:00 AM

Answers

  • Update to forum.

    I debugged the issue.  The RAIL server, in the [MS-RDPERP] 2.2.2.2.1 “Handshake PDU (TS_RAIL_ORDER_HANDSHAKE)” message was setting CHANNEL_FLAG_SHOW_PROTOCOL 0x00000010 in the [MS-RDPBCGR] 2.2.6.1.1 “Channel PDU Header (CHANNEL_PDU_HEADER)” Flags field (in addition to CHANNEL_FLAG_FIRST 0x00000001 and CHANNEL_FLAG_LAST 0x00000002).  The client (MSTSC) is not expecting CHANNEL_FLAG_SHOW_PROTOCOL 0x00000010.

    The server is likely setting this flag because in the client(MSTSC)-to-Server T.125:MCSConnectInitial TS_NET options ([MS-RDPBCGR] 2.2.1.3.4.1 “Channel Definition Structure (CHANNEL_DEF)”) we’re sending the server CHANNEL_OPTION_SHOW_PROTOCOL 0x00200000 for the “rail” channel.  However, the server MUST ignore this flag: “The value of this flag MUST be ignored by the server. […]”.


    Bryan S. Burgin Senior Escalation Engineer Microsoft Protocol Open Specifications Team

    Wednesday, July 31, 2013 10:32 PM
    Moderator

All replies

  • Hello fowieojfow,
                            Thank you for your inquiry about RDP protocols. One of the Open specifications team member will contact you shortly.

     
    Regards,
    Sreekanth Nadendla
    Microsoft Windows Open specifications

    Monday, July 22, 2013 2:21 PM
    Moderator
  • Hi fowieojfow,

    I can help you with this.  Can you send me mail at "dochelp (at) microsoft (dot) com".  There should be a Windows Error Report left behind, usually at C:\Users\<user>\AppData\Local\Microsoft\Windows\WER\ReportArchive or ReportQueue.  This will help us identify what's going on.  Did this happen just once, sometimes happen or can you reproduce this issue "at will"?


    Bryan S. Burgin Senior Escalation Engineer Microsoft Protocol Open Specifications Team

    Monday, July 22, 2013 4:55 PM
    Moderator
  • Hi Bryan

    I can reproduce this issue "at will".

    Mail was sent.

    Thanks for your help!

    Tuesday, July 23, 2013 2:52 AM
  • Thank you, I received the file.

    Bryan S. Burgin Senior Escalation Engineer Microsoft Protocol Open Specifications Team

    Tuesday, July 23, 2013 4:49 AM
    Moderator
  • Update to forum.

    I debugged the issue.  The RAIL server, in the [MS-RDPERP] 2.2.2.2.1 “Handshake PDU (TS_RAIL_ORDER_HANDSHAKE)” message was setting CHANNEL_FLAG_SHOW_PROTOCOL 0x00000010 in the [MS-RDPBCGR] 2.2.6.1.1 “Channel PDU Header (CHANNEL_PDU_HEADER)” Flags field (in addition to CHANNEL_FLAG_FIRST 0x00000001 and CHANNEL_FLAG_LAST 0x00000002).  The client (MSTSC) is not expecting CHANNEL_FLAG_SHOW_PROTOCOL 0x00000010.

    The server is likely setting this flag because in the client(MSTSC)-to-Server T.125:MCSConnectInitial TS_NET options ([MS-RDPBCGR] 2.2.1.3.4.1 “Channel Definition Structure (CHANNEL_DEF)”) we’re sending the server CHANNEL_OPTION_SHOW_PROTOCOL 0x00200000 for the “rail” channel.  However, the server MUST ignore this flag: “The value of this flag MUST be ignored by the server. […]”.


    Bryan S. Burgin Senior Escalation Engineer Microsoft Protocol Open Specifications Team

    Wednesday, July 31, 2013 10:32 PM
    Moderator