Symptoms
When using a custom virtual channel after upgrading to version 9.230 or later of the Presentation Server Client for Windows, string data or binary string data being sent over the virtual channel appears to be incomplete or corrupted.
The return value for the ICA Client Object error code may also indicate an "Invalid Parameter."
Sending data of the binary data type is not affected.
More Information
The ICA Client Object is implemented as an ActiveX control (OLE Control Extension (OCX)), and can be used in any container supporting this type of embedded interface.
On the client side, virtual channel data can be sent by accessing the SendChannelData interface and read on the server by using the WFVirtualChannelRead function.
These application programming interfaces (APIs) are documented in the following software development kits (SDKs):
http://support.citrix.com/servlet/KbServlet/download/4195-102-10986/ICA_Client_Object_Guide.pdf
http://apps.citrix.com/cdn/sdk/default.asp#vc
Microsoft's SendChannelData interface allows the data to be sent in one of the following formats: binary data, string data, or binary string data.
Resolution
This change in behavior is a result of the security updates included in version 9.230 or later. In previous versions of the client, the "NUMBER DataLength count of bytes to send" was not enforced.
The string data type now verifies that the data length parameter describes the number of bytes, not characters, that the buffer parameter contains and which are to be sent. Microsoft always stores strings as wide characters, so the SendChannelData interface expects an even number of bytes because each character in a string is represented by two bytes. The interface checks that the length parameter is an even number.
For example, if you want to send the following string data with ActiveX:
“ABCDEF”
This is represented internally by Microsoft as:
NULL “A” NULL ”B” NULL ”C” NULL ”D” NULL ”E” NULL ”F”
The SendChannelData interface would receive the wide-character representation in the buffer argument and the length parameter should reflect the byte length of the wide string, which is 12, and not the string length, which is only 6 in the above example.
The binary string data type also verifies that each character in the string is also composed of two bytes for the Microsoft interface. The binary string data type must also verify that each binary code is represented by two characters in the string. Thus for the Microsoft interface, this means that it verifies that the binary string data length (which is in bytes, not characters) must be divisible by 4 bytes (2 bytes per character times 2 characters). Partial or incomplete binary string data indicates invalid binary string data.
For example, if you want to send four binary data bytes:
0xFE 0xED 0xBE 0xEF
This is represented in binary string data with the following string:
“FEEDBEEF”
Where each two characters represent a single binary byte. If you want to send this using ActiveX, this string is represented internally by Microsoft as
NULL “F” NULL ”E” NULL ”E” NULL ”D” NULL ”B” NULL ”E” NULL ”E” NULL ”F”
The SendChannelData interface would receive the wide-character representation in the buffer argument and the length parameter should reflect the byte length of the wide string, which is 16, and not the string length, which is only 8 in the above example.
Note: Netscape internally stores characters as single bytes, so the SendChannelData interface for the Netscape plug-in receives the string data as individual bytes, not wide characters.
