Long initial connection delay?

[scottbussinger]

I'm in the process of updating my VNC infrastructure and wanted to update to the latest version of SC. I've run into an odd issue though with the latest SC (dated July 2014). Everything seems to work except that there's a very long delay (around 70 seconds) on the initial connection. I'm using the current VNCViewer, current SC, and current repeater with RC4 encryption. The sequence is like this:

• Start vncviewer (so it connects to repeater)
  Start SC (July 2014) and accept UAC prompt
  Host shows SC tray icon (as not connected)
  ...70 seconds elapse (no visible sign of anything happening)...
  Viewer pops up and SC shows as connected (and everything seems to work fine at this point)

I tried putting the old winvnc.exe back (dated October 2011, but using the current version hooks and encryption dlls) and the delay is gone. The repeater didn't change and I tried reverting vncviewer.exe but it didn't help so it's clearly SC that's causing it. Any thoughts what could be causing the delay in connecting? I'd like the bug fixes and performance benefits of the latest version of SC, but an over a minute delay is a killer.

Thanks for any thoughts!

[scottbussinger]

No thoughts from anyone here?

Can anyone at least confirm that the latest versions of SC, VNCViewer, and the Repeater all work together for them? At least I'll know it's something specific about my situation and not generally misbehaving.

[Rudi De Vos]

The SC online creator is making almost 1000 exe a day.
When this would be a general issue i expect that other people would already reported the same issue.
Latest version is already more then 6 months online.

[Rudi De Vos]

The SC online creator is making almost 1000 exe a day.
When this would be a general issue i expect that other people would already reported the same issue.
Latest version is already more then 6 months online.

[proceno72]

This is a big issue for me too, especially when I'm connectinig on Win8 machine. For now I'm putting the old winvnc.exe back. We hope for an update

[Rudi De Vos]

As more people start reporting a 1 minute delay it's time to find a solution....
connection ? direct or via a repeater ?

[ender]

I answered this in my other topic, but it's more appropriate to do it here.

The 1-minute connection delay happens when desktop composition (Aero) is enabled on the server. When [WALLPAPER] is used in helpdesk.txt, this delay will be avoided on Windows Vista and 7 (because Aero will be disabled), but on 8 and 8.1 desktop composition cannot be disabled, so the delay will be always present. Using repeater doesn't make any difference, and while the viewer is waiting for the picture to appear (after accepting connection), the tray icon on server doesn't respond. The problem is not limited to the latest version - it happened with older versions, too (can't say how far back I noticed this - probably ever since [WALLPAPER] was introduced).

[Rudi De Vos]

Thanks for the feedback
Are you running as "runas admin" or normal user.

Default sc remove aero and wallpaper when [WALLPAPER] is set aero en wallpaper or NOT removed. ( invers option)
I need to do some test to see if i can repeat it.

[ender]

I'm aware that Aero isn't disabled when [WALLPAPER] is set. I'm saying that with [WALLPAPER] set, the issue can be reproduced on Vista and 7 (when the user has Aero enabled), and that the issue always occurs on Windows 8 and 8.1 (since desktop composition can't be disabled there). I'm fairly sure that the error happens regardless of what rights the user has (I'm using a custom self-extractor for SC, which will drop winvnc.exe to Program Files, and run it from there when user has administrative privileges [to allow interaction with elevated processes], but when user isn't an admin, it'll run winvnc.exe from %TEMP%); I can do more testing later.

[Rudi De Vos]

Found:

SC check the best method to acpture the screen
getpixel ( was used on w2k,xp ...) , new bitblt ( faster from some xp systems)
The problem is that on some newer systems the getpixel is so slow that it take 30-60 seconds.
The check works, but slow the initial start.
The solution seems to aboard the getpixel check when it takes longer then bitblt

I need to do a few checks, but src change seems to do the trick

[Rudi De Vos]

creator updated, please test and report if fixed

[ender]

Is the source available?

[Rudi De Vos]

Not yet, need feedback if it's fixed or not.

[ender]

Seems to have been fixed for me (tested on physical Windows 8.1 and Vista running in VMWare Workstation).

[Rudi De Vos]

change, 3 lines added to quit for loop when it take to long

COLORREF cr = 0;
for (int xx=0;xx<m_bmrect.right*m_bmrect.bottom/32/32;xx++)
{
cr=GetPixel(m_hrootdc, 1, 1);
DWORD stop= timeGetTime(); <<< ADD
time2=(stop-start); <<< ADD
if (time2>time1) break; <<<<ADDD
}
}
DWORD stop= timeGetTime();
time2=(stop-start);