mirror of
https://github.com/1Remote/1Remote.git
synced 2026-04-25 13:36:03 +03:00
[GH-ISSUE #878] Fix RDP reconnection #2634
Labels
No labels
area-configuration
area-ct-app
area-ct-rdp
area-ct-remoteapp
area-ct-ssh
area-ct-vnc
area-launcher
area-list
area-tags
area-teamwork
bug
chore
dependencies
general-build/ci
general-performance
general-refactor
general-security
general-supportive
general-ux
meta-documentation
meta-enhancement
meta-enhancement
meta-feature
meta-help-wanted
meta-unknown-error
priority-hi
priority-low
pull-request
question
resolution-duplicate
resolution-invalid
resolution-wontfix
stale
task-put-off
task-still-considering
task-working-in-progress
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/1Remote#2634
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @itagagaki on GitHub (Mar 1, 2025).
Original GitHub issue: https://github.com/1Remote/1Remote/issues/878
Originally assigned to: @VShawn, @itagagaki on GitHub.
The session window closes or rarely crashes when the RDP session hangs.
I thought closing the window was a specification, but I think it was originally designed to reconnect automatically or was modified to do so. However, it still does not, and in some cases it crashes, so something is wrong. Could be a local problem, but needs to be investigated.
As for protocols other than RDP, I have not tried them yet.
@itagagaki commented on GitHub (Mar 1, 2025):
@VShawn
github.com/1Remote/1Remote@aa84184cdd/Ui/View/Host/ProtocolHosts/AxMsRdpClient09Host.cs (L143-L152)When I force my RDP host PC to sleep,
e.discReasonis 0x208 (no host), but_rdpClient?.ExtendedDisconnectReasonisExtendedDisconnectReasonCode.exDiscReasonNoInfo, so it was not reconnected in this block and disposed in the else block. I think it should be reconnected in this case as well, but can you recall why it dared not do so?@VShawn commented on GitHub (Mar 1, 2025):
There was no particular reason; at that time, I inferred that reconnect was not necessary based on the enum name.
@itagagaki commented on GitHub (Mar 1, 2025):
I got what
OnRdpClientDisconnecteddoes.Here we have three cases. Reconnect, display an error message and reconnect button, or close the window.
The conditions for switching (bifurcation) may need to be reviewed.
I couldn't find 0xb08 as a disconnect reason in the current Microsoft Learn, so the specification may have changed.
exDiscReasonNoInfomay occur when the RDP server goes to sleep, in which case it may be better to display a reconnect button instead of closing or auto-reconnecting.However, the comment in the code says that win2008 (Windows Server 2008?) will report
exDiscReasonNoInfoon logout. If the user has signed off, it would be better to close it, but that would be inconsistent with the above. Hmmm. I don't have the environment to try Windows Server, so I can't to investigate this.And I think
_retryCountshould be reset to 0 when a connection is made.@VShawn commented on GitHub (Mar 3, 2025):
Yes, win2008 = Windows Server 2008. And these are conclusions I reached after repeated testing several years ago.
I no longer have Windows Server 2008 now, so I am unable to test it either.
u are right.
@VShawn commented on GitHub (Mar 15, 2025):
here is the reference of e.discReason
https://learn.microsoft.com/en-us/windows/win32/termserv/imstscaxevents-ondisconnected
@itagagaki commented on GitHub (Apr 6, 2025):
If the RDP server works differently on Windows Server 2008, 2016, Windows 10, 11, etc., then I have no way to verify it. I'm stuck.
@VShawn commented on GitHub (Apr 7, 2025):
well You won't be able to complete all the TEST on your owm. recommended to focus on the server versions that you can test, and leave the rest aside :)
@github-actions[bot] commented on GitHub (May 8, 2025):
This issue is stale because it has been open for 30 days with no activity.
@itagagaki commented on GitHub (May 10, 2025):
I have tried several cases with the Windows 10 Pro. I could see the following 4 in
e.discReason.disconnectReasonRemoteByUser)disconnectReasonDNSLookupFailed)disconnectReasonSocketConnectFailed)disconnectReasonAtClientWinsockFDCLOSE)When user signed out it was 2.
Same for shutdown (makes sense since shutdown includes a sign-out step).
I think 1Remote should only close the session in this case, and reconnect in other cases.
@VShawn
The current code contains several conditional decisions. The history of this is not clear to me. If you recall, please let me know.
Also, why did you set 1Remote's reconnect process to disabled?
https://github.com/1Remote/1Remote/blame/81d19f150e671597cda2e24659bbdf28ad2e9489/Ui/View/Host/ProtocolHosts/AxMsRdpClient09Host.cs#L167
@VShawn commented on GitHub (May 11, 2025):
At that time, I tested the e.discReason on multiple systems (Windows 8, Windows 10, Windows Server 2000, Windows Server 2008, etc.) and found that they do not seem to return a consistent enumeration value when the user logs out, which led to the conditions as you see. Unfortunately, I no longer have enough servers to retest these systems.
I remember trying to get the auto reconnect feature to work properly but failed. https://github.com/1Remote/1Remote/issues/869 reported errors. I didn't have the time to resolve the problems then, so I disabled the feature.
@itagagaki commented on GitHub (May 12, 2025):
Done to fix reconnect logic.
Willing to submit PR after some testing, but it is blocked by #929.
The problem of random occasional hangs and crashes has not been resolved, so we need to investigate further. I will add it as a new issue.
@itagagaki commented on GitHub (May 15, 2025):
I pushed the modification of the process after RDP disconnection to my branch.
https://github.com/itagagaki/1Remote/tree/fix-rdp-reconnection
It should now reconnect as expected.
However, it is blocked by #930.
@github-actions[bot] commented on GitHub (Jun 15, 2025):
This issue is stale because it has been open for 30 days with no activity.
@itagagaki commented on GitHub (Jun 15, 2025):
Sorry, but I've been busy lately and haven't had a chance to investigate this issue yet.
@VShawn commented on GitHub (Jun 16, 2025):
it's ok, plz take care of your self friend. I believe our daily live is much more important than working on open-source projects.
@github-actions[bot] commented on GitHub (Jul 17, 2025):
This issue is stale because it has been open for 30 days with no activity.
@itagagaki commented on GitHub (Jul 19, 2025):
Experimental results on Windows 10
disconnectReason***exDiscReason***ByServer(3)ReplacedByOtherConnectionRemoteByUser(2)LogoffByUserRemoteByUser(2)LogoffByUserRemoteByUser(2)LogoffByUserRemoteByUser(2)LogoffByUserLocalNotError(1)NoInfoMaxReconnectAttemptsSocketConnectFailed(516)NoInfoEnableAutoReconnect:i:0AtClientWinsockFDCLOSE(2308)NoInfoMaxReconnectAttempts:i:0NoInfoBased on this result, we can conclude that 1Remote should attempt to reconnect when ExtendedDisconnectReason is
exDiscReasonNoInfo. However, according to the current source code, Windows Server 2008 returnsexDiscReasonNoInfowhen signing out too.Therefore, it would be better to close the window immediately when discReason is either
disconnectReasonRemoteByUser(2) ordisconnectReasonByServer(3), and to attempt to reconnect in all other cases.What would be better in the case of discReason is
disconnectReasonLocalNotError(1), in UX?@itagagaki commented on GitHub (Jul 26, 2025):
Let's attempt to reconnect in order to switch to an alternate host. The user can dismiss it if he/she wants to.
@itagagaki commented on GitHub (Jul 26, 2025):
I found a clue as to why the app freezes after RDP reconnecting.
The call to
Shawn.Utils.Wpf.RelayCommand.CanExecute(null)repeats indefinitely.@VShawn Do you have any advice on how to further investigate the cause?
@VShawn commented on GitHub (Jul 27, 2025):
The
CanExecutemethod is called by the WPF UI, e.g. a button refreshes its disabled state through the CanExecuteChanged event of its bound ICommand object. Honestly, I don't think it would cause the UI to freeze.We can temporarily remove all CanExecute methods to verify if they are the cause of the freeze.
If they are indeed causing the freeze, the most straightforward solution would be to eliminate the CanExecute for the corresponding command.
Then I checked, and there is only one instance of relaycommand used in the RDP, so if relaycommand is the issue, modifying this one instance should suffice.
Annd the
CanExecutecondition of this command just relate towhether the RDP is connected, and this status will change during reconnection.@itagagaki commented on GitHub (Jul 27, 2025):
@VShawn
The problem seems to be in this block. Commenting it out will at least the UI will prevent the UI from freezing.
github.com/1Remote/1Remote@90aad35337/Ui/View/Host/ProtocolHosts/AxMsRdpClient09Host.cs (L63-L68)Steps to reproduce:
@VShawn commented on GitHub (Jul 29, 2025):
I'm glad to hear that you've found the root block. We can start by removing it so that the reconnection feature can work properly.
I'm puzzled as to why it's causing the interface to freeze, as it performs well in another place where it's called.
It is likely that an error occurred in TcpHelper.TestConnectionAsync or FindFirstConnectableAddressAsync functions called within the GetCredential function.
I suspect that the error was caused by UI controls in FindFirstConnectableAddressAsync, so I have created a non-UI version of this function. Could you please test it for me since i failed to find the a net cable in my house now.
@itagagaki commented on GitHub (Aug 1, 2025):
The following log was obtained using the conventional
FindFirstConnectableAddressAsync. Since the host, crow, is offline, it connects to the alternative, aero.The result of replacing it with
WithoutUIversion is as follows. No connection was made, no window opened, and no error message appeared.@VShawn commented on GitHub (Aug 3, 2025):
okey it did works when i test it. but I test it by on/off my wifi..
I need to check why it failed
log said:
Task1 completed first. Cancelling remaining tasks.it means completedTaskIndex == 1, and the func has found that aero is connectable, then the func should return
return credentials[1].CloneMe();The logic seems to be correct....
I don't have any leads for now, willl think about it again tomorrow.
@itagagaki commented on GitHub (Aug 3, 2025):
I found that a new RDP tab opens successfully when I insert the delay code into the
WithoutUIfunction as follows.@VShawn commented on GitHub (Aug 4, 2025):
Today I went through the code again and found an out-of-bounds bug:
Here,
tasksis ping tasks + timeout tasks. WhencompletedTaskIndex = tasks.Count - 1, it causescredentials[completedTaskIndex]to go out of bounds.For example, when
credentials.Count = 2, thentasks = [ping credential 1, ping credential 2, countingTask].So when
completedTaskIndex = tasks.Count - 1 = 2, theifcondition is true, andreturn credentials[2]goes out of bounds.This might be the reason for the freezing issue, but it doesn't explain why I couldn't reproduce the freezing problem and why it frequently occurs in your environment.
@VShawn commented on GitHub (Aug 6, 2025):
I forgot to mention that I rewrote the function
FindFirstConnectableAddressAsyncandFindFirstConnectableAddressAsyncWithoutUI. I've tested it, and so far, so good. You can give it a try.https://github.com/1Remote/1Remote/blob/main/Ui/Service/SessionControlService_AlternateCredential.cs#L234-L313
@itagagaki commented on GitHub (Aug 9, 2025):
When I rebased and built for the first time in a while, the build failed because putty.exe was not found. Did you switch from KiTTY to PuTTY? What should I do?
@VShawn commented on GitHub (Aug 9, 2025):
Yes i move to PuTTY in PR https://github.com/1Remote/1Remote/pull/936 because KiTTY hasn't been updated in years.
Have you pulled this submodule? I put putty.exe inside.
@itagagaki commented on GitHub (Aug 9, 2025):
Thanks, I managed to build it. However, it still freezes or crashes. I will continue to investigate.
@VShawn commented on GitHub (Aug 9, 2025):
💔 really bad news.