App hangs on Connected, waiting for image.... #328

Closed
opened 2026-02-20 22:28:53 -05:00 by deekerman · 28 comments
Owner

Originally created by @eqpaisley on GitHub (Mar 8, 2022).

Describe the bug you encountered:

When connecting to a new setup, the connection is made but the Connected, waiting for image... screen never goes away.

What did you expect to happen instead?

Log in should complete and the remote desktop should appear.

How did you install RustDesk?

Windows portable

RustDesk version and environment

Running rustdesk (downloaded today 3/9/22 from the website) on Windows 10. Connecting via Windows 10 on a different PC.

I use rust desk to connect to a different computer with no issues.

image

Originally created by @eqpaisley on GitHub (Mar 8, 2022). <!-- Hey there, thank you for creating an issue! --> **Describe the bug you encountered:** When connecting to a new setup, the connection is made but the Connected, waiting for image... screen never goes away. **What did you expect to happen instead?** Log in should complete and the remote desktop should appear. **How did you install `RustDesk`?** <!-- GitHub release, build from source, Windows portable version, etc. --> Windows portable **RustDesk version and environment** <!-- In order to reproduce your issue, please add some information about the environment in which you're running RustDesk. --> Running rustdesk (downloaded today 3/9/22 from the website) on Windows 10. Connecting via Windows 10 on a different PC. I use rust desk to connect to a different computer with no issues. ![image](https://user-images.githubusercontent.com/5481431/157329079-046cc5b5-795a-439b-ac49-143a411d3fc0.png)
deekerman 2026-02-20 22:28:53 -05:00
Author
Owner

@fufesou commented on GitHub (Mar 8, 2022):

Do you have a monitor on the remote side? #59

@fufesou commented on GitHub (Mar 8, 2022): Do you have a monitor on the remote side? #59
Author
Owner

@rustdesk commented on GitHub (Mar 8, 2022):

Please try out https://github.com/rustdesk/rustdesk/releases/download/tmp/rustdesk-1.1.9-putes.exe (on both side) if you have the monitor?

@rustdesk commented on GitHub (Mar 8, 2022): Please try out https://github.com/rustdesk/rustdesk/releases/download/tmp/rustdesk-1.1.9-putes.exe (on both side) if you have the monitor?
Author
Owner

@eqpaisley commented on GitHub (Mar 9, 2022):

I do not have a monitor on the remote side.

@eqpaisley commented on GitHub (Mar 9, 2022): I do not have a monitor on the remote side.
Author
Owner

@rustdesk commented on GitHub (Mar 9, 2022):

do not have a monitor

@fufesou but it does not report "No display" error, you may need to consider this scenario.

@rustdesk commented on GitHub (Mar 9, 2022): > do not have a monitor @fufesou but it does not report "No display" error, you may need to consider this scenario.
Author
Owner

@rustdesk commented on GitHub (Mar 14, 2022):

@eqpaisley try out https://github.com/rustdesk/rustdesk/releases/download/tmp/rustdesk-1.1.9-putes.exe please

@rustdesk commented on GitHub (Mar 14, 2022): @eqpaisley try out https://github.com/rustdesk/rustdesk/releases/download/tmp/rustdesk-1.1.9-putes.exe please
Author
Owner

@xvolks commented on GitHub (Jul 18, 2022):

I have the same behaviour between my macbooks and macOS VM both running Monterey 12.4 and Rustdesk 1.1.9.
Tested with public server and private server.
Between 2 macbooks it works fine, but it behaves the same if no session is open on the remote computer.

@xvolks commented on GitHub (Jul 18, 2022): I have the same behaviour between my macbooks and macOS VM both running Monterey 12.4 and Rustdesk 1.1.9. Tested with public server and private server. Between 2 macbooks it works fine, but it behaves the same if no session is open on the remote computer.
Author
Owner

@gioman commented on GitHub (Aug 11, 2022):

Can someone help clarify here? what is the issue, the monitor being unplugged/sleeping and/or the session being locked?

@gioman commented on GitHub (Aug 11, 2022): Can someone help clarify here? what is the issue, the monitor being unplugged/sleeping and/or the session being locked?
Author
Owner

@xvolks commented on GitHub (Aug 13, 2022):

@gioman I've tested multiple scenarii:

  • Macbook Pro 2012 (12.4, open legacy patcher, no session opened) --> no image,
  • Virtual Mac (12.4, Opencore, Proxmox, both session opened or not) --> no image,
  • Macbook Pro 16" core-I9 (12.5, both session opened or not) --> image OK.

Maybe the problem is on Opencore side...

@xvolks commented on GitHub (Aug 13, 2022): @gioman I've tested multiple scenarii: - Macbook Pro 2012 (12.4, open legacy patcher, no session opened) --> no image, - Virtual Mac (12.4, Opencore, Proxmox, both session opened or not) --> no image, - Macbook Pro 16" core-I9 (12.5, both session opened or not) --> image OK. Maybe the problem is on Opencore side...
Author
Owner

@gioman commented on GitHub (Aug 17, 2022):

@xvolks thanks for the reply.

This is my observation so far.

Local machine Win 10, remote machine Linux Mint 20:

I can connect and control the remote machine (even if the screen is physically turned off) as long in Linux Mint the option "turn off screen when inactive for..." is not enabled. The moment that the screen power saving kicks in, then the remote machine is not controllable anymore (rustdesk shows the hanging "waiting for image" message).

Local machine Win 10, remote machine mac mini M1 / macOS Monterey:

locking the session, physically turning off the display and letting macOS turn off the display after "x" minutes of inactivity, are all cause to rustdesk not being able to control the remote machine ("waiting for image" message).

Screens on remote systems are all connected via HDMI cable.

@gioman commented on GitHub (Aug 17, 2022): @xvolks thanks for the reply. This is my observation so far. Local machine Win 10, remote machine Linux Mint 20: I can connect and control the remote machine (even if the screen is physically turned off) as long in Linux Mint the option "turn off screen when inactive for..." is not enabled. The moment that the screen power saving kicks in, then the remote machine is not controllable anymore (rustdesk shows the hanging "waiting for image" message). Local machine Win 10, remote machine mac mini M1 / macOS Monterey: locking the session, physically turning off the display and letting macOS turn off the display after "x" minutes of inactivity, are all cause to rustdesk not being able to control the remote machine ("waiting for image" message). Screens on remote systems are all connected via HDMI cable.
Author
Owner

@MaCXyLo commented on GitHub (Aug 29, 2022):

had the same issue today.
allow screen recording on "settings", "security and privacy" on the mac.
https://docs.microsoft.com/de-de/stream/media/stream-record-video/stream-record-video-privacy-setting.png
the keyboard input still seems to cause problems. maybe another permission problem?
didn't have time to take a closer look.

@MaCXyLo commented on GitHub (Aug 29, 2022): had the same issue today. allow screen recording on "settings", "security and privacy" on the mac. https://docs.microsoft.com/de-de/stream/media/stream-record-video/stream-record-video-privacy-setting.png the keyboard input still seems to cause problems. maybe another permission problem? didn't have time to take a closer look.
Author
Owner

@rustdesk commented on GitHub (Aug 29, 2022):

permission

https://github.com/rustdesk/rustdesk/issues/974#issuecomment-1186577391

@rustdesk commented on GitHub (Aug 29, 2022): > permission https://github.com/rustdesk/rustdesk/issues/974#issuecomment-1186577391
Author
Owner

@MaCXyLo commented on GitHub (Aug 29, 2022):

teamviewer has a permission checker:
https://community.teamviewer.com/English/kb/articles/44699-remote-control-a-mac
seems to be a possible workaround.

otherwise: it would be even nicer if rustdesk would ask the user to grant the permission.

@MaCXyLo commented on GitHub (Aug 29, 2022): teamviewer has a permission checker: https://community.teamviewer.com/English/kb/articles/44699-remote-control-a-mac seems to be a possible workaround. otherwise: it would be even nicer if rustdesk would ask the user to grant the permission.
Author
Owner

@MaCXyLo commented on GitHub (Aug 29, 2022):

this stackoverflow thread describes how to change these kinds of permissions via terminal:
https://stackoverflow.com/questions/37865439/terminal-command-to-change-security-and-privacy-advanced-setting

@MaCXyLo commented on GitHub (Aug 29, 2022): this stackoverflow thread describes how to change these kinds of permissions via terminal: https://stackoverflow.com/questions/37865439/terminal-command-to-change-security-and-privacy-advanced-setting
Author
Owner

@gioman commented on GitHub (Sep 1, 2022):

Local machine Win 10, remote machine mac mini M1 / macOS Monterey:

locking the session, physically turning off the display and letting macOS turn off the display after "x" minutes of inactivity, are all cause to rustdesk not being able to control the remote machine ("waiting for image" message).

if the remote machine is a mac mini Intel / macOS Catalina the issue is slightly different:

physically turning off the display and letting macOS turn off the display after "x" minutes of inactivity do not seems to be a problem for rustdesk, while locking the session is: when the session is locked and the remote machine is unattended then rustdesk connects but show a static image of the desktop the moment the session was locked. If someone move the mouse on the remote machine than the login screen shows and the password can be entered.

@gioman commented on GitHub (Sep 1, 2022): > Local machine Win 10, remote machine mac mini M1 / macOS Monterey: > > locking the session, physically turning off the display and letting macOS turn off the display after "x" minutes of inactivity, are all cause to rustdesk not being able to control the remote machine ("waiting for image" message). if the remote machine is a mac mini Intel / macOS Catalina the issue is slightly different: physically turning off the display and letting macOS turn off the display after "x" minutes of inactivity do not seems to be a problem for rustdesk, while locking the session is: when the session is locked **and** the remote machine is unattended then rustdesk connects but show a static image of the desktop the moment the session was locked. If someone move the mouse on the remote machine than the login screen shows and the password can be entered.
Author
Owner

@charlespick commented on GitHub (Sep 28, 2022):

I'm having the same issue, connecting to a macos VM (running on a real mac), esxi with a video output that I can use with anydesk, macos's built in vnc, and the vsphere web console. But with rust desk it just connects and sits there. Frustrating cause anydesk seems to have a different issue right now

@charlespick commented on GitHub (Sep 28, 2022): I'm having the same issue, connecting to a macos VM (running on a real mac), esxi with a video output that I can use with anydesk, macos's built in vnc, and the vsphere web console. But with rust desk it just connects and sits there. Frustrating cause anydesk seems to have a different issue right now
Author
Owner

@Kukulkano commented on GitHub (Nov 21, 2022):

I try to access MacOS 12.6 Monterey client using OpenSuse 15.3 Linux. Both running RustDesk 1.1.9.

I get asked the password and then the screen stays black saying "Connected, waiting for image...". There is no nightly DMG file I can try...

Screen recording & accessibility are turned on at the Mac.

@Kukulkano commented on GitHub (Nov 21, 2022): I try to access MacOS 12.6 Monterey client using OpenSuse 15.3 Linux. Both running RustDesk 1.1.9. I get asked the password and then the screen stays black saying "Connected, waiting for image...". There is no nightly DMG file I can try... Screen recording & accessibility are turned on at the Mac.
Author
Owner

@mon-jai commented on GitHub (Nov 29, 2022):

I have a Windows host running nightly build. I tried connecting to it with Windows (v1.19 and nightly build) as well as Android v1.19.

I was not able to connect to the host with both Windows builds. v1.19 failed with the message "An existing connection was forcedly closed by the remote host OS ERROR 10054". Nightly hanged with "Connected, waiting for image..." prompt.

Android app connected to the remote host successfully after several attempts but the refresh rate was so low that makes RustDesk unusable, something like 1 frame/minute.

@mon-jai commented on GitHub (Nov 29, 2022): I have a Windows host running nightly build. I tried connecting to it with Windows (v1.19 and nightly build) as well as Android v1.19. I was not able to connect to the host with both Windows builds. v1.19 failed with the message "An existing connection was forcedly closed by the remote host OS ERROR 10054". Nightly hanged with "Connected, waiting for image..." prompt. Android app connected to the remote host successfully after several attempts but the refresh rate was so low that makes RustDesk unusable, something like 1 frame/minute.
Author
Owner

@G2G2G2G commented on GitHub (Dec 1, 2022):

Connecting is fine with what @MaCXyLo said. Going into permissions and enabling the screen sharing.

We didn't get the keyboard and mouse to work though even though the "enable keyboard/mouse" was checked. We'll try some other things (restarting the computer) and such later

His stack overflow is probably the solution to an automated enable of the screensharing.

@G2G2G2G commented on GitHub (Dec 1, 2022): Connecting is fine with what @MaCXyLo said. Going into permissions and enabling the screen sharing. We didn't get the keyboard and mouse to work though even though the "enable keyboard/mouse" was checked. We'll try some other things (restarting the computer) and such later His stack overflow is probably the solution to an automated enable of the screensharing.
Author
Owner

@29039 commented on GitHub (Dec 31, 2022):

MacOS upgrade from 10.14 to 13 and the Screen Recording permissions wasn't carried over, needing manual user intervention.

@29039 commented on GitHub (Dec 31, 2022): MacOS upgrade from 10.14 to 13 and the Screen Recording permissions wasn't carried over, needing manual user intervention.
Author
Owner

@zhOrange commented on GitHub (Jan 7, 2023):

I get the same problem. Did some one have any ideas?

@zhOrange commented on GitHub (Jan 7, 2023): I get the same problem. Did some one have any ideas?
Author
Owner

@guilhermewerner commented on GitHub (Jan 20, 2023):

I have the same problem when trying to access a vm running on proxmox. I changed the privacy settings and it didn't work.

  • Host: Proxmox VE 7.3-3
  • VM: OpenCore Mac OS Ventura 13.1
  • Client: Windows 11 Pro

imageimage
image

@guilhermewerner commented on GitHub (Jan 20, 2023): I have the same problem when trying to access a vm running on proxmox. I changed the privacy settings and it didn't work. - **Host**: Proxmox VE 7.3-3 - **VM**: OpenCore Mac OS Ventura 13.1 - **Client**: Windows 11 Pro ![image](https://user-images.githubusercontent.com/26710260/213785620-7af553e1-d146-4e1d-97e6-8863ef10bf41.png)![image](https://user-images.githubusercontent.com/26710260/213785556-ec5aa8cc-a8b8-421c-9914-df1349511734.png) ![image](https://user-images.githubusercontent.com/26710260/213786219-f74c66d1-aa8c-4e62-8d4a-aa04b9ecde45.png)
Author
Owner

@rafaelarcanjo commented on GitHub (Feb 20, 2023):

Hi.

Any news on virtualized MacOS?

Thanks!

@rafaelarcanjo commented on GitHub (Feb 20, 2023): Hi. Any news on virtualized MacOS? Thanks!
Author
Owner

@guilhermewerner commented on GitHub (Feb 21, 2023):

@rafaelarcanjo I tried it on several versions of macos and with different hardware configurations and they all have the same problem

@guilhermewerner commented on GitHub (Feb 21, 2023): @rafaelarcanjo I tried it on several versions of macos and with different hardware configurations and they all have the same problem
Author
Owner

@RLWestfall commented on GitHub (Apr 15, 2023):

I had this same problem just now with RustDesk 1.1.9 installed on a MacBook Pro laptop with MacOS 10.15.7. I successfully enter the credentials to manage a remote MacBook Pro laptop that has RustDesk 1.1.9 installed. I get a popup window saying something to the effect the connection was successful and waiting for image. If you press the OK button on the popup window, the connection drops. The person on the other end of the connection sees my name pop up on their display after the successful login but I don't know if my name disappears from their display at the same time the connection drops on my end.

@RLWestfall commented on GitHub (Apr 15, 2023): I had this same problem just now with RustDesk 1.1.9 installed on a MacBook Pro laptop with MacOS 10.15.7. I successfully enter the credentials to manage a remote MacBook Pro laptop that has RustDesk 1.1.9 installed. I get a popup window saying something to the effect the connection was successful and waiting for image. If you press the OK button on the popup window, the connection drops. The person on the other end of the connection sees my name pop up on their display after the successful login but I don't know if my name disappears from their display at the same time the connection drops on my end.
Author
Owner

@mon-jai commented on GitHub (Apr 16, 2023):

1.1.9 was released about one year ago.

Maybe you should try the latest nightly build.

@mon-jai commented on GitHub (Apr 16, 2023): 1.1.9 was released about one year ago. Maybe you should try the latest nightly build.
Author
Owner

@rustdesk commented on GitHub (May 24, 2023):

https://github.com/rustdesk/rustdesk/issues/3261

@rustdesk commented on GitHub (May 24, 2023): https://github.com/rustdesk/rustdesk/issues/3261
Author
Owner

@agentr14 commented on GitHub (Sep 15, 2023):

Anyone figure this out yet ?

@agentr14 commented on GitHub (Sep 15, 2023): Anyone figure this out yet ?
Author
Owner

@gioman commented on GitHub (Sep 16, 2023):

Anyone figure this out yet ?

@agentr14 using one of these https://www.amazon.com/dp/B07YKGGQTJ?ref=ppx_yo2ov_dt_b_product_details&th=1 to workaround the issue.

@gioman commented on GitHub (Sep 16, 2023): > Anyone figure this out yet ? @agentr14 using one of these https://www.amazon.com/dp/B07YKGGQTJ?ref=ppx_yo2ov_dt_b_product_details&th=1 to workaround the issue.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/rustdesk-rustdesk#328
No description provided.