Details
-
Bug
-
Resolution: Incomplete
-
P4: Low
-
None
-
5.6.3, 5.8.0, 5.9.6
-
None
-
Citrix XenDesktop 7.17, Windows remote desktop with forwarded COM port
Description
What did you do?
- Connect to a windows remote desktop (Citrix XenDesktop to exact)
- Forward a local COM port to the remote desktop
- Map the forwarded COM port using
net use COM3 \\client\COM3
- Use the qt serial port example to connect to the COM port on the remote desktop
What did you expect to happen?
The COM port opens correctly and I'm able to communicate over the forwarded port
What happened instead?
The open call of the QSerialPort object fails. The error property indicates
QSerialPort::UnsupportedOperationError.
After investigating I tracked down the issue to be related to https://github.com/qt/qtserialport/blob/5.9.6/src/serialport/qserialport_win.cpp#L526
::ZeroMemory(&communicationOverlapped, sizeof(communicationOverlapped));
if (!::WaitCommEvent(handle, &triggeredEventMask, &communicationOverlapped)) {
The WaitCommEvent call fails with ERROR_INVALID_PARAMETER.
The documentation at https://docs.microsoft.com/en-us/windows/desktop/api/winbase/nf-winbase-waitcommevent states:
If hFile was opened with FILE_FLAG_OVERLAPPED and lpOverlapped is not NULL, WaitCommEvent is performed as an overlapped operation. In this case, the OVERLAPPED structure must contain a handle to a manual-reset event object (created by using the CreateEvent function)
The hEvent property of the OVERLAPPED structure does not contain a handle to such event.
The bugfix I came up with was introducing the following line after the ZeroMemory call:
communicationOverlapped.hEvent = CreateEvent(NULL, TRUE, FALSE, NULL);
However I'm uncertain if this fix is complete because according to the remarks of the documentation:
If the overlapped operation cannot be completed immediately, the function returns FALSE and the GetLastError function returns ERROR_IO_PENDING, indicating that the operation is executing in the background.
When this happens, the system sets the hEvent member of the OVERLAPPED structure to the not-signaled state before WaitCommEvent returns, and then it sets it to the signaled state when one of the specified events or an error occurs.The calling process can use one of the wait functions to determine the event object's state and then use the GetOverlappedResult function to determine the results of the WaitCommEvent operation.
GetOverlappedResult reports the success or failure of the operation, and the variable pointed to by the lpEvtMask parameter is set to indicate the event that occurred.
I would think that there might be a need to check the hEvent and I'm uncertain if any cleanup is needed for this either.
Do note that so far I've only been able to reproduce this issue on Citrix XenDesktop. On a normal windows desktop, a virtualized windows desktop or a normal remote windows desktop with forwarded COM ports I've not seen this issue.
I assume this is because the WaitCommEvent call returns immediately in all these cases and doesn't in the case of the XenDesktop.