Zombie process

[Jikaro]

Recently I noticed that under certain conditions, UVNC will not allow me to log back in after closing the server remotely and then restarting it (via a daemon). I tried upgrading to the most recent version (1.2.0.1) but the problem persisted. Upon investigation, I found that when this occurs, there is a zombie winvnc.exe process that appears to be preventing the new process from allowing access. For some reason this bug occurs more often when I attempt to close the server from a connection outside the local subnet. When I attempt to connect to the new process, the authentication completes, then UVNC immediately closes connection.

Recreation steps:
1) Start UVNC server as a non-service task.
2) Connect from a remote machine. I'm using my Android phone with RealVNC. (When I connect locally (within the subnet) the bug is infrequent, but when I connect via my external IP the bug occurs most of the time.)
3) R-Click the UVNC task tray icon and select 'Close VNC connections'.
4) Check task manager - if there's a winvnc.exe process resident then the bug has occurred. If not, retry.
5) Do not kill the process.
6) Start a new instance of UVNC.
7) Try to connect.

This is frustrating because I use my daemon to start UVNC and then connect to it, then close it when I'm done. When the bug triggers, I have no way of reconnecting apart from going back home and terminating the rogue process manually.

[Rudi De Vos]

I think i found it.... deadlock server when connected via gprs.. damm slow but nice for testing.
Test exe for download... please post result.

Removing tye deadlock possible introduce a memory error in some cases.
Please play with it.

http://www.uvnc.eu/download/1201/winvnc ... k_test.zip

[Jikaro]

I'll check it out. Thank you.

[Jikaro]

Okay, I tried the x64 version, but the problem persists. The process does not close correctly under certain conditions. The difference in this case was that trying to start a new process caused a dialog box to appear which said that UVNC was sill running. The x86 version is generating the same behavior as the original.

I've found that I'm able to reliably recreate the problem in this way (even within the subnet):
1) VLC is playing back a video on the PC.
2) Android program 'Remote for VLC' is running its widget, which is connected to VLC on the PC.
3) Android 'VNC Viewer' connects, then uses the r-click menu of the UVNC task-tray icon to close UVNC.

After that I open task manager and the process is still present. In the release version and the x86 version I'm able to start a new instance, but it won't accept connections correctly.



The zombie is the one with higher memory use.

[Rudi De Vos]

It's not simple to repeat, even on a gprs or modem.
Without repeating it's a little trial an error.
Next test

http://www.uvnc.eu/download/1201/winvnc_locktest2.zip

[Jikaro]

Thanks. I'll take a look.

[Jikaro]

This appears to have corrected the problem. I can create the bug in the release version, then close that process and use either of the test versions in the same situation and they both close the process correctly.

Thanks!

[koepie]

I have the same problem with the Zombie Process.

And i solve the problem through replace the winvnc exe with the winvnc32.exe from http://www.uvnc.eu/download/1201/winvnc ... k_test.zip ?