OpenVPN service fails on a profile the GUI opens: five checks

Two launchers open the same profile on one machine, and only the GUI connects. The file is intact and the installer is probably fine; what differs is the context each launcher gives openvpn.exe. Working directory, account identity and file attributes all travel with that context. Check them in that order and stop at the first one that explains the error.

Confirm which launcher fails

Start by proving the split. If the GUI connects and the service does not with the same profile path, the file is readable by someone and the question becomes who reads it and from where. If both fail, the profile is broken and none of this applies. Write down the service name and the exact profile it was told to load.

A service pointed at its own auto-start directory may not be loading the file you have open in an editor. Compare the path in the service configuration with the path in the GUI, character for character, because a trailing folder name or a different drive letter is enough to send you down the wrong branch.

Where relative paths resolve

A profile that references ca.crt or a helper script by bare name asks for a lookup relative to wherever the process happens to be. The GUI starts in the configuration folder, so those names resolve. A service started by the service manager has no such starting point, and the lookup fails before any certificate is read. That is why the same profile works in one launcher and not the other.

Give the wrapper a directory to start in, or make every reference absolute. Reproducing the GUI's context on a command line looks like this:

openvpn --cd "C:\VPN\profiles\office" --config "C:\VPN\profiles\office\office.ovpn"

Raising verbosity on that command shows the exact path that was attempted. Do it before changing permissions, because a missing file and a denied read need different fixes. The default log does not distinguish them. One extra flag saves an hour of guessing.

When the service identity cannot read

A service runs as a system identity, not as you. An ACL that grants your user full control and nobody else fails there while working perfectly in your session. A profile kept on a mapped drive or an authenticated share fails for the same reason. Confirm the file's permissions before you look at anything else.

The check is a read of the effective permissions plus a read attempted as the service identity. Run the first part from an elevated prompt:

icacls "C:\VPN\profiles\office\office.ovpn"

Then attempt the same read as the service identity, for example with psexec -s -i from Sysinternals, and watch whether the file opens. If it does not, no path fix will help. Fix the ACL or move the profile to a location the service identity can read.

File-level encryption is the second, rarer case. A profile marked with the Encrypting File System attribute decrypts transparently for the user who encrypted it and stays unreadable to a service account. That is why the same file opens in your editor and not under the service.

The attribute is visible from an elevated prompt, and checking it does not open the profile. Run both commands and read the output:

cipher /s:"C:\VPN\profiles\office"
attrib "C:\VPN\profiles\office\office.ovpn"

Clearing the attribute makes the file readable, and it also removes the protection it carried. If the profile has to stay protected, put the secret material where the service identity has an explicit grant instead of relying on per-user encryption. That arrangement survives a password change, and it makes the access reviewable by someone other than the person who encrypted the file.

Deciding who owns the tunnel

The GUI can prompt for a password and can read a certificate from your user store. The service can do neither, so a profile that depends on an interactive secret will never start unattended no matter how the paths are fixed. That limit is a design decision, not a defect to work around. Pick one owner before changing anything else.

If the tunnel has to be up before login, give the service an unattended credential source and its own copy of the profile. If it only needs to exist while you are at the desk, keep it in the GUI and remove the service copy. Both at once is the configuration that produces adapter conflicts and duplicate routes.

That conflict usually gets diagnosed as a config error rather than as two owners fighting over one adapter. The event log will show one process failing to open the TAP device, which looks like a permission problem and is not. Count the owners first.

What the service wrapper actually launches

The service entry point is a small wrapper that reads its own stored parameters and then starts openvpn.exe. When the command line in the event log disagrees with your expectation, those values are the thing to inspect. Reinstalling resets them to defaults and destroys the evidence. Read them first.

The values live in the registry under the service's own key, and sc qc shows the binary path the service manager will launch. Compare that path with the wrapper's stored configuration before you edit either one.

Replacing the wrapper with a script you control is more invasive, but it collapses the effective command line into one readable file. Finish with a restart, then read the per-profile log until the first successful startup line appears. A service state of running only means the wrapper has not exited, which is also true when its child died immediately.