BitDefender prevents VNC Server "connection test" from working
I have already contacted the RealVNC support people about this and opened a support ticket with them, and they have been able to duplicate my issue. The problem is that their "connection self-test" functionality FAILS WHEN BITDEFENDER IS INSTALLED, and WORKS WHEN BITDEFENDER IS UNINSTALLED!! The mystery here is that the product itself works perfectly in its normal connection functionality. And it is only their special diagnostic "connect self-test" (designed to prove that the product is installed correctly and functioning properly) which DOES NOT WORK PROPERLY!!
They are themselves now working to try and determine what is different between VNC Server's "connection self-test" and "normal operation" which could account for any difference caused by a separate software product (no doubt by the Firewall of BitDefender), but haven't figured it out yet. However like me in trying to prove that it is BitDefender which is responsible they have also tried to FULLY DISABLE ALL FEATURES OF BITDEFENDER, using the Protection interface (i.e. deactivating every available sub-feature that can be deactivated, including Firewall, etc., ) and the problem still occurs. In other words using all the available UN-CHECK items available they STILL CANNOT TEMPORARILY FULLY DISABLE BITDEFENDER. Their VNC Server "connection self-test" will not work as long as BitDefender remains installed in any way, shape, or form, no matter how little of is presumably still left installed and operational even after un-checking all available boxes.
The only way to restore VNC Server "connection self-test" to work properly is to FULLY AND COMPLETELY UNINSTALL BITDEFENDER!!!
Once BitDefender is COMPLETELY UNINSTALLED then once again VNC Server "connection self-test" functions perfectly, clearly pointing to BitDefender as the culprit responsible for this issue. And no matter the fact that in theory the product is fully and temporarily disabled by UN-CHECKING all of the "protection" sub-features, obviously there is still some basic underlying BuitDefender functionality which remains fully active and operational and has NOT BEEN DISABLED BY ME, THE USER, which is responsible for the VNC Server "connection self-test" malfunction!
In other words IT IS IMPOSSIBLE TO DISABLE BITDEFENDER TEMPORARILY, WITHOUT COMPLETELY UNINSTALLING IT!!!
This is the same story as I've already seen with BitDefender in another case (reported here, and also through recently opened BitDefender support ticket 2019121620110002 which is still open at this moment) where BitDefender interferes with the successful installation of software product Free Commander XE and instead abends with an "access violation in module ATCUF32.DLL". Same as with the story with VNC Server, attempting to temporarily fully disable BitDefender using the Protection interface and un-checking everything, it apparently DOES NOT FULLY DISABLE BITDEFENDER COMPLETELY!! In fact something remains active in the basic BitDefender functionality regardless, which apparently is sufficient to make it responsible for this ATCUF32.DLL failure that still occurs. The only way to eliminate this failure is to FULLY AND COMPLETELY UNINSTALL BITDEFENDER!!
This is ridiculous. It should not be required that the product be uninstalled just to prove that it is BitDefender IS THE CULPRIT and IS RESPONSIBLE FOR THE 3RD-PARTY SOFTWARE PRODUCT MALFUNCTION OR FAILURE!!! Of course the problem IS IN BITDEFENDER, not the 3rd-party software product, that has now been proven in two separate issues of mine: (a) cannot install software product Free Commander XE because of the access violation in ATCUF32.DLL, and (b) cannot run the VNC Server "connection self-test" which is part of the RealVNC software product.
This is now for me the second currently active (a) actual abend failure in a BItDefender component itself, or (b) failure in a 3rd-party product caused by BitDefender being installed, which has been EXPERIMENTALLY PROVEN TO BE 100% DIRECTLY RELATED TO OR CAUSED BY BITDEFENDER BEING INSTALLED! The problems are both due to BitDefender being installed, and will only be fixed when the underlying causes in BitDefender are corrected AS THEY OBVIOUSLY SHOULD BE.
In the meantime there appears to be NO WAY TO TEMPORARILY DISABLE BITDEFENDER WHICH FULLY INHIBITS IT FROM FUNCTIONING!!! The only thing us users can do is to FULLY UNINSTALL THE PRODUCT, which seems to be the only way to fully inhibit it from functioning!! RIDICULOUS!!
So, to summarize my current situation:
(1) BitDefender currently "breaks" the successful install of software product Free Commander XE, resulting in an "access violation in module ATCUF32.DLL". Ticket 2019121620110002 opened with BitDefender support.
(2) BitDefender currently "breaks" the "diagnostic connection self-test" of the VNC Server product, even though the normal operation of VNC Server is unaffected. No support ticket yet opened with BitDefender support, but there IS a ticket opened with RealVNC support. They have duplicated the failure caused by BitDefender, but have so far not determined exactly what makes "connection self-test" functionally different from "normal operation" in order to account for what might be the interference resulting from BitDefender.
(3) Both failures have been experimentally PROVEN TO BE THE RESULT OF BITDEFENDER BEING INSTALLED.
(4) Both failures disappear fully when BitDefender is fully uninstalled.
(5) It is impossible to fully disable BitDefender TEMPORARILY by un-checking all sub-features shown in Protection. Only by FULLY UNINSTALLING BITDEFENDER is it actually possible to 100% disable 100% of the BitDefender functionality. If the product remains installed, even un-checking all of its features leaves fully operational some residual basic underlying functionality which seems to remain fully responsible for both of my current issues.
THERE NEEDS TO BE A WAY TO TEMPORARILY BUT FULLY 100% DISABLE 100% OF ALL BITDEFENDER FUNCTIONALITY, WITHOUT REQUIRING FULL UNINSTALL OF THE PRODUCT!!
And whatever is in BitDefender that is CAUSING BOTH OF MY 3'rd PARTY PRODUCT FAILURES NEEDS TO BE FIXED!! I need to be able to install Free Commander XE as they intended, and I need to be able to run the "diagnostic connection self-test" of VNC Server as they intended.
As it turns out I have an operational workaround for the Free commander XE install failure issue. And the "connection self-test" of VNC Server is not critical, since the product itself actually works 100% perfectly even if its built-in "connection self-test" fails. But both issues have been 100% proven to be caused by BitDefender being present in the environment, which apparently cannot be eliminated by disabling any or all of the available BitDefender Protection check-options, but only by fully uninstalling the BitDefender product completely.
Ridiculous.
Comments
-
I reported this problem to RealVNC back in December, same time as I reported it here. They have been attempting to determine why their connection diagnostic self-test fails, whereas ordinary normal remote connection to the exact same PC works, with BitDefender present. Presumably the BitDefender firewall is the same, but there clearly is something slightly different they must be doing in the self-test that is triggering BitDefender firewall to block self-test whereas it doesn't block anything normally.
They have been unsuccessful in figuring out what's going on. They of course know what is the architecture of the connection self-test, but that series of steps is really no different than a normal remote connection to this host PC... except that it is SELF-GENERATED. In other words both the "remote client" (attempting the connection) and"target host" (object of the attempted connection) are one and the same machine. This contrasts with ordinary real world remote connectivity, where the "remote client" is say one PC in Los Angeles and the "target host" is a second PC in Florida.
Per Jack (the technician at RealVNC in the UK who I have been working with on this), "The connection test is essentially reaching out to a site we host, and then reverse connecting to see if the connection can be made. This is a little different to a typical VNC connection, but we cannot determine why Bitdefender isn't liking it."
But I have described above that subtle difference, which is that both the source and object of the connection self-test are the same single physical machine, whereas normal connections involve two different physical machines. It may well be that BitDefender considers this connection self-test "out and back" perhaps a form of malware, or maybe a suggestion of something going on that might be considered malicious. Don't know.
Now what has been really frustrating to RealVNC is that they, like all of us, cannot actually fully disable BitDefender Firewall. Even though they have turned off the "master switch" on the Protection page, that doesn't seem to actually disable firewall!!! It still interferes, on a major level, as if it were still partially active. The only way to truly eliminate the interference of BitDefender Firewall is to UNINSTALL IT COMPLETELY!! That of course is ABSOLUTELY RIDICULOUS, but as most of us already know that is simply a fact. You cannot temporarily disable firewall through the Protection master switch, even though you'd think that was what it was for. You have to uninstall the product completely in order to eliminate firewall's functionality. The master switch DOES NOT ACTUALLY DISABLE FIREWALL 100%... because of some crazy architectural decision which makes no sense whatsoever. Perhaps it's a program bug that needs fixing???
So, I ask the BitDefender technicians who are hopefully reading this thread. Is there any special handling or interpretation as malicious, of what RealVNC is doing with their diagnostic connection self-test, i.e. both source and target for the connection attempt in the same single PC? IT DOESN'T WORK WHEN BITDEFENDER IS INSTALLED, and of course works normally when BitDefender is uninstalled. Clearly the issue is something BitDefender is doing.
If you don't provide a suggestion here on this thread, I would like to open a problem ticket. I can get the RealVNC people to provide you with a temporary license to install and use their software so that your developers can chase this down in your lab.0 -
Well, I just performed a re-test of this RealVNC connection diagnostic self-test, expecting to then start building the package of materials for me to submit to you to open a ticket. Imagine my surprise when the self-test ran successfully, instead of failing as it has been doing!!
I've now tried it on four different machines and it's now working successfully on all four! would say that your developers must have secretly fixed something very recently which was responsible for this. Even though you never responded to my initial post of this thread, whatever was actually responsible for the symptom has now seemingly been corrected.
Even more surprising, my original post talked about being unable to prevent the symptom simply by un-checking firewall in the Protection tab. I could only prevent the symptom by totally uninstalling the BitDefender product, implying that even when firewall is un-checked it's actually still active to some degree. Well, whatever has been recently (and secretly) fixed that now allows RealVNC self-test to work again, miraculously it doesn't matter whether firewall is checked or un-checked!!! No matter which way that master-toggle switch is set, the RealVNC self-test still works!!
Looks to me that the correction to whatever was causing the symptom has now made BitDefender behave totally transparently to RealVNC self-test, as it should be doing. There is nothing the self-test is doing that is in any way conceptually different from an outside client machine trying to connect remotely to a RealVNC host machine. There should never have been any involvement of BitDefender at all with self-test, as it permits ordinary client/host connections without any interference. Thus there really should have never been any difference no matter that the firewall master switch is on or off. And now things work properly as they should.
Bottom line: something has been changed. This problem no longer occurs. You have very recently fixed whatever was responsible for this failure.
This thread is now "solved".
0 -
Hello,
Glad to hear the situation was solved!
Thread locked.0
