Hi folks! It’s been a long time since I wrote the
Terminal Services and Graphically Intensive Applications
post. Today’s post is a short one; we will be discussing a curious case of Event ID: 56 on Windows Server 2008/R2 with the Remote Desktop Services Role. The clients were being disconnected by the server and the following error was generated:
Log Name: System
Event ID: 56
The Terminal Server security layer detected an error in the protocol stream and has disconnected the client.
<Provider Name="TermDD" />
<TimeCreated SystemTime="" />
This happened in conditions of heavy traffic to the server along with large client packets (i.e. lot of input activity on the client). As a result, the data stream gets corrupted and the TS server disconnects the client.
To track this down, I looked at the binary data attached to the event. The last DWORD is the error code is converted to an HRESULT.
For example if you have the following binary data attached to the event…
You first have to reverse the byte order to get a readable error code. You don’t reverse the whole thing, you reverse each byte pair individually. So,
moves to the front, followed by
etc. After reversing you’ll get this:
To make it even messier, the
is actually a result of converting an NTSTATUS code into HRESULT, so we then have to replace it with
(Normally HRESULT would start with “8”). Thus, you need to replace “D” with “C”.
Finally we now have and NTSTATUS error of
You can look up this error code using something like Err.exe and and get
This most likely indicates that server was trying to send data to the client after the connection was broken. It does not tell us why the connection was broken. Additional codes might be more informative:
- STATUS_IO_TIMEOUT - the connection has timed out.
- STATUS_INVALID_LOGON_HOURS - The user account has time restrictions and may not be logged onto at this time.
- SEC_E_DECRYPT_FAILURE – the data on the wire got corrupted
To decipher the codes, you can download Err.exe from:
Another way to troubleshoot the error is more inclined towards the driver development community, which is to use Windows Software Trace Preprocessor (WPP) to trace a driver's operation; it enhances
WMI event tracing
by adding conventions and mechanisms that simplify tracing a driver's operation. It is an efficient mechanism for user-mode applications and kernel-mode drivers to log real-time binary messages. The logged messages can subsequently be converted to a human-readable trace of the driver's operation.