Opened 9 years ago

Last modified 3 years ago

#536 new Bug / Defect

"There are no TAP-Windows adapters on this system" after installing Windows 10 build 10049

Reported by: chrisschrimsher Owned by: jamesyonan
Priority: major Milestone:
Component: tap-windows6 Version: OpenVPN 2.3.6 (Community Ed)
Severity: Not set (select this one, unless your'e a OpenVPN developer) Keywords: windows
Cc:

Description

Hi there,

This is my first time reporting a "bug" in OpenVPN, and I suspect it may have more to do with a change Microsoft made in Windows, so please forgive me if this post is not appropriate or if there's a better means to report it. OpenVPN is a HUGE help for me and I just want to help in return!

OpenVPN has been working fine on Windows 10 Technical Preview until I upgraded to build 10049 this morning. After upgrading to this build, OpenVPN would not connect, log file tail below:

Tue Mar 31 11:45:48 2015 MANAGEMENT: Client disconnected
Tue Mar 31 11:45:48 2015 There are no TAP-Windows adapters on this system.  You should be able to create a TAP-Windows adapter by going to Start -> All Programs -> TAP-Windows -> Utilities -> Add a new TAP-Windows virtual ethernet adapter.
Tue Mar 31 11:45:48 2015 Exiting due to fatal error

I ran the batch files to delete / reinstall the TAP adapters, reinstalled OpenVPN, even modified my config file to use dev-tun to locate the TAP adapter by name, but no dice.

Using ProcMon? to compare to a known working system (Windows 8.1, if that matters), I noticed that as openvpn.exe was enumerating network adapters in

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4d36e972-e325-11ce-bfc1-08002be10318}

it querues for a REG_SZ value named ComponentId?. On my Windows 10 build 10049, this value was missing. It appears that when this value is missing, it does not proceed to query NetCfgInstanceId?, which is why I suspect reports that no TAP adapters were found. I checked my working system (again, Windows 8.1), and ComponentId? was set to 'tap0901' (the same as MatchingDeviceId?).

From the stack trace in ProcMon?, it appears that openvpn.exe is directly querying this value (as opposed to calling some Windows API which then queries the value).

After I manually added HKLM\System\CurrentControlSet?\Control\Class\{4d36e972-e325-11ce-bfc1-08002be10318}\0017\ComponentId? (the 0017 is specific to my system, of course) with REG_SZ value 'tap0901' (no quotes), I was successfully able to connect.

I hope this helps and I will gladly provide any information I can if needed. Thank you!!!!!!!

Sincerely,
Chris Schrimsher

Change History (15)

comment:1 Changed 9 years ago by Samuli Seppänen

Windows 10 has probably dropped support for NDIS5 drivers. Could you uninstall OpenVPN and retry with one of these installers:

Let us know if these solve the problem.

comment:2 Changed 9 years ago by vnicolici

After having the same issue and digging through the source code I came to the same conclusion as the reporter:

The driver installs fine, except for that missing registry value for "ComponentId?", and works fine after adding the registry value manually.

This is what I had to add:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4d36e972-e325-11ce-bfc1-08002be10318}\0001]
"ComponentId"="tap0901"

(please note that in my case the key was named 0001, but you will have to replace it with the id assigned to your adapter, for example it was 0007 on another computer, and you may have to do this for each of your TAP adapters if you use more than one)

I noticed that the "MatchingDeviceId?" value is present on both Windows 10 10049 and on Windows 8.1, so that could be used instead of "ComponentId?", since it contains the same string: "tap0901".

So the easiest way to fix this would be to replace in tun.c line 2951

      char component_id_string[] = "ComponentId";

with

      char component_id_string[] = "MatchingDeviceId";

comment:3 in reply to:  1 Changed 9 years ago by chrisschrimsher

Replying to samuli:

Windows 10 has probably dropped support for NDIS5 drivers. Could you uninstall OpenVPN and retry with one of these installers:

Let us know if these solve the problem.

Hi there! Thanks for the suggestion, although I'm already using OpenVPN from openvpn-install-2.3.6-I603-x86_64.exe, and the bundled NDIS 6 TAP driver (9.21.1).

I don't know anything about NDIS/driver development/etc, but I believe something must have changed in the way this build of Windows installs the driver that omits the ComponentID key -- I didn't see it present on any of my other adapters either.

Thanks,
Chris

comment:4 in reply to:  2 Changed 9 years ago by chrisschrimsher

Replying to vnicolici:

So the easiest way to fix this would be to replace in tun.c line 2951

      char component_id_string[] = "ComponentId";

with

      char component_id_string[] = "MatchingDeviceId";

Thanks! I'll also see if I can find anything on the Microsoft Connect site -- I can't find anything concrete in the DDK on either of those two fields (or more specifically, the deprecation of ComponentId?, so it's possible that this is just a bug in this preview build?

comment:5 Changed 9 years ago by vnicolici

Could be a bug. It would probably be safer to wait a bit to see if it comes back in future builds.

comment:6 Changed 9 years ago by Samuli Seppänen

Component: tap-windowstap-windows6
Keywords: windows added; TAP-Windows adapters Windows10 10 10049 ComponentId removed
Owner: set to jamesyonan
Priority: minormajor

Let us know if this problem gets resolved in future Windows 10 builds. If not, we'll have to fix it at the OpenVPN end.

comment:7 Changed 9 years ago by vnicolici

I'm currently running Windows 10 build 10162 and OpenVPN 2.3.6, the problem seems to be gone.

I removed all the adapters, added them back, and ComponentId? is no longer missing.

I also checked all the other adapters and they have a ComponentId? .

So it was probably a Windows 10 bug that got fixed.

comment:8 Changed 8 years ago by Samuli Seppänen

Is someone still having this issue? If not, I will close it soon.

comment:9 in reply to:  8 Changed 8 years ago by chrisschrimsher

Replying to samuli:

Is someone still having this issue? If not, I will close it soon.

Not to start +1 fever (I'm the original reporter), but it's been working fine for me for several Windows builds now.

Thanks!

comment:10 Changed 8 years ago by korppari

Hi

This worked for me (Version openvpn-install-2.3.6-I603-x86_64)

AppleCurry? said:
I created an account here to post how I resolved it. I tried all of the above to install TAP, but it all failed.

First, from the run box (shortcut windows-R) enter and run: control ncpa.cpl
Then run the installer as admin as usual, with the network adapters window still open (ncpa.cpl).

I have no idea why this particular thing makes it work, but it did so perfectly for me. I even uninstalled everything and retried again both with and without having ncpa open. Crazy

comment:11 Changed 3 years ago by dlon

I've seen this (or a similar) issue when using Wintun on a couple of machines (on Windows 10, 18363.1016, and on Windows 10, 19041.630). It occurs only sometimes when creating an adapter, apparently by chance. However, if WintunCreateAdapter is instructed to create a new adapter with the same GUID as that of the misbehaving device, after the latter has been deleted, then the new device has the same problem.

"ComponentId?" and "DeviceInstanceId?" are missing from the registry key for the network device. As mentioned in other comments, the problem can be "fixed" by manually creating a "ComponentId?" value. Incidentally, wireguard-go is able to set up a tunnel using this same adapter, because it doesn't look up "ComponentId?".

This would maybe not address the root issue, but might it be a good idea to not rely on this registry value?

Last edited 3 years ago by dlon (previous) (diff)

comment:12 Changed 3 years ago by Almaza211

edited: spam

Last edited 3 years ago by Antonio Quartulli (previous) (diff)

comment:13 Changed 3 years ago by davidson02

Edited SPAM

Last edited 3 years ago by tct (previous) (diff)

comment:14 Changed 3 years ago by dodubq

SPAM

Last edited 3 years ago by tct (previous) (diff)

comment:15 Changed 3 years ago by cewyz

It occurs only sometimes when creating an adapter, apparently by chance. However, if WintunCreateAdapter?? is instructed to create a new adapter with the same GUID as that of the misbehaving device, after the latter has been deleted, then the new device has the same problem.

I am a spammer!

Last edited 3 years ago by tct (previous) (diff)
Note: See TracTickets for help on using tickets.