Skip navigation
This discussion is archived

ARD and screen sharing become unresponsive when switching users

13925 Views 23 Replies Latest reply: Mar 31, 2010 1:45 PM by Doogie125 RSS
1 2 Previous Next
Aaron Adams Calculating status...
Currently Being Moderated
Sep 26, 2009 6:31 PM
I wanted to repost this question because surely I cannot be the only person who's had this problem.

I manage a number of Leopard (10.5.8) and Snow Leopard (10.6.1) servers and desktops via ARD. Whenever I'm sharing the screen of those servers and I return to the login window by switching users, the screen sharing window closes and I am unable to reconnect to screen sharing on the server until I reboot it. Killing all loginwindow processes from ssh also restores ARD's ability to reconnect to the server, but also obviously kills the sessions of users logged in.

I have made sure this is not a problem with my admin machine. I have followed Apple's instructions to remove ARD admin from my admin machine, cleared caches, repaired permissions, deleted preference files, and done all the usual troubleshooting steps. This leads me to believe that the problem lies with the servers and not the admin station.

On the servers, the following entries appear in the system log when the client attempts to reconnect:

Sep 26 21:09:38 Mac-mini AppleVNCServer[1540]: kCGErrorIllegalArgument: CGSGetDisplayBounds (display 503550)
Sep 26 21:09:38 Mac-mini[1523]: Sat Sep 26 21:09:38 Mac-mini.local AppleVNCServer[1540] <Error>: kCGErrorIllegalArgument: CGSGetDisplayBounds (display 503550)

I have found this problem only happens on servers that have no monitor plugged in.

What is causing screen sharing to become unresponsive? Is there any way to correct this issue?

Message was edited by: Aaron Adams
MacBook Pro, Mac OS X (10.6.1)
  • Matt W (TechnicalMac) Level 1 Level 1 (25 points)
    Not isolated. It just happened here too, also a headless unit. I tried ARD running on 10.6.1 connecting to 10.5.8, switched users and nothing. Have blue screen when I connected a monitor to the affected machine. The target is unresponsive to local keyboard input as well (was connected prior to the lost video event), not just remote access. After logging out (killall -u <2nd user>) ARD produces no window. Screen Sharing paints a black window with nothing in it. There appears to be a bug in the windowserver (?) process.

    MacBook Pro, Mac OS X (10.6.1)
  • Werner Van Geit Calculating status...
    You are not alone. I also had exactly the same problem. Apple Remote Desktop control mode -> then switch to login window -> connection breaks, and it is impossible to start a new control/observe session. And the system.log show errors like kCGErrorIllegalArgument: CGSGetDisplayBounds
  • S.K.K. Calculating status...
    Same here. Headless Mac Mini running 10.6.1 Server.

    Same log entry:

    AppleVNCServer[64410] <Error>: kCGErrorIllegalArgument: CGSGetDisplayBounds (display b01a4668)
    Mac Mini, Mac OS X (10.6.1)
  • andrejbl Calculating status...
    Ditto. Headless Mac Mini running 10.6.2. Same log entry.

    When Screen Sharing and the remote user is switched, the Screen Sharing function fails. Can no longer connect without rebooting the remote computer.
    Mac OS X (10.6.2)
  • eyeless Level 1 Level 1 (35 points)
    Yes, it has lately become very difficult to use screen sharing on the Mac. If you log out one user you will never be able to log in again remotely.

    If you change network location then authentication will not work and let you back in from the new place (maybe happens because I never leaved the session properly, but another machine cannot connect via screen sharing either on the same local LAN afterwards).

    You have to be very careful not shifting between Ethernet and Airport as that will break any connection attempts even if on the same LAN (this might have been so before and for good reasons, perhaps).

    Copying files over the Internet via ARD has never really worked in any situation (with some of odd exceptions).

    Moving windows on the remote machine has for many years resulted in having them snapped to the edges of the remote desktop ... .

    Basically you have to have the remote machine connected all the time to keyboard, mouse and screen and have someone standing in front of it as ARD cannot be relied upon these days.
    MBA, Mac OS X (10.6.2)
  • mpearrow Calculating status...
    I'm having a similar problem. My management computer is a MacBook Pro running 10.6.2 and ARD 3.3 (451.15). My remote server is a G5 tower running OS X Server 10.4.11. If I lock the remote screen (with the "curtains"), the remote server becomes totally unresponsive to ARD until a reboot.
    MacBook Pro 2.8GHz Core 2 Duo / 4GB RAm, Mac OS X (10.6.2)
  • ruluk7 Calculating status...
    Same problem here: Mac Mini Server 10.6.2 headless. When logging out or locking screen (switching user), Screen Sharing is gone.
    Interestingly, I even can't login locally after attaching a display. It only shows an empty blue screen.

    Seems as if the windows server hangs...
  • Farcaller Calculating status...
    Same here on headless mini with 10.6.2 server. killall -9 WindowServer returns ARD functionality, but this is somewhat... bad resolution. All UI sessions are killed.
    MacMini2,1, Mac OS X (10.6.2)
  • ruluk7 Level 1 Level 1 (0 points)
    Exactly the same here...
    At least, by killing WindowServer I'm able to login again...

    But this has to be fixed...
  • Farcaller Level 1 Level 1 (0 points)
    I've posted a rdar://7505826 to Apple, you can track it from OpenRadar here:
    Mac OS X (10.5.6)
  • gojohn Calculating status...
    I'm having the same problem with a recent Aluminum iMac, using Snow Leopard. I switch users via the fast user switching menu and the other user logs in, but the screen stays with the previous user. In addition, when I log out the current user, I can no longer control the machine at all.

    This occurs when controlling over the internet. I forward ports 5900 and 3283, which used to always work when controlling the previous iMac.
    MacBook Pro, Mac OS X (10.6.2)
  • gojohn Level 1 Level 1 (0 points)
    Here's the error I get once I disconnect and try to reconnect to ARD on the client Mac:

    Jan 9 09:26:20 Aluminum-iMac AppleVNCServer[97396]: kCGErrorIllegalArgument: CGSGetDisplayBounds (display 786550)
    Jan 9 09:26:20 Aluminum-iMac AppleVNCServer[97396]: setbackground error 268435459
    Jan 9 09:26:20 Aluminum-iMac AppleVNCServer[97396]: IOPMAssertionCreate error -536870199
    Jan 9 09:26:20 Aluminum-iMac AppleVNCServer[97396]: setbackground error to zero 268435459
    Jan 9 09:26:20 Aluminum-iMac AppleVNCServer[97396]: kCGErrorIllegalArgument: CGSGetDisplayBounds (display 786550)
    Jan 9 09:26:20 Aluminum-iMac AppleVNCServer[97396]: setbackground error 268435459
    Jan 9 09:26:20 Aluminum-iMac AppleVNCServer[97396]: IOPMAssertionCreate error -536870199
    Jan 9 09:26:21 Aluminum-iMac[99] (0x100207010.anonymous.SafariSyncClient[88002]): The following job tried to hijack the service "" from this job:
    Jan 9 09:26:21 Aluminum-iMac[99] ([88004]): Exited with exit code: 1
    Jan 9 09:26:21 Aluminum-iMac AppleVNCServer[97396]: setbackground error to zero 268435459

    I currently can't recreate the problem of trying to switch users, since I can't log into the Mac remotely to test it.
    MacBook Pro, Mac OS X (10.6.2)
  • dweingartner Calculating status...
    I just had the same problem. ARD on my Leopard machine, managing Snow Leopard on a Mac mini. I turned the curtain on, and forgot to disable the curtain when I logged out of the user account. The curtain screen stayed up, and ARD got no response, so I had to reboot the Snow Leopard mini. Seems like this should have been fixed in the last ARD release.
    PowerMac G5, Mac OS X (10.5.8)
1 2 Previous Next


More Like This

  • Retrieving data ...

Bookmarked By (4)


  • This solved my question - 10 points
  • This helped me - 5 points
This site contains user submitted content, comments and opinions and is for informational purposes only. Apple disclaims any and all liability for the acts, omissions and conduct of any third parties in connection with or related to your use of the site. All postings and use of the content on this site are subject to the Apple Support Communities Terms of Use.