Hi! We have some ppl using Viscocity with windows 11. About 2 weeks ago some of us had the VPN stopped working with the error
“CreateFile failed on TAP device via management.” I belive i had the code 1 or -1 then.
We reinstalled the driver and upgraded to the latest version 1.11.5 (1842) and it worked. I believe we had diffrent oled versions of Viscocity.
Now the connection problem occured again for alteast 3 users. Where i had errnr: 10035. Dont know what the others have.
We run W11 and eset Endpoint Security. In Device management we all can see the network driver Viscosity Virtual TUN Adapter.
Any help for us to skip the reinstall step every other week wold be aprititated!
Update: The network adapter stops working when I switch IP-adress (wifi or phone wifi). I can however get around this by uninstalling the Network adapter and then connect via Viscocity.
Here is the log:
nov 20 7:39:40 PM: State changed to Connecting
nov 20 7:39:40 PM: Viscosity Windows 1.11.5 (1842)
nov 20 7:39:40 PM: Running on Microsoft Windows 11 Home 64 bit
nov 20 7:39:40 PM: Running on .NET Framework Version 4.8.09221.533509
nov 20 7:39:41 PM: Checking reachability status of connection…
nov 20 7:39:41 PM: Connection is reachable. Starting connection attempt.
nov 20 7:39:41 PM: Interface Type: ViscTunTap
nov 20 7:39:41 PM: Bringing up interface…
nov 20 7:39:41 PM: OpenVPN 2.6.14 Windows [SSL (OpenSSL)] [LZO] [LZ4] [AEAD]
nov 20 7:39:41 PM: library versions: OpenSSL 3.0.16 11 Feb 2025, LZO 2.10
nov 20 7:39:41 PM: Valid endpoint found: ####:udp4
nov 20 7:39:42 PM: TCP/UDP: Preserving recently used remote address: [AF_INET]####
nov 20 7:39:42 PM: UDPv4 link local (bound): [AF_INET][undef]:0
nov 20 7:39:42 PM: UDPv4 link remote: [AF_INET]#####
nov 20 7:39:42 PM: State changed to Autentiserar
nov 20 7:39:42 PM: WARNING: this configuration may cache passwords in memory – use the auth-nocache option to prevent this
nov 20 7:39:42 PM: [Akustikverkstan-VPN] Peer Connection Initiated with [AF_INET]####
nov 20 7:39:42 PM: State changed to Connecting
nov 20 7:39:44 PM: Awaiting adapter to come up…
nov 20 7:40:29 PM: Unable to repair interface, cancelling connection attempt.
nov 20 7:40:29 PM: Please try the following if this problem persists: Troubleshooting Viscosity Problems (Windows) - SparkLabs
nov 20 7:40:29 PM: CreateFile failed on TAP device via management.: Operation would block (WSAEWOULDBLOCK) (errno=10035)
nov 20 7:40:35 PM: OpenVPN has exited. Exitcode = -1
nov 20 7:40:35 PM: State changed to Disconnected
The typical cause for this error is Endpoint Security Software (such as security monitoring software, antivirus software, firewall software, some VPN clients, enterprise management software, etc.) attaching to the VPN network interface and blocking it from activating.
We have been seeing this issue crop up more just recently though (despite no changes to Viscosity), so there may be a updated third-party driver or Windows update that has recently come out that is causing more clashes that usual.
I recommend running through the following steps:
Check installed Endpoint Security Software. Such software includes things like Antivirus software, firewall software, device management software, DNS proxies, certain networking tools and drivers, and some other VPN clients. Some endpoint security software (typically installed on enterprise machines) can be quite aggressive and block or inject itself into system processes, which can cause issues. You mention you have ESET Endpoint Security installed, so I would recommend starting with that.
If any such software is installed, try temporarily disabling it or whitelisting/excluding Viscosity and see whether the issue persists. You may need to uninstall/reinstall Viscosity after uninstalling/disabling any such software.
Check for any installed Windows filters. Despite the name, Windows network filters are not always about filtering network traffic: basically they’re network add on layers used by some third-party software such as network security software, firewall software, some other VPN clients, some WiFi cards, some cellular and USB ethernet adapter drivers, network packet inspection tools, etc.
Try temporarily uninstalling or otherwise disabling any such software and see if you get the same problem. Depending on the software, you may be able to configure it not to attempt to attach to the VPN network interface.
While a third-party filter isn’t necessarily a problem, generally when a VPN network interface is unable to be activated they are the cause. Some third-party filters may not be correctly designed to handle a virtual network interface, and fail to load, causing problems for the network interface they are attached to.
Try using the latest beta version of Viscosity. The current beta version has updated signing on its driver, which may aid compatibility if something is blocking the driver due to the prior certificate: Using Viscosity Beta Versions - SparkLabs
If none of that helps, while the VPN connection isn’t in a working state please try the following steps, which may help diagnose what is going on:
Open the Device Manager control panel. The easiest way to do this is to type “Device Manager” into the Search box in the Start menu, or by typing “devmgmt.msc” into the Run dialog.
Expand “Network adapters” and find the Viscosity network adapter for the VPN connection (it should be named something like “Viscosity Virtual TUN Adapter”.
Double-click on it to open up Properties. In the Device status section it should say “This device is disabled (Code 22).
Click the “Enable Device” and follow the prompts. If an error appears, any pop-up dialogs appear, or the process hangs please let us know what it is. (Please note that this just enables the underlying device, the network adapter will still appear disabled if there is no VPN connection).
If it enables fine, it should have the status “This device is working properly”. Try connecting the VPN connection again and see how you get on.
If enabling the device allows you to connect again, but it only works once or stops working, then try the following (while the VPN network adapter is still in a broken state):
Open Device Manager again, and open Properties for the VPN network adapter.
Go to the Details tab, and then from the Property menu select “Device instance path”, and make note of the Value. It should be something like “ROOT\NET\0000” (the end number may vary).
Open the Command Prompt as an Administrator. The easiest way to do this is to search for “Command Prompt” in the Start menu, then right-click on the Command Prompt result and select “Run as administrator”.
Enter the following command and press enter. Replace “ROOT\NET\0000” with the correct “Device instance path” from step 1 if it differs (but leave the @ character). "C:\Program Files\Viscosity\Resources\Drivers\tapinstall.exe" enable @ROOT\NET\0000
If an error message appears or the process appears to hang then please let us know any output. If the process hangs, try leaving it for awhile and see if it’s eventually able to enable the adapter. If you see "1 device(s) are enabled”, try connecting the VPN connection and see if it works.
Hi AAron and tnx for the detailed explanations. I have not solved this yet.
Here is an update:
I am searching my ESET endpoint security for instances where Viscocity is beeing blocked but I hahent found much yet.
I have no trouble activating Viscosity Virtual TUN Adapter while the connection doesnt work. This however does not change anything. I still cant connect.
I am currently going around this by uninstalling the Adapter. I can then launch Viscocity and connect to my VPN seemless for the duration.
I belive the error occur when the computer is restarted or entering sleep state and changing Network (IP-adress).
That’s good to hear. Thank you for posting a follow up.
The 1.12 update added a fallback workaround - if the Windows driver store APIs didn’t appear to be responding Viscosity will try pulling the driver information directly from the registry and from the disk instead.
It still points to a problem with the driver store on the local PC, and it’s probable it’s causing slowness in other applications or background services/tasks, but it should allow Viscosity to avoid the issue on those machines.
Regards,
Aaron
SparkLabs Newsletter
Thank you for being interested in keeping up with the latest news from us! Please double-check your email address below and then click the Subscribe button.
