All TAP-Windows adapters are in use

OpenVPN stops on Windows with a single line and no further explanation:

All TAP-Windows adapters on this system are currently in use.

The message is literal. OpenVPN needs a virtual network adapter to build the tunnel on. When it reports that all TAP-Windows adapters on this system are currently in use, it has enumerated every TAP adapter Windows reports and found every one of them unavailable. Unavailable covers four different machine states, and the usual advice on forums fixes only one of them. Work out which state you are in before you install anything. An older TAP-Win32 form of the same message still circulates in search results, so match the line in your own log rather than the wording in a guide. The four states below are the same either way.

OpenVPN on Windows does not talk to your physical network card. It creates its routes on a virtual adapter that the TAP-Windows driver provides, and the tunnel lives on that adapter. One tunnel needs one adapter.

At startup the client enumerates the TAP adapters present, then takes the first one that is free. Free means installed, enabled, not reporting a driver error, and not already held by another process. Fail any of those four conditions and the adapter is skipped.

When every adapter fails at least one condition, the client has nowhere to build and prints the line above. Notice what it does not say. It does not distinguish between "there are none" and "there are some and they are all busy". That ambiguity is what sends people to addtap.bat when the real problem is a disabled adapter.

List the adapters before changing anything. This one command decides which half of the page you need.

Open PowerShell as Administrator and run:

Get-NetAdapter | Where-Object { $_.InterfaceDescription -like "*TAP-Windows*" } |
  Format-Table Name, InterfaceDescription, Status

Read the Status column against these four outcomes:

• No rows at all. The driver is not installed, so skip to the driver section.
• A row with status Up. Something is using it, most likely a running openvpn.exe.
• A row with status Disabled. Somebody or something turned it off in Device Manager.
• A row with status Not Present or Error. The driver installed but is not loading.

The graphical equivalent is ncpa.cpl, which opens Network Connections. A TAP adapter shows there with a description similar to TAP-Windows Adapter V9. Device Manager, at devmgmt.msc, is the place to see a driver error rather than just a state, because it marks a failed device under Network adapters.

Why the names do not match

Expect three different names for the same thing, because the driver, the device and the connection are each named separately.

tap-windows6 is the driver project. TAP-Windows Adapter V9 is the description Windows shows for the device it installs. tap0901 is the hardware ID that tapinstall.exe matches on. Searching for tap-windows9 finds results because people read the V9 in the description and assume it is the version number of the driver.

None of those three is the adapter Name, which is whatever Windows assigned when the device appeared. That is usually something like Ethernet 2, and it is the value every PowerShell command on this page wants. Read it from the first column of Get-NetAdapter and use it verbatim, quotes included when it contains a space.

Four states produce this message. They look identical from the client log and they need four different fixes.

A previous session did not release the adapter

This is the most common cause and the least documented. An openvpn.exe process that crashed, or that was killed while the tunnel was up, keeps its handle on the adapter. Windows keeps the adapter marked as in use until that handle goes away.

Check for the leftover process and end it:

Get-Process openvpn* -ErrorAction SilentlyContinue
Stop-Process -Name openvpn -Force

Restart the OpenVPN services afterwards rather than only the tray application, because a service holds adapters independently of the GUI. Run Get-Service *openvpn* to list what your install actually registered. Restart every one of them that reports Running.

The adapter status usually returns to Disconnected within a few seconds. If it does not, a reboot clears it, and a reboot that does not clear it points at one of the other three states.

The adapter is disabled or has a driver error

A disabled adapter is invisible to OpenVPN and visible to you. It happens after a driver update, after a cleanup tool has run, and after somebody disabled it to test something and forgot.

Re-enable it by name:

Enable-NetAdapter -Name "Ethernet 2"

Substitute the Name value from your own Get-NetAdapter output, which is rarely the same on two machines. In Device Manager the same adapter appears under Network adapters, and a yellow marker there means a driver error rather than a disabled device. A driver error is not fixed by enabling. Update or reinstall the driver instead.

The driver never installed

A fresh OpenVPN install can complete while its driver component fails, usually silently. You then get this error on the very first connection attempt, with no TAP adapter present at all.

Confirm it with the Get-NetAdapter command above. No rows means no driver. Reinstall the client and watch for a driver installation prompt during setup. Windows asks for confirmation before it installs a network driver, and a dismissed prompt leaves you exactly here.

Run the installer from an account with administrator rights, and watch the driver step rather than the progress bar. If it fails a second time on the same machine, capture what the installer reports and stop repeating the install. That message is the only thing separating a policy that refuses the driver from a package that never reached the step.

You genuinely have two connections open

One tunnel needs one adapter. Two simultaneous OpenVPN connections need two adapters, and a default install provides one.

This catches people who leave a work profile connected and then start a personal one. It also catches split setups where one tunnel carries only a subnet. The fix is not to fight the first tunnel. Add a second adapter, which the next section covers.

Match your Get-NetAdapter output to a row, then run only that row's action.

Two of those rows fail quietly if you get the order wrong. Stop the process before you touch the adapter, because enabling an adapter a dead process still holds returns it to the same state. And reinstall before adding, because adding an adapter on a broken driver produces a second broken adapter.

addtap.bat is the script forum answers reach for first, and it is the right answer for exactly one of the five rows above.

It ships with the TAP-Windows component and installs into the driver's own directory rather than the OpenVPN one. The usual path is:

C:\Program Files\TAP-Windows\bin

Run it from an Administrator command prompt. The companion script in the same folder is deltapall.bat, which removes every TAP adapter on the machine. Both are thin wrappers around the driver's own device tool, which is called tapinstall.exe in some builds and devcon.exe in others.

The tap-windows6 installer writes both scripts into a bin folder under its install directory, and adds Start menu shortcuts named Add a new TAP virtual ethernet adapter and Delete ALL TAP virtual ethernet adapters. Use the shortcut to locate the folder if the path above does not exist on your machine.

Treat deltapall.bat with care. It removes all of them, including adapters another VPN client on the same machine depends on, and several products bundle their own TAP adapter under their own name.

There is a better answer when you run two tunnels regularly. Bind each profile to a named adapter with dev-node so that neither profile can take the other's:

dev-node "OpenVPN TAP-Windows6"

The value is the adapter Name shown by Get-NetAdapter, not the interface description. Rename the adapters to something you will recognise first:

Rename-NetAdapter -Name "Ethernet 2" -NewName "OpenVPN-Work"

Then set dev-node "OpenVPN-Work" in one profile and the other adapter name in the other. Each tunnel now claims its own adapter and fails loudly rather than stealing one. See re-importing the profile once you have edited it.

This is the fix worth making permanent. Adding adapters until the error goes away works once and leaves you with a machine whose behaviour depends on start order. Naming them removes the race entirely.

OpenVPN can use more than one virtual adapter driver on Windows, and the difference matters here for a reason nobody states.

TAP-Windows is the original driver, presenting a full virtual Ethernet adapter. Wintun is a newer and lighter alternative from the WireGuard project. Later OpenVPN releases added a data-channel-offload driver as well.

Which one your client uses is a property of the build you installed rather than of your Windows version. Read the driver component list in the installer, or read the InterfaceDescription column of Get-NetAdapter afterwards. Do not infer it from a version number in a forum post.

The useful consequence is a diagnosis rather than a setting. A client configured to use Wintun does not enumerate TAP adapters at all, so it cannot produce this error. If you see this message while believing you are on Wintun, your client is not using the driver you think it is. Check the log lines above the error, which name the adapter the client actually opened.

Do not change drivers as a fix for this error. Changing driver replaces a known problem with an unfamiliar one, and none of the four states above are caused by the driver being TAP.

A recurring version of this error is a different problem wearing the same message. Something is claiming the adapter before you do.

Start with the service. The OpenVPN service can start at boot and connect a profile automatically, which leaves the adapter held before you open the GUI. Check the service start type and the profile directory the service reads from. If a stale profile is being auto-started, remove it rather than adding an adapter to work around it.

Then look at ordering. A tunnel that starts before the physical network is ready can fail and leave a half-initialised adapter behind. Setting the service to a delayed start usually removes that race. Run Get-Service *openvpn* | Select-Object Name, StartType to see which services start themselves. Then find the directory each one reads profiles from before you delete anything.

Fast startup is worth checking on laptops. Windows can resume from a saved kernel state rather than performing a cold boot, which carries driver state across what looks to you like a restart. An adapter that was held at shutdown could therefore still be held after the machine comes back. Test that on your own machine rather than taking it on trust. Shut down, power on, and read the adapter status. Then restart and read it again. If the adapter is held after one and free after the other, fast startup is the difference and turning it off is the fix.

Track which fix actually worked as well. This error has four causes and a reboot masks two of them, so a machine that only ever gets rebooted teaches you nothing about which one you have.

Finally, rule out a second VPN product. Two clients that both auto-start will compete for adapters on every boot, and the loser prints this message. For where each profile belongs and which client reads it, see using your OpenVPN profile.