Eset/Nod32 is blocking winvnc.exe in Crossloop

I have Eset Smart Security ver. 4.2.35.0.
I installed the Crossloop screen sharing application ver. 2.72 on the computer and installation went without error.
When I tried to run Crossloop and share my screen the process would get to the point of launching winvnc.exe on my computer then terminate a couple of seconds later. I added the winvnc.exe file to the list of exclusions under Real-time protection and the same thing happens. I disabled real-time protection and still the same. I completely uninstalled my security suite and I was able to share my screen just fine using Crossloop.

I would appreciate help with this because many Crossloop users are running in to this problem.

Joe

 

Why would NOD32 kill a process which is not even detected? It sounds very strange for me.
I think it is worthy to try disabling the web-access protection just for the test. In the case you'll get the same undesired behavior, the issue should be reported to the developers of the Crossloop software. They should be able to debug and to discover the error condition which is causing the new version to end prematurely.

 

I have also had this problem and when I add exceptions to the Files, I still get the same problem, blocking the WinVNC_Viewer. It's only when I completely remove ESET ESS/NOD32 from my PC, I no longer have a Problem. I can connect to my customer with Older versions of ESET ESS/NOD32 as long as I don't have ESET ESS/NOD32 on my system, I have recently switched to Microsofts Security Essentials and I'm not having any problems connecting to anyone remotely as I have always done in the past.

 

What kind of exceptions did you add? Exclusion from the real-time scanning or from protocol filtering?
By blocking of the the WinVNC_Viewer did you mean the AV is killing the process or the process is ending because it fails to establish the desired connection?

 

To Begin with, if we knew exactly what was blocking the viewer, I don't believe we would be here trying to ask for help. Our Engineers sent me the following instructions and I followed them.

So far the only work around has been to completely remove ESET ESS. Our Engineers have sent request to ESET Support for help an no response has come yet. I remembered this forum and told our Engineers and Joe Started this post, hoping to get some help.
I have to continue working so I have removed ESET ESS so I can work but I'm happy to add what I know the this thread.

 

Don't know if it will help or not, but I ran into and reported this problem a couple years ago.

Since then, I went into the Advanced Setup | Exclusions and added the Directory of where it is installed (c:\program files\crossloop).

Since adding the entire directory, I haven't had a single problem. I use it on dozens of systems with NOD32 and ESS and with the exclusion added, it never acts up. Maybe worth trying.

 

To troubleshoot the issue I recommend this:
1. Ensure the proper firewall rules are creates in ESS or start with the NOD32
2. Exclude the application from protocol filtering (it is a different thing than excluding from real-time scanning)
3. Disable web-access protection

Please note that exception in the real-time protection forbids the scanner to scan the executable but it's network traffic is not excluded. Those are 2 different kinds of exclusions.

According what was said I can conclude the issue is not caused by the real-time scanner because all of you have confirmed the exclusions were applied and the files are undetected.

Focus on the network part now, tell us if the tweaking the protocol filtering/web access protection and disabling the firewall affects the issue.

Is the Crossloop able to create some kind of debug log file with the events/activities inside the problematic executable? Such information would surely shed more light upon the issue.

There was an similar problem in the past and it was discovered a third party application had a very little timeouts for the socket operations. It was working fine on a computer without NOD32 however when huge files were downloaded (several hundreds of MBs) and NOD32 was active the app was frequently closing the connection. Nobody is able to scan such huge files in a fraction of second and by setting a small timeout the developer was expecting impossible.

 

Why would NOD32 kill a process which is not even detected?

This is exactly what we want to know!

I just tried adding the entire Crossloop directory to the exclusions list- no help.

In Eset Setup I disabled all three items, Antivirus and Antispyware, Personal Firewall and Antispam protection and still have the same problem.

"Focus on the network part now, tell us if the tweaking the protocol filtering/web access protection and disabling the firewall affects the issue."

How do I do this?

 

Here:

 

Thanks danieln!

I added crossloopconnect.exe and crossloopservice.exe to the Protocol filtering excluded applications list by placing check marks in the boxes for those files and it now works.

My question now is why did it not work when I disabled the Antivirus and Antispyware section completely and why is it blocking those files in the first place?

 

I've tried desktop sharing between 2 Windows XP with v. 4.2.35 installed with default settings and it worked fine. What OS on the remote and local computer did you test it with?

 

I'm on an old 450 MHz Pentium 3 with 512 MB RAM running XP with SP3.
Without excluding both crossloopconnect.exe and crossloopservice.exe in the protocol filtering section the viewer fails to launch every time.

 

I am seeing the problem with ESET Smart Security 4, version 4.2.35.0 with signature database 4969 (20100323) running on Windows XP Professional.

CrossLoop 2.72 uses UltraVNC as a plugin. Shortly after CrossLoop connects to port 5910 on localhost via which UltraVNC will communicate using the RFB protocol, UltraVNC drops the connection, without as much as sending the usual version message that is sent at the start of an RFB connection.

This happens when UltraVNC is installed as a service and ESET Smart Security is configured to check for "potentially unwanted applications", as suggested during installation.

When I uninstalled Smart Security 4 and reinstalled without the check for "potentially unwanted applications", CrossLoop 2.72 started working.

Thus it appears that Smart Security 4 is interfering with UltraVNC. What's really confusing about that is that it doesn't even tell me that it found any "potentially unwanted applications". Thus users wouldn't even be aware of a conflict.

I searched Google for information about what ESET Smart Security does when it finds any "potentially unwanted applications" but couldn't find any information.

Smart Security 4 should be fixed to not interfere with any kind of WinVNC that is bundled with CrossLoop, which it clearly is doing (at least on XP) right now.

 

This looks like a false accusation.
Joes831 wrote he excluded crossloopconnect.exe and crossloopservice.exe from the protocol filtering and it started to work, he did not mention excluding another process such UltraVNC. How did you come to the conclusion the UltraVNC is the process which is being interfered?

Misleading conclusions does not help anybody to find proper solution of the issue.

Smart Security 4 is being blamed, no problems with the v3?

I have been using RealVNC and TightVNC software for a long time together with the ESS without any problem.

The NOD32 is not preventing the software to execute and it is not blocking it's network communication. Marcos tried CrossLoop and ESET software with the default settings (note: No Exclusions) and it was working OK together. This is a proof it is able to work.

It was confirmed it was working for others without applying any protocol filtering exclusion. It is another proof the network traffic is allowed.
Some of you have said the situation improved after excluding files/folder from the real-time file system protection. The only effect of such exclusion is a few milliseconds faster startup/opening of the excluded files/executables. Should such a little delay make a stable application to stop working?

Marcos told me that based on the past experiences there could be a problem in some third party software running on the computer. Sometimes remaining parts of the previous AV are causing problems. The log from the SysInspector (it is included in the ESS4) is useful to find it. You can repeat the tests on a clean Windows installation + CrossLoop and ESET. Try to perform the tests on some modern hardware.

I will wait for the results of the testing in order to confirm/deny the possibility of the third party problem and for the SysInspector log (from machine where the problem is always reproducible).

 

I think it is just coincidence and I think the enabling/disabling the PUA does not make a difference at all in this case. Are are able to reproduce it several times on different machines?

 

Thanks for your reply!

Well, the problem is occurring with UltraVNC, not with RealVNC or TightVNC. One major difference between those two and UltraVNC is that the latter can operate in service mode, which is required to be able to cope with User Access Control (UAC) prompts under Windows Vista and Windows 7.

TightVNC and RealVNC don't run in service mode.

Also, if CrossLoop is reconfigured to not use UltraVNC in service mode, that also allows it to work. This again suggests that it is an interaction between service mode UltraVNC and ESS.

Was that on XP or on Vista/Win7? When I first tried it on Vista it also worked. Then I tried it on XP and it didn't.

Was it with or without "Potentially Unwanted Application" checking?

 

Facts;

Crossloop versions 2.60 and older installed and used TightVNC (non-service mode).
Crossloop versions 2.70 and newer install and use UltraVNC in service mode.
Eset does not cause Crossloop a problem when using ver. 2.60 or older.
Eset did not cause a problem after the release of Crossloop versions 2.70, 2.71 and 2.72.
I started hearing about a problem with Eset from customers approximately 2 weeks ago.
I have heard from many Eset users that are not able to use Crossloop without uninstalling Eset.
This problem did not correspond with the realease date of any of the Crossloop versions.
We can repro the problem on several XP computers with Crosloop version 2.72 and Eset security ver.4.2.35.0 with the latest updates.
The problem happens when the XP machine with Eset is on the Share tab and we attempt a connection.
Crossloop creates a connection and launches UltraVNC in service mode (winvnc.exe tries to run on the Share computer).
Winvnc.exe fails on the shared computer with Eset so the connection terminates.
Placing our entire Crossloop directory in the real time protection exclude list did not help.
Placing crossloopconnect.exe and crossloopservice.exe in the exclusion list in Eset's Protocol filtering section made
it work. These files were in the list and I placed a check in the box.

No other security software causes this problem for Crossloop.
This problem happens without any warnings or options to allow.
You have already lost business because of this and so have we.
One of our top Crossloop experts (Crossloop experts are independent technicians) has been using Eset security on all of his computers and all of his customer's computers. He is one of the customers you have already lost because of this problem.

Please give this problem immediate attention because it is costing Eset and Crossloop money!

If you have any questions you can reach me at customersupport@crossloop.com.

Thanks,
JoeS

 

I am one of those people currently having Issues and I have been working with the Crossloop Engineers to discover some resolution to fix the problem. I've taken the tips our Crossloop Engineers have offered me, and the Other tips offer by other posters here. This Post was created to find help with a problem, and not draw out any attitude from others. I have Completely Removed ESET ESS from my personal Systems and replaced them with Microsoft Security Essentials. I am no longer having any Issues, with any version of Crossloop. That Tells me, ESET must be the Problem. If there is no interest in fixing the Issue, then I am forced to Remove ESET ESS from the 16 PC's have direct Control over and all of the Customers I influence.
This Saddens me as I have been a big supporter of ESET since I Discovered it from Leo Laporte. (The Radio Tech Guy on KFI640 Am Radio) Leo Laporte Dared me to remove Norton Security try it NOD32. I found things that Norton had Missed. I switched to NOD32 that day and I have promoted ESET Since that day. Now it looks like it is time to change again and change all of my customers. To Read Attitude in danieln's post does not set well with me. I can find other Anti-virus Programs and the attitude does not help anyone or anything. It's completely uncalled for. Please Consider, if you don't have Customers, what happens to your job.

 

Meanwhile when I was waiting for the answers and the requested informations I decided to find a reliable way and circumstances how to make the issue to be always reproducible.

I tried many attempts to establish the sharing. Sometimes it worked without excluding anything. In other cases disabling all modules and firewall + exclusion in the protocol filtering did not help the viewer to start.

The crossloopconnect.exe (from the free version) was crashing quite often in my tests. First time it crashed alone when I was by the second PC during an connection attempt. Quite often it crashed just upon the application startup or a few seconds later. The crashed were reproduced also with the disabled modules in the ESS, disabled firewall and the protocol exclusion enabled.

The screenshot from the one of the crashes:

 

I went back and tried it again and you're correct, disabling PUA does not reliably enable CrossLoop connections with ESET, unless CrossLoopConnect.exe and CrossLoopService.exe are added to the exclusion list for Protocol checks.

As to the crashes you observed, we are not seeing these in our testing or have them reported by our customers.

 

The mystery explained

Here is an update on what we've found about ESET and CrossLoop.

The problem was indeed related to protocol filtering in ESET. Here is why CrossLoop failed when ESET was monitoring its TCP/IP connections, unless CrossLoop was manually exempted from checking:

CrossLoop 2.72 uses the UltraVNC winvnc.exe binary as a plugin, which it launches and then connects to it to provide secure, encrypted VNC sessions for a remote viewer (standard VNC sessions are unencrypted). After it execs the plugin, it waits a short interval and then attempts to connect to the server port on which WinVNC listens for VNC viewer connections.

We don't know how soon after being launched WinVNC will be ready to accept connections, but if we attempt a connection and the port is still closed, the connect function returns an error and we simply wait a little and try again, until WinVNC is ready for us.

The problem is that ESET is accepting connects on the VNC port (5910 in this case) if no VNC is present. When we then try to receive the first message from what looks like WinVNC but isn't, ESET drops the bogus connection on us.

Because they first accepted a connection, our software was tricked into believing that the WinVNC had come up and subsequently treated the dropped connection as a WinVNC shutdown, which is why remote sessions immediately terminated. Because the connect itself looked "successful" our code never went through the retry polling to wait until the real WinVNC came online.

We have developed a workaround which we're now testing for the next release, but this quirky behaviour by ESET's protocol filtering has wasted a lot of our time and I can't help wondering how many other programs it may break.

I recommend you fix the problem and don't accept connections on local ports unless an application has done a listen() call for that port, which is the normal behaviour for TCP/IP.

 

Hello,

Any progress on this issue? Here in Czech Republic is ESET product very often used (ESET is Slovak company -former czechoslovakia).

I tried to identify source of problem with help of tcpview, procexp and diagnostic options in ESET ESS and I can confirm that critical issue is somewhere on launch of winvnc and start of TCP connection on 5910 port.

It is interesting that if just after failed launch of winvnc (I can see it on procexp) I run winvnc manualy I will get picture on VNC cilent on remote side!!!

I had problems that picture freezes shortly , but it can be made by wrong start parameters.

I am not as sure that problem source is totaly on ESET side.
It seems that crossloop makes something very uncommon, what interferes with port monitoring way used by ESET but may be also some other security tools - I got similar troubles also with AVAST5.

Sincerely Zdenek Hladik

 

After several tests on two other machines (XP,ESS):

Scenario:

after establishing of Crossloop connection - after confirming access on called side TCPVIEW there shows SYN_SENT to 127.0.0.1:5910 from CrossLoop, probably VERY FAST(!) reopening of connection - TCPVIEW refresh time is about 2s and it blinks red. No evidence of running winvnc (may be very quickly crashed, but probably not restarted.)

Usually called side crossloop timeouts after 2 minutes. calling side minimizes crossloop and starts session timer but does not launch vncviewer window

But if I run manually WINVNC.EXE from

"%userprofile%/Local Settings/Application Data/Crossloop"

voila! IT does help! Remote window on caller site shows. On TCPVIEW on called PC I can see: connection 127.0.0.1:xxxx -> 127.0.0.1:5910 from crossloop to winvnc process. and keyboard/mouse are also OK.

So I don't understand what is as hard on workaround via crossloop process. It probably does not suppose that winvnc can crash by some reason? But simple retry of winvnc if there is no running instance probably helps.

I understand that you want establish VNC session as quick as possible, but may be on some PC configurations (low power hw, slow antivirus or fireall?)
there it is probably not reliable way to run untravnc desktop binary? so retry of launch loop after several seconds will be necessary?

Please if your workaround version is ready release it ASAP. We have lot of clients with this type of problem. Or I will be even happy if there wil be some BETA, I have just now several PCs with this type of problem so I can test possible workaround on them (and tommorow I will do test of manual start)

TNX
Zdenek Hladik

 

Hello,

I believe that next ˇand some previous msgs are now off topic in this forum because it seem problem is not in ESET product. But may ne it is good to know for NOd experts also.

I found source of problems on localized WIN XP case and made fix script. Look bellow on thread on Crossloop forum.

Problem was not in Firewall/protocol filter but in broken path for starting winvnc service.

http://forum.crossloop.com/showthread.php?t=654

 

Thanks for looking into and finding the fix. If your read from the top of thread, in of the posts, there was a mention that removing ESS helped the issue. From what I understood from your fix that shouldn't have made any difference