Opened 16 months ago

Last modified 6 months ago

#1283 new Bug / Defect

BSoD on Windows in Bridged Mode

Reported by: mpfrench Owned by:
Priority: major Milestone: release 2.4.11
Component: Generic / unclassified Version:
Severity: Not set (select this one, unless your'e a OpenVPN developer) Keywords: I601
Cc:

Description

Ref: openvpn-install-2.4.9-I601-Win10.exe
Computers - 2 - One AMD based, the other Intel based. Both use the same LAN chip - Realtek RTL-8111
Realtek LAN driver 10.39.212.2020 (latest available from Realtek)
OS - Win 10 Pro 10 Version 10.0.18363 Build 18363

I am running an OpenVPN server in bridged mode on Windows 10 Pro on two computers where Windows was freshly installed.

I sporadically get a Blue Screen of Death (BSoD) and an automatic Windows restart as shown by the event log. This BSoD event happens whether or not the OpenVPN server is connected to a remote client.

I happened to be sitting at the computer console on two such events and observed the BSoD on-screeen message: "SYSTEM_THREAD_EXCEPTION_NOT_HANDLED
BRIDGE.SYS"

It appears that there is a problem with the interaction of Windows BRIDGE.SYS, the Realtek LAN driver, and the OpenVPN TAP driver. However, even updating the LAN driver to the latest version does not solve the problem and I do not know of anything else that is under my control left to do.

I have attached the latest memory dump analysis which shows the following key line:
PRIMARY_PROBLEM_CLASS: AV_STACKPTR_ERROR_bridge!unknown_function

I am not knowledgeable enough to know what this last error indicator is telling us. However, both computers function without BSoDs unless a network bridge is formed.

Frankly, it looks to me that there is a design problem with the OpenVPN TAP driver.

Attachments (1)

MEMORY_BSoD_20200518.DMP_Analysis.txt (6.9 KB) - added by mpfrench 16 months ago.

Download all attachments as: .zip

Change History (7)

Changed 16 months ago by mpfrench

comment:1 Changed 16 months ago by tct

Subscribing

comment:2 Changed 13 months ago by Gert Döring

What makes you think that it's the OpenVPN tap driver that is at fault here, and not the Realtek driver, or the bridging driver itself (the analysis shows hat the bridge driver does a null pointer access, which it should never do)? And why would that be a "design problem" in the TAP driver?

I have not seen anyone use bridged networks on Windows successfully in a long time, but we have seen regular reports about "it will even crash if OpenVPN is not involved", so this seems to be something not tested well at Microsoft. Generally speaking, if you really can't avoid using bridging (using routing instead), this is better done on a Linux or BSD machine.

Last edited 13 months ago by Gert Döring (previous) (diff)

comment:3 Changed 10 months ago by mpfrench

This bug is related to bug #828 and was fixed in the release of OpenVPN-2.5.0-I601-amd64.msi.

comment:4 Changed 7 months ago by mpfrench

My last post is wrong. The bug is still present in OpenVPN-2.5.0-I601-amd64.msi.

See bug report 1385 for a consolidated review and testing.

comment:5 Changed 6 months ago by Gert Döring

Milestone: release 2.4.9release 2.4.11

comment:6 Changed 6 months ago by Samuli Seppänen

I have opened an internal ticket about this. Our goal is to have our QA team set up an environment for reproducing the issue. Then our developers can fix it.

Note: See TracTickets for help on using tickets.