Server just stops working

[gneuner]

Hi.

I am using UVNC 1.3.8.1 64-bit to remotely administer a number of Windows 10 machines. In the span of a month I've now had the UVNC service simply stop responding on 2 different machines. Apparently it can occur with no warning ... a machine I could access yesterday did not respond today.

The service executable remains running, and a local user can initiate a call OUT to a remote viewer, but their machine will not respond to incoming connection requests. Connections are not being rejected - the machines simply don't answer.

On all machines, Windows is configured to restart the service executable if it crashes, and I have checked the UVNC settings. But the executable apparently is not crashing, and the settings all are fine.

Rebooting the machine does not resolve this problem. Once it happens, the only answer I have found is to reinstall the UVNC software (which thankfully does not erase settings or security certificates). Thankfully the first machine it happened to had a fairly technical user, but still it took considerable time troubleshooting just to discover that they _could_ still call out to me.

Some of these machines are hundreds of miles away and some have quite non-technical users. Just talking some of them through initiating remote viewing for me would be a chore. I didn't have any real issues with 1.2.4.0. I don't want to have to downgrade - 1.3.8.1 is significantly faster and smoother - but I can't have servers going unresponsive.

Has anyone else run into this? If so, did you solve it?
Thanks,
George

[Rudi De Vos]

The machines simply don't answer:

It looks like it's not longer listening on port 5900 or wahtever you use.
*Is the viewer still working local, can you connect to localhost
*use tcpview
https://learn.microsoft.com/en-us/sysin ... ds/tcpview
this should show or not if winvnc is listening
winvnc.exe,6060,TCP,Listen,0.0.0.0,5800,0.0.0.0,0,7/11/2022 17:49:49,winvnc.exe,,,,
winvnc.exe,6060,TCP,Listen,0.0.0.0,5900,0.0.0.0,0,7/11/2022 17:49:49,winvnc.exe,,,,

Rebooting the machine does not resolve this problem:

This is realy strange,
Special because a reinstall of vnc doesn't touch any setting, it keeps all old settings and reuse them after reinstall.

When you look at mslogon.log ( same folder as winvnc.exe) is there an entry for your connection attempt.
If you activate the logging, do you see anything in the log when you try to connect.

When you start winvnc manual, does this allow to connect.

Is it possible that some other software blacklist winvnc.exe for listening.
When this works on the exe, replacing him could explain why a reinstall works.

[gneuner]

It looks like it's not longer listening on port 5900 or whatever you use.
*Is the viewer still working local, can you connect to localhost

Unfortunately, I didn't think to try a loopback connection. I keep that disabled normally because some people have been freaked by the resulting "hall of mirrors" effect - they think they broke something and panic if/when they can't figure out which of the many "windows" to close to stop it.

*use tcpview
https://learn.microsoft.com/en-us/sysin ... ds/tcpview
this should show or not if winvnc is listening

This I did check. According to tpcview, the server was active and listening.

When you look at mslogon.log ( same folder as winvnc.exe) is there an entry for your connection attempt.

Yes. There is a pattern - 3 connect receives followed by a disconnect, all with the same timestamp [be nice if it included seconds]:

7/11/2022 7:28 Connection received from <my.ip>
7/11/2022 7:28 Connection received from <my.ip>
7/11/2022 7:28 Connection received from <my.ip>
7/11/2022 7:28 Client <my.ip> disconnected
7/11/2022 7:28 Connection received from <my.ip>
7/11/2022 7:28 Connection received from <my.ip>
7/11/2022 7:28 Connection received from <my.ip>
7/11/2022 7:28 Client <my.ip> disconnected
7/11/2022 7:29 Connection received from <my.ip>
7/11/2022 7:29 Connection received from <my.ip>
7/11/2022 7:29 Connection received from <my.ip>
7/11/2022 7:29 Client <my.ip> disconnected
7/11/2022 7:29 Connection received from <my.ip>
7/11/2022 7:29 Connection received from <my.ip>
7/11/2022 7:29 Connection received from <my.ip>
7/11/2022 7:29 Client <my.ip> disconnected
7/11/2022 7:30 Connection received from <my.ip>
7/11/2022 7:30 Connection received from <my.ip>
7/11/2022 7:30 Connection received from <my.ip>
7/11/2022 7:30 Client <my.ip> disconnected
:

which correspond to my attempts to connect. But on my machine I was seeing only the viewer's connection dialog, and after several seconds the viewer would error out with "Failed to connect to server !"

If you activate the logging, do you see anything in the log when you try to connect.

Didn't try that ... I didn't think of it the 1st time, and the 2nd time the user wanted to get working so there was little time for exploration of the problem.

When you start winvnc manual, does this allow to connect.

The service is still running, so the user gets an error trying to start it (again) manually. They can, however, manually initiate a remote session to me (assuming I start my viewer in listen mode).

Is it possible that some other software blacklist winvnc.exe for listening.
When this works on the exe, replacing him could explain why a reinstall works.

In general, yes - I have little control over what the users may do apart from knowing that most of them would be afraid to do anything themselves.

However, the incident that prompted this thread was me logging into a machine late Sunday evening to initiate a somewhat lengthy backup job that was to be done overnight, and then NOT being able to log in again early Monday morning to check on it. During that time the user was not present, nothing critical (Windows, antivirus, etc.) got updated, and I'm pretty certain I didn't do anything myself to cause it.

Aside: I am aware that today (Nov 8) is "update Tuesday". Generally I don't allow Windows updates to be done independently - I keep them postponed, monitor the tech news, and install them only after some time has passed and I'm reasonably confident that they aren't causing widespread problems. Similarly, all the machines run Avast rather than Defender and Windows firewall, so I know also when that is updated.

The 1st incident - about a month ago - was completely different: the user called and asked me to troubleshoot a problem with MSOffice. I had not logged into that machine for some time and so could not account for things like software updates. That particular user is fairly technical and self sufficient and only calls me for serious problems. I am reasonably confident that she did nothing that could have caused UVNC to misbehave. In particular, this user I trust to install programs and software updates herself ... I just tell her it's OK to do it.

George

[Rudi De Vos]

Installed 1.3.8.1 and was testing with a test viewer 1.3.9 dev3 , this generate identical the same logging.
( i know that thereis a compatibility issue with dev 3)
mslogon show the same as in your case.
recv
recv
recv
disconnect
recv
recv
disconnect
...



Then i connected using viewer 1.3.9 dev 5, that seems to work and i was able to connect.

Please test with this new viewer, you never know.
This is a local change, so easy to test.
But then it should always fail...Strange problem.

[gneuner]

Sorry for delay - I don't seem to be receiving notices when someone posts.

Installed 1.3.8.1 and was testing with a test viewer 1.3.9 dev3 , this generate identical the same logging.
( i know that thereis a compatibility issue with dev 3)
mslogon show the same as in your case.
recv
recv
recv
disconnect
recv
recv
disconnect
...

Then i connected using viewer 1.3.9 dev 5, that seems to work and i was able to connect.

Please test with this new viewer, you never know.
This is a local change, so easy to test.
But then it should always fail...Strange problem.

I'm not sure what exactly I can "test". I've only encountered this connection problem twice, and the two incidents were separated by almost a month. I don't know how to force it to happen, so I would need to wait until it occurs again spontaneously to see if using a new(er) viewer changes anything.

George

[gneuner]

Just had another 1.3.8.1 machine stop responding. I tried the 1.3.9dev5 viewer as suggested with no luck ... it fails just as 1.3.8.1 does.

I had the user verify with tcpview that the server was listening. She sent me a screen capture that showed it was active and marked as listening. I don't know how to upload a locally hosted image here, but it would only illustrate what I've already written.

I also had the user activate loopback connection and try connecting that way. This produced varied results: initially it didn't work - neither by machine name nor by "localhost". Then I had the user reboot - and then it DID work. However I still could not connect remotely.

I had the user activate debug logging from the administrator properties, but nothing appeared in the WinVNC.log following my attempts to login remotely. It's like my login attempts were not even happening.

So finally I had the user reinstall UVNC ... presto, it worked again. ??????

Now 3 times in a month.
George

[VNCHELP890]

Windows Firewall?

[gneuner]

Windows Firewall?

All the machines use Avast - Windows firewall is disabled.

So far I can't find anything to explain this. My one "outside the box" thought is that perhaps jumping directly from 1.2.4.0 to 1.3.8.1 introduced some instability on some of the machines. [I've done big jumps like that before, but you never know.] Because reinstalling 1.3.8.1 seems to fix (at least temporarily) the problem, my "solution" has been to proactively reinstall everywhere.

We'll see how long that works.
George