RDCMan 3.21: persistent state corruption for specific server/IP + login after RDG save/reload
Summary
With RDCMan 3.21, one specific RDP connection in an existing .rdg file appears to become unusable based on the server/IP + login combination.
The original server entry was already failing. Deleting and recreating that entry does not fix the problem permanently, even when:
- using a different display/server name;
- placing it in a new group;
- defining credentials directly on the server entry;
- or using the same credentials through a global credential profile.
The observed behavior is:
- Create a fresh server entry pointing to the same IP.
- Assign the affected account.
- Connect immediately: works.
- Reconnect several times: may still work.
- RDCMan appears to reuse a previously remembered certificate trust state, so no certificate prompt is necessarily shown at this stage.
- RDCMan saves the
.rdg file.
- Close and restart RDCMan.
- The same connection now fails.
- A certificate warning may reappear.
- After accepting it, the session may remain black for several seconds and then disconnect.
Creating another fresh entry only restores the connection temporarily, until the next:
save -> close RDCMan -> reopen RDG
Migration context
I have used RDCMan across multiple versions and upgraded progressively up to 3.21.
My .rdg files migrated transparently across these upgrades, with no apparent errors or manual rebuild required.
In general, the migration works very well: the large majority of existing groups, servers, credential profiles and historical connections still work correctly.
This issue appears very localized.
Important diagnostic point
This does not appear to be a general problem with the remote server itself or with RDP connectivity.
On the same target server, I already have other RDCMan server entries using:
- different domain accounts;
- different local accounts;
- existing migrated entries;
and those connections continue to work normally.
I also have many other servers in the same .rdg file using the same:
- groups;
- templates;
- global profiles;
- display settings;
- inheritance mechanisms;
- and even the same account / password / domain combinations;
without this problem.
In many cases, the only thing that differs is the server IP address.
This makes the issue look much more specific to a combination such as:
Server/IP + identity/login
rather than to the server, RDCMan group or global credential profile itself.
Local vs global credentials: same behavior
The issue does not seem to depend on how credentials are provided to RDCMan.
I reproduced it with:
- Logon Credentials defined directly on the server entry;
- and a global credential profile.
The same account / password / domain combination works normally with other server entries.
This gives the impression that some state associated with the endpoint/IP + identity is persisted or recalculated when the .rdg file is reloaded.
Deleting the credential profile or deleting/recreating the server entry does not appear to reliably remove that state.
Reproduction sequence
- Open the existing
.rdg file in RDCMan 3.21.
- Use the existing affected server entry -> connection fails.
- Delete the affected entry.
- Create a new server entry pointing to the same IP, optionally with a different name and in a new group.
- Assign the affected login, either directly or through a global profile.
- Connect immediately -> OK.
- Reconnect several times -> may still be OK.
- RDCMan appears to reuse previously remembered certificate trust, so no new certificate prompt is necessarily shown.
- Let RDCMan save the
.rdg file.
- Close RDCMan.
- Restart RDCMan and reload the same file.
- Connect to the same entry again.
- A certificate warning may now reappear.
- Click Connect anyway.
- The connection attempts to establish.
- Black screen or no visible desktop for several seconds.
- Disconnect.
Creating yet another fresh entry reproduces the same cycle.
RDP client event log
Log used:
Microsoft-Windows-TerminalServices-RDPClient/Operational
Example below is anonymized using 198.168.1.2 as the target IP.
During a failing attempt:
Event 1024
RDP ClientActiveX attempts to connect to server 198.168.1.2
Event 1028
Server supports SSL = supported
Event 1029
Base64(SHA256(UserName)) = ...
Event 226
RDPClient_SSL:
transition TsSslStateHandshakeInProgress -> TsSslStateDisconnecting
in response to TsSslEventHandshakeContinueFailed
Error code: 0x80004005
Event 1105
Multi-transport connection disconnected
Event 1026
RDP ClientActiveX disconnected
Reason = 263
A subsequent attempt then appears to establish the connection successfully:
Event 1028
Server supports SSL = supported
Event 1029
Base64(SHA256(UserName)) = ...
Event 1102
Client initiated multi-transport connection
Event 1103
Client established multi-transport connection
Event 1025
RDP ClientActiveX connected to server
Event 1402
Client uses hardware memory for frame buffer
Event 1401
Server uses RDP graphics protocol version 0xA0600
AVC available = 1
Then about six seconds later:
Event 1105
Multi-transport connection disconnected
Event 1026
RDP ClientActiveX disconnected
Reason = 1
So the second phase does reach the connected state before the final disconnect.
Certificate behavior
After reloading the .rdg file, RDCMan may display a warning similar to:
The identity of "198.168.1.2" cannot be verified.
- The certificate is not issued by a trusted certificate authority.
- The certificate name does not match the remote computer.
The warning itself is understandable because the connection is made by IP address.
What looks abnormal is the change in behavior before vs. after save/reload.
Before RDCMan is closed, it appears to correctly reuse a previously remembered certificate trust state, equivalent to having previously selected the option not to ask again.
After the .rdg file is reloaded, that trust state sometimes appears not to be applied in the same way.
This may be another indication that some connection/security state is not being restored consistently.
Possibly related symptom: Display Settings
I also see inconsistent behavior in Display Settings under RDCMan 3.21.
Values shown in the UI, especially:
Docked RD resizing
Undocked RD resizing
do not always match the behavior actually observed when connecting.
This may indicate a mismatch between:
- properties shown in the UI;
- properties serialized into the
.rdg file;
- and properties actually applied to the RDP ActiveX control after reload.
Working hypothesis
My current observation is that some persistent state seems to exist for a combination like:
IP/server + login
and becomes invalid after .rdg save/reload.
The following points make this look more like a persistent-state / serialization issue than a normal RDP problem:
- the original entry was already failing;
- deleting/recreating the entry does not fix it permanently;
- changing the display name or group does not help;
- server-local credentials and global credential profiles behave the same;
- the same account / password / domain combination works elsewhere;
- a freshly created entry works immediately;
- it may work several times before RDCMan is closed;
- the failure returns after save + reload;
- other accounts on the same server continue to work normally.
Possibly related issues
These issues look related to the same functional area in RDCMan 3.21, but I did not find one describing this specific behavior:
a specific IP + Login combination works on a fresh entry, then fails after saving and reloading the RDG, while other connections using the same server, the same credentials, or the same templates continue to work.
Thanks
I have tried to provide the most detailed and reproducible report I could, including the tests already performed and the client-side RDP event log, in the hope that it helps narrow this down.
Thank you very much for RDCMan. It remains an excellent tool and I use it extensively to manage a large number of remote connections.
Good luck with the investigation and fixes for this release, and a big thank you to the Sysinternals team for the work on this tool.
RDCMan 3.21: persistent state corruption for specific server/IP + login after RDG save/reload
Summary
With RDCMan 3.21, one specific RDP connection in an existing
.rdgfile appears to become unusable based on the server/IP + login combination.The original server entry was already failing. Deleting and recreating that entry does not fix the problem permanently, even when:
The observed behavior is:
.rdgfile.Creating another fresh entry only restores the connection temporarily, until the next:
Migration context
I have used RDCMan across multiple versions and upgraded progressively up to 3.21.
My
.rdgfiles migrated transparently across these upgrades, with no apparent errors or manual rebuild required.In general, the migration works very well: the large majority of existing groups, servers, credential profiles and historical connections still work correctly.
This issue appears very localized.
Important diagnostic point
This does not appear to be a general problem with the remote server itself or with RDP connectivity.
On the same target server, I already have other RDCMan server entries using:
and those connections continue to work normally.
I also have many other servers in the same
.rdgfile using the same:without this problem.
In many cases, the only thing that differs is the server IP address.
This makes the issue look much more specific to a combination such as:
rather than to the server, RDCMan group or global credential profile itself.
Local vs global credentials: same behavior
The issue does not seem to depend on how credentials are provided to RDCMan.
I reproduced it with:
The same account / password / domain combination works normally with other server entries.
This gives the impression that some state associated with the endpoint/IP + identity is persisted or recalculated when the
.rdgfile is reloaded.Deleting the credential profile or deleting/recreating the server entry does not appear to reliably remove that state.
Reproduction sequence
.rdgfile in RDCMan 3.21..rdgfile.Creating yet another fresh entry reproduces the same cycle.
RDP client event log
Log used:
Microsoft-Windows-TerminalServices-RDPClient/OperationalExample below is anonymized using
198.168.1.2as the target IP.During a failing attempt:
A subsequent attempt then appears to establish the connection successfully:
Then about six seconds later:
So the second phase does reach the connected state before the final disconnect.
Certificate behavior
After reloading the
.rdgfile, RDCMan may display a warning similar to:The warning itself is understandable because the connection is made by IP address.
What looks abnormal is the change in behavior before vs. after save/reload.
Before RDCMan is closed, it appears to correctly reuse a previously remembered certificate trust state, equivalent to having previously selected the option not to ask again.
After the
.rdgfile is reloaded, that trust state sometimes appears not to be applied in the same way.This may be another indication that some connection/security state is not being restored consistently.
Possibly related symptom: Display Settings
I also see inconsistent behavior in Display Settings under RDCMan 3.21.
Values shown in the UI, especially:
do not always match the behavior actually observed when connecting.
This may indicate a mismatch between:
.rdgfile;Working hypothesis
My current observation is that some persistent state seems to exist for a combination like:
and becomes invalid after
.rdgsave/reload.The following points make this look more like a persistent-state / serialization issue than a normal RDP problem:
Possibly related issues
These issues look related to the same functional area in RDCMan 3.21, but I did not find one describing this specific behavior:
Thanks
I have tried to provide the most detailed and reproducible report I could, including the tests already performed and the client-side RDP event log, in the hope that it helps narrow this down.
Thank you very much for RDCMan. It remains an excellent tool and I use it extensively to manage a large number of remote connections.
Good luck with the investigation and fixes for this release, and a big thank you to the Sysinternals team for the work on this tool.