Non-Deterministic BSOD 0x3B in wireguard.sys on Disconnect

[blockchain420 0]

Hello AirVPN Support and Development Team,

I am writing to report a stability issue regarding a non-deterministic Blue Screen of Death (BSOD) with error code **0x3B (SYSTEM_SERVICE_EXCEPTION)** triggered when disconnecting from a WireGuard tunnel via the Eddie client.

Because this crash happens intermittently during the teardown sequence, it strongly indicates a **Race Condition** or **Use-After-Free (UAF)** vulnerability inside the `wireguard.sys` driver wrapper, where memory buffers are accessed after being invalidated by the NDIS subsystem.

**System Environment**

* **OS:** Windows 10 IoT Enterprise LTSC 2021 (64-bit)
* **Build Number:** 19044.7725
* **Eddie Version:** Any version utilizing WireGuard 1.0.0.0
* **WireGuard Driver Version:** WireGuard 1.0.0.0

**Bug Check Details & Stack Trace Summary**

* **Bug Check Code:** 0x3B (`SYSTEM_SERVICE_EXCEPTION`)
* **Exception Code:** 0xC0000005 (`EXCEPTION_ACCESS_VIOLATION`)
* **Faulting Address:** `0xfffff8004f01111e` (Inside `ndis.sys`)
* **Trigger Event:** Disconnecting from the WireGuard tunnel using Eddie.
* **Key Stack Frames:** Crash manifests inside `ndis!ndisDeviceControlHandler` triggered by concurrent execution paths originating from `wireguard.sys+0x13b02` and `wireguard.sys+0x13844` during an IOCTL-driven shutdown.

**Technical Analysis (Race Condition Hypothesis)**
The crash signature and call stack point to a synchronization gap during the driver's teardown phase:

1. **Teardown Initiation:** Eddie issues an IOCTL call to halt the adapter.
2. **Memory Invalidation:** NDIS begins freeing `NDIS_MINIPORT_BLOCK` structures and associated packet buffers.
3. **Concurrent Access:** A pending network interrupt or timer event inside `wireguard.sys` simultaneously attempts to process packets using stale pointers.
4. **Violation:** The driver dereferences the invalidated memory, throwing an access violation within `ndis.sys`.

**Reproduction Steps**

1. Launch Eddie and connect to any WireGuard endpoint.
2. Maintain the connection for an arbitrary duration.
3. Click **Disconnect**.
4. **Result:** The client intermittently crashes with BSOD 0x3B instead of executing a clean disconnect. The failure is purely stochastic and independent of network traffic load.

**Troubleshooting Performed**

* Fast Startup: Disabled.
* Clean Install: Performed complete purges of Eddie and residual `wireguard.sys` drivers, followed by clean reinstalls. The issue persists.
* Traffic Load: Tested under both idle and high-throughput states; failures occur uniformly, confirming a state-dependent synchronization bug rather than a load-dependent fault.

**Impact & Request**
This issue undermines system stability on Windows 10 IoT LTSC environments. Since the official WireGuard for Windows client utilizes `Wintun.sys` (which manages adapter concurrency and teardown safely in user-space/TUN architecture), the legacy `wireguard.sys` wrapper appears to lack robust reference counting or synchronization primitives (such as proper spinlock implementation) during NDIS miniport halts.

Could you please clarify:

* Are you aware of this specific race condition in `wireguard.sys`, and is there an updated build or fix available?
* Are there plans to transition Eddie toward native `Wintun.sys` utilization to bypass these kernel-level concurrency constraints?

Thank you for your time and assistance in analyzing this behavior. A full kernel memory dump (`MEMORY.DMP`) is attached to this message.


 

091326-9562-01.dmp

[Tech Jedi Alex 1572]

I've never seen anyone providing a memory dump around here before  now I've seen it all, I guess.

In any case, this reeks a bit of AI processing, like it's written by some form of AI agent. Kudos for the structured problem report, of course, but there are things in here that absolutely no human would ever write about in such excruciating detail.
If the driver is the problem, did the agent try installing the official driver, not the one provided by Eddie? Did it try an older version? Because Eddie only bundles the driver, AirVPN doesn't code it per se, so a "sync gap during the driver's teardown phase" really belongs upstream, and not here, I would think. As outlined in Troubleshooting Performed, this was not tried.