Infinite reconnection to server #154
Reference in New Issue
Block a user
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?
Lately, after building, I've been constantly reconnecting to the server. I see in the server logs that everything is going smoothly, and it keeps going on forever. If I connect through the standard client, everything works fine.
This can happen if you selected "Always run as Administrator", this option is broken at the moment
Try compiling any x64 EXE or MSI package. You'll see that the EXE doesn't launch at all, and the MSI constantly tries to restart its service, causing the one-time key to change every 5-10 seconds. The status is also "not connected to the server." After stopping the service, the package can only be launched using the --service-install, --debug, or even --help parameters. The EXE shortcut doesn't respond to a simple double-click!
I did this using both my web server and this repository's web server. The result was the same. 40 minutes of waiting for nothing.
This checks out as the issues when you have selected "Always run as Administrator" to Yes.
Please DO NOT use that, it will run the service as SYSTEM anyways.
Please make a compilation, it'll take 40 minutes! And you'll see that something didn't go according to plan!
I confirm the issue on 1.4.4 and investigating
Testing on 1.4.3 now , not working with "always run ad admin" - No , same problem again ... old clients (1.4.3) works fine
Starting Rustdesk with double click on windows: Nothing
Starting Rustdesk from CMD with any args: Works
I suspect something is broken there when starting Rustdesk without any args. Service likely crashes for same reason.
This doesn't affect x86 build on Windows, only x64
I suspect a base64-encoded file called custom.txt in the root directory. If I remove it, Rustedsk will launch without modifications via double-click.
Oh , yes it's works , but service not work
The custom.txt file is where all the customization settings are loaded from. There must be an issue with one of the settings. I just tried on my computer and I cannot reproduce the issues. There are logs stored at "C:\Users\USER\AppData\Roaming\RustDesk\log\rustdesk_rCURRENT.log" that should show an error that should point to the issue.
On 1.4.4 build, even having an empty "custom.txt" leads to RustDesk not loading.
Logs don't show any particular error, it just stops before loading hwcodec config
I have not updated to support 1.4.4 yet. I hadn't noticed it was released already.
[2025-11-20 09:03:26.636273 +03:00] ERROR [src\ui_interface.rs:1167] ipc connection closed: reset by the peer
[2025-11-20 09:03:30.725326 +03:00] ERROR [src\ui_interface.rs:1167] ipc connection closed: reset by the peer
[2025-11-20 09:03:34.815376 +03:00] ERROR [src\ui_interface.rs:1167] ipc connection closed: reset by the peer
[2025-11-20 09:03:37.940329 +03:00] ERROR [src\ui_interface.rs:1167] ipc connection closed: reset by the peer
[2025-11-20 09:03:42.006814 +03:00] ERROR [src\ui_interface.rs:1167] ipc connection closed: reset by the peer
[2025-11-20 09:03:45.141154 +03:00] ERROR [src\ui_interface.rs:1167] ipc connection closed: reset by the peer
[2025-11-20 09:03:48.253296 +03:00] ERROR [src\ui_interface.rs:1167] ipc connection closed: reset by the peer
[2025-11-20 09:03:52.314454 +03:00] ERROR [src\ui_interface.rs:1167] ipc connection closed: reset by the peer
[2025-11-20 09:03:56.392431 +03:00] ERROR [src\ui_interface.rs:1167] ipc connection closed: reset by the peer
[2025-11-20 09:03:57.420804 +03:00] ERROR [src\ui_interface.rs:1167] ipc connection closed: reset by the peer
i tested 1.4.3 and 1.4.2 , same problem
Old build of 1.4.3 still works fine... Maybe some dependencies changed?
I can confirm that there is an issue with 1.4.4, but I am not seeing an issue with older versions (both sides on 1.4.3 or lower work for me, if either side has 1.4.4 there is an issue). I have no idea what the issue is, but I am looking into it.
I have older builds, and they work fine. But the builds I've been making for the last few days (1.4.3, 1.4.2) all have this problem.
I think it is a permissions issue with the custom.txt file. I changed the permissions manually on this file, and then everything worked again. I am adding a permissions change into the generator to see if this solves the issue.
Sadly just changing the permissions of the custom.txt file didn't work for me
build failed
Run icalcs ./rustdesk/custom.txt /grant Everyone:(F)
F: D:\a_temp\39189aeb-c46c-40c5-a203-a9d8491d38c6.ps1:2
Line |
2 | icalcs ./rustdesk/custom.txt /grant Everyone:(F)
| ~
| The term 'F' is not recognized as a name of a cmdlet, function, script file, or executable program. Check the
| spelling of the name, or if a path was included, verify that the path is correct and try again.
Error: Process completed with exit code 1.
"I removed the custom.txt file and was able to start RustDesk again without any issues."
Comparing 2 custom.txt files
Installed RustDesk 1.4.3 custom.txt with problems (does not start or open after stopping the service)
{
"conn-type": "both",
"override-settings": {},
"default-settings": {
"access-mode": "custom",
"enable-keyboard": "Y",
"enable-clipboard": "Y",
"enable-file-transfer": "Y",
"enable-audio": "Y",
"enable-tunnel": "Y",
"enable-remote-restart": "Y",
"enable-record-session": "Y",
"enable-block-input": "Y",
"allow-remote-config-modification": "N",
"direct-server": "Y",
"verification-method": "use-both-passwords",
"approve-mode": "password-click",
"allow-hide-cm": "N",
"allow-remove-wallpaper": "Y",
"enable-remote-printer": "Y",
"enable-camera": "Y",
"enable-terminal": "Y"
},
"enable-lan-discovery": "Y",
"allow-auto-disconnect": "Y"
}
If you remove the custom.txt from the problematic version and replace it with the other one, the client returns to working without problems. The differences
RustDesk 1.4.3 installation works perfectly with the following custom
{
"conn-type": "both",
"override-settings": {},
"default-settings": {
"access-mode": "full",
"enable-keyboard": "Y",
"enable-clipboard": "Y",
"enable-file-transfer": "Y",
"enable-audio": "Y",
"enable-tunnel": "Y",
"enable-remote-restart": "Y",
"enable-record-session": "Y",
"enable-block-input": "Y",
"allow-remote-config-modification": "Y",
"direct-server": "Y",
"verification-method": "use-both-passwords",
"approve-mode": "password-click",
"allow-hide-cm": "N",
"allow-remove-wallpaper": "Y",
"enable-remote-printer": "Y",
"enable-camera": "Y",
"enable-terminal": "Y"
},
"enable-lan-discovery": "Y",
"allow-auto-disconnect": "N"
}
custom.txt (problem) vs custom.txt (ok)
access-mode
→ custom.txt = "custom"
→ custom.txt = "full"
allow-remote-config-modification
→ custom.txt = "N"
→ custom.txt = "Y"
allow-auto-disconnect
→ custom.txt = "Y"
→ custom.txt = "N"
One observation: the same configuration with the difference of one client compiled 15 days ago and another 2 days ago. And all files compiled 2 days ago come with a different custom.txt and are identified by RustDesk as custom and not full.
Why does the compilation from 2025-11-06 work perfectly but the ones from 2025-11-18 or 19 or 20 or 21 do not work?
I have no idea at the moment what is causing this issue. I noticed that if you remove or rename custom.txt, you can open rustdesk as others have already stated, then you can start the service. After it reloads, close the window and put custom.txt back and open again. It should load now.
This will make the service start without important parameters in the custom.txt, such as permanent password, thus making the connection fail without asking for the one time use password.
Also the custom.txt compiled with 1.4.4 is the same for me as 1.4.3
I will have to go through the recent rustdesk code changes and see what I can find. Hopefully they haven't intentionally blocked us from using custom.txt in some way.
Is it possible to not set the maintenance mode in the recent change you've made ? cause using your image in docker, we cannot create client anymore even in 1.4.3 which works so just block build 1.4.4 if there's issue ?
By the way, I have to say that I tried different options even with other version and there's some error with custom like "notify new version" doesn't work and create an error, cycle monitor too
Thanks a lot
Found the culprit being "printer_driver_adapter.dll", which is downloaded from here at build time:
https://github.com/rustdesk/hbb_common/releases/tag/driver
This was updated 2 weeks ago, also explains why new builds even of older versions don't work.
Replacing with the file from 1.4.3 fixes the issue.
Great job ! Now need to find why this file break the app and how to patch it during the build ?and you did you do ? Just download the adapter and charge it the root file ?
Building without the Remote Printer files works, but will inhibit that feature. Could be used right now as a workaround.
Other option is to upload the older dll, but not sure if that is against the license? 🤔
For me I don’t think so because the file is not modified and we won’t modify it somehow just using an official file but older they don’t like when you inject code inside a file it looses the integrity but here it’s not the case the file comes from Rustdesk and original so 😁
Just disassembled the DLL and found out that new DLL added checks for custom.txt aswell, with same Public Key as the one we patch, but I cannot find any source code for that to patch it out...
Hum the verification of the key and custom file should be somewhere in the code or they check it using a server from api ?
EDIT: sorry it was not a real commit I’ll try to investigate too
EDIT 2: found that
For now I have disabled the printer driver, and builds should be working again. I think they might be trying to block my generator from working and sneaking it into code that they don't have open sourced.
Is it possible for exemple if anyone has the old DLL to inject it directly and bypass it ? Normaly the dll is already signed from the last build so I don't know if it can work
printer_driver_adapter.zip contains the dll and the adapteur files are the same so if you zip the old adapter dll in a zip and extract it but without using en encryption.
I am trying to see if it is possible to build the dll from the code. It looks like it might be built from the hbb_common code, so if we can remove the check on custom.txt and build the dll, then it should work. If not, I will investigate other options.
It doesn't look like there is any source code for the printer_driver_adapter.dll. They might have it in a private repository or I just can't find it.
Ye, I searched for the Public Key in whole GitHub, but couldn't find it referenced elsewhere but language files and common.rs in RustDesk
The dll is only use during the installation ? Or does the files is implemented into C:\Program\app name\drivers? Because if the dll is here why don’t take it from here but in an older version ? I’m not sure about what I’m saying maybe it is not the case
I'm not sure about using an older version of the dll. Since the source code is likely not available, I don't think we could legally distribute an older dll, but I don't really know. The dll is posted to their hbb_common repository as a release but has no license associated with it.
I have never been able to get remote printing working for me anyway so I don't even know how I would test if using the old dll works or not.
testing new builds (today) , client working good , but not connected to the server ( testing any servers and versions of client) original client working normal
Find a problem , when i disabled websockets , works fine . How disable websockets when building client ?
Try putting allow-websocket=N in the Default or Override settings in the "Other" section.
Disabling it will prevent the webclient from working. allow-websocket=N
I just updated the generator with a simple solution to the issue. I have it change the code to use "custom_.txt" as the file for loading custom settings instead of "custom.txt". This should work since our compiled rustdesk will use custom_.txt (which exists) and the printer dll will look for custom.txt which will no longer exist.