Menu ▾ ▴

#1507 More trouble with UAC

None
open-accepted
nobody
None
5
2022-07-29
2020-04-08
rdiez
No

First of all, many thanks for TightVNC. I have used it for years to help friends and relatives.

I have even written setup instructions in Spanish, in case I cannot preinstall it on the target computer:

http://rdiez.shoutwiki.com/wiki/Ayuda_inform%C3%A1tica_a_trav%C3%A9s_del_control_remoto

Yesterday I had a particularly bad time with TightVNC and I wanted to share it with you.

I am finding that people have often seen TeamViewer and are less inclined to tolerate the difficulties associated with TightVNC, so I have to endure more and more snarky comments about the low-quality open-source software I tend to use. Windows users have no heart. 8-)

I always use a reverse connection for security reasons. Most people do not how to configure a port forward on the router (let alone install a VPN), but I can do that on my side, so a reverse connection is the way to go.

There is a second reason: some people use their laptops at work too, and I want to avoid questions from their IT administrators about a newly-installed service designed for remote control. Avoiding such suspicions is also the reason why I tell users to disable option "Accept incoming connections". I can then "prove" that such remote control sessions can only be started manually.

The first problem with TightVNC is installation. Many people find it hard to configure the "TightVNC Server (Application Mode)" to start with administrator privileges, and Microsoft has moved things around again in Windows 10 and made it even harder. It would be nice if TightVNC's setup program could create an alternative icon called "TightVNC Server (Application Mode) as Administrator".

The biggest issue with TightVNC are the hard disconnections associated with the UAC prompt. I normally need to do admin-level work on the remote computers, so I hit his issue very frequently.

I am aware of this (closed) issue:

951 UAC 'landmines' still an issue
https://sourceforge.net/p/vnc-tight/bugs/951/

Most times, when the UAC prompt came up, TightVNC not only lost the connection, but crashed. I have never seen that issue with older TightVNC versions, but unfortunately, I do not keep track of which exact versions my friends etc. are using. Yesterday my remote partner was using the latest version of TightVNC (2.8.27) on a 32-bit Windows 10 system. The viewer I was using was vinagre 3.22.0-5 that comes with Ubuntu 18.04.4 LTS. I could not see the exact crash message on the remote computer. My remote partner had to restart the "TightVNC Server (Application Mode)" several times during one session, as I wanted to uninstall unnecesary software on his Windows PC, triggering one UAC prompt every time.

Fixing the TightVNC crash would be the first step. But there is more that could be done to handle UAC prompts better.

I do not really mind if the remote partners have to reconnect every time, but TightVNC could make it more user friendly. Instead of dropping the connection to the viewer, it could send a hint to the viewer that the desktop is no longer available, probably due to a UAC prompt. Or it may just still disconnect and leave me wondering (I can cope with it), but perhaps show the remote user a task-bar notification that the remote-control session has been disconnected (hopefully after the UAC prompt has been clicked away), so that the user's attention is drawn back to the VNC icon on the taskbar.

After the UAC prompt, when the normal Windows desktop is available again (that is, when the user has clicked the UAC prompt away), the TightVNC server could either resume the session (if the connection was not actually dropped), or automatically reconnect to the viewer (UltraVNC has option -autoreconnect), or maybe prompt the remote user whether he wants to reestablished the remote connection. That would help users that have problems finding icons and navigating to the pop-up menu option "Attach Listening Viewer...".

I heard that TightVNC does not have such issues with UAC when working in service mode. Therefore, another solution would be to have some easy-to-use GUI tool start the TightVNC service in order to make a single reverse connection. When the connection is finished, the service should automatically stop. If it stayed running, I would only be happy if it would not take any incoming connections. May I suggest a separate service named "TightVNC for reverse connections" that just can never take incoming connections.

Thanks in advance,
rdiez

Discussion

  • rdiez

    rdiez - 2020-04-09

    I have more information on the crash I reported above. I am using now a virtual PC with Windows 10, this time the 64-bit version, as the remote PC doing the reverse connection. Therefore, I am using the 64-bit version of TightVNC. When the UAC dialog comes up, you get this error dialog:

    TightVNC

    Apllication crashing. Do you want save debug information?

    Yes No

    This must be some internal dialog in TightVNC, especially since "Apllication" is misspelled. Such dialogs are normally a bad idea, becuase they tend to obscure the original crash or create confusion. It is usually better to let the operating system close the program immediately.

    While this dialog is up, attempting to reconnect with a reverse connection silently fails, adding to the confusion. The 'vinagre' viewer reports then:

    Connection closed
    Connection to host 192.168.100.11::49681 was closed.

    If you choose "No" on the dialog, TightVNC server closes, leaving a taskbar icon behind for a few seconds. Attempting to click on the icon does nothing, which further confuses users with no IT experience. Eventually, the taskbar removes the icon.

     

    • Anton

      Anton - 2020-09-07

      Hi!
      Could you send me the crash.dmp file to anton@glavsoft.com

       

  • Anton

    Anton - 2020-09-07
    • status: open --> open-accepted
    • Group: -->
     

  • rdiez

    rdiez - 2020-09-07

    I sent it just now.

     

  • rdiez

    rdiez - 2020-09-09

    Were you able to identify the problem with the crash dump I sent, or do you need more help?

     

    • Anton

      Anton - 2020-09-09

      yes, it was the same crash was fixed in .38 version above but the version still closes connection after 3 seconds of black screen

       

    • Anton

      Anton - 2020-09-28

      Hi!
      Please test the new version https://tightvnc.com/pvt/0diagnostics/tightvnc-2.8.50-gpl-setup-32bit.msi
      it should not disconnect on UAC.

       

      • junbrave

        junbrave - 2021-08-14

        hi, Anton!
        can you please send me a svn patch which fix the bug?
        i am using the old version 2.8.8, there is nothing wrong for me but the "connection broken when uac window shows".
        so i want to merge the code to old version so i can fix the error, but i can not find the different.

         

        • Anton

          Anton - 2021-08-17

          Hi!
          Line numbers may differ:

          --- a/src/desktop/WinDxgiOutputDuplication.cpp
          +++ b/src/desktop/WinDxgiOutputDuplication.cpp
          @@ -20,6 +20,9 @@ WinDxgiOutputDuplication::WinDxgiOutputDuplication(WinDxgiOutput1 *dxgiOutput, W
          if (hr == DXGI_ERROR_NOT_CURRENTLY_AVAILABLE) {
          throw WinDxRecoverableException(
          _T("Can't DuplicateOutput() because resource doesn't available at the time"), hr);
          + } else if (hr == E_ACCESSDENIED) {
          + throw WinDxRecoverableException(
          + _T("Can't DuplicateOutput() because of access denied error"), hr);
          } else {
          throw WinDxCriticalException(_T("Can't DuplicateOutput()"), hr);
          }

           

          • junbrave

            junbrave - 2021-08-17

            hi, Anton!
            thank you so much for the code! i have fix the bug in 2.8.8! thank you!

            one more thing, if i want to show some thing like "uac window shows on the server machine, remote screen will show when the uac window disapears." in viewer, what should i do?
            any suggestions? thank you again ^_^.

             

  • rdiez

    rdiez - 2020-09-28

    I tested the 64-bit version instead, and it does not crash anymore.

    However, when a UAC prompt comes up with the default Windows UAC configuration, the desktop in Vinagre gets completely black. This is not ideal, because the Vinagre user may not know (or remember) that a black screen can actually mean a UAC prompt.

    Even when I do remember, I normally ask the remote user "you are probably seeing a window asking for permission, right?", which the user tends to confirm. It is a little bump on the road.

    But it is definitely better than crashing. Thanks for the fix.

    Nowadays I try to remember to disable hiding the desktop on UAC on every remote PC, which is yet another step to do. It is still not ideal, because I tend to click on the UAC window, which has no effect. I then remember what is happening, I need to tell the user to click on the 'yes' or the 'no' button. That means that the other user must be there all the time, just in case.

    It would be best if TightVNC could at least offer some tips in this scenario. Instead of black desktop, some message like "desktop not accesible, probably due to a UAC prompt". Or when clicking does not work, a hint like "the remote desktop is not accepting click requests, probably due to a UAC prompt ". If that is at all possible with Windows.

    I do not want to use the service mode. For security reasons, I want the user to manually start the reverse connection for the remote control session.

     

  • Anton

    Anton - 2021-12-22

    Hi.
    I can confirm that signed server binary with uiAccess="true" in manifest running from "Program Files" has access to UAC buttons in "no dim desktop" mode but somethig is broken with control application so i still need some debug.

     

  • uneasy

    uneasy - 2022-07-29

    The bug is back in TightVNC 2.8.63 - crash after UAC prompt (reverse connection). Tested 32-bit version.

    TightVNC 2.8.59 works okay.

     

Log in to post a comment.