I figured it's about time that I take some of the peskier bugs we keep discussing and write them down in one place so that, I hope, the developers can choose to address them. Thanks.
1. REPEATER COMPATIBILITY. UltraVNC server 188.8.131.52 does <b>not</b> work with UltraVNC repeaters. After a couple of hours, the server becomes unreachable, because it's pausing 15 minutes or more between repeater reconnects. (184.108.40.206 has no such problem.)
Documented at Re: Possible BUG for server version 220.127.116.11 + repeater and UltraVNC On Windows 7 Video Issues? and elsewhere.
2. CAN'T SHUT DOWN. If UltraVNC server is set to "When Last Client Disconnects, Log Off Workstation", the Windows machine can not be shut down (while session active). It can't even be shut down at the physical server keyboard.
Problem with restart/shutdown on windows 2003 R2
Confirmed so far in UltraVNC 18.104.22.168 <b>and</b> UltraVNC 22.214.171.124
3. NO CTRL-ALT-DEL. Windows won't allow Ctrl-Alt-Del if UAC is turned off.
UltraVNC solution posted at CAD solution with UAC off
4. BAD REFRESHING. With UltraVNC installed as a service, and connected, after logging out of Windows and logging back in again, screen does not refresh (or lags so severely as to seem so) during keyboard/mouse activity, whereas it worked in the preceding login session. (See #2 above.) Restarting the service seems to fix this.
5. MULTIPLE MONITOR. UltraVNC 126.96.36.199 has very poor multiple monitor support in my experience (and based on other reports). 188.8.131.52 is better. With 184.108.40.206, pressing the "Select Full Desktop / Switch monitor(driver only)" button alternately doesn't work, flashes the screen before redisplaying the first monitor anyway, leaves a ghost image of the first monitor even after switching, overlaps parts of the two displays, shifts actual focus to the secondary monitor but continues displaying the first monitor, and finally just crashes the viewer completely (and silently; and repeatedly).
6. IP ADDRESS BINDING. UltraVNC <b>never</b> appears to check the IP addresses of its local host after the WinVNC server starts. This causes all <b>sorts</b> of problems as reported in these forums. People whose IP address changes due to DHCP re-leases, or the addition of a new NIC, or the <b>activation</b> of a previously disabled NIC, or the insertion of a cellular air-card, etc., etc., etc. -- all these people will have a running UltraVNC server that knows NOTHING about their active IP address and are left WITHOUT connectivity. Worse, this problem applies <b>especially</b> when UVNC has been started as a service, and it thwarts the usefulness of dynamic DNS services (since for those with public IP addresses on their computer, while the DDNS name will still reach them, the running UltraVNC server won't answer!).
7. AUTO-SCALING. Auto-scaling seems a haphazard affair. Sometimes it works, and sometimes it doesn't. Sometimes it's "sticky" and sometimes it's not.
8. MS LOGON BLOCKS ACCESS. If all three groups are left empty, the server will reject <b>all</b> connections, even by local admins. All versions of UltraVNC from 1.0.2 to the present. Care of YY at Re: Hi, Newbie! Having real problems with port fowarding :(
My apologies in advance for a lack of detail on some of the above.