[Bug]: Possible BSOD caused by ProxyBridge bundled WinDivert64.sys during network packet handling

[mehradhm1]

Platform

Windows

ProxyBridge Version

3.2.0

OS and Version

Windows 11

Documentation

• I have read the Windows documentation
• I have read the macOS documentation
• I have read the Linux documentation

Code Review

• I have gone through the code page

Describe the Bug

Hi,

I am reporting a reproducible BSOD issue that appears to be related to ProxyBridge’s bundled WinDivert driver.

While using ProxyBridge on Windows 11, my system crashed with a BSOD. This has happened more than once, and in previous troubleshooting we were able to trace the crash path back to the same WinDivert driver used by ProxyBridge. When ProxyBridge is not running, the system remains stable and I do not get these crashes. The crashes occur when ProxyBridge is active and handling/routing traffic.

ProxyBridge is installed here:

C:\Program Files\ProxyBridge\

The system crashed with:

KERNEL_SECURITY_CHECK_FAILURE (139)

WinDbg showed:

Arg1: 000000000000000e
FAST_FAIL_INVALID_REFERENCE_COUNT

The failure bucket was:

0x139_e_INVALID_REFERENCE_COUNT_NETIO!NetioDereferenceNetBufferListEx

The relevant stack trace was:

00 nt!KeBugCheckEx
01 nt!KiBugCheckDispatch+0x69
02 nt!KiFastFailDispatch+0xb2
03 nt!KiRaiseSecurityCheckFailure+0x368
04 NETIO!NetioDereferenceNetBufferListEx+0xf5
05 NETIO!NetioDereferenceNetBufferListChain+0x111
06 tcpip+0x462e9

After switching to the trap frame and checking the stack again, it still pointed to the same network path:

NETIO!NetioDereferenceNetBufferListEx+0xf5
NETIO!NetioDereferenceNetBufferListChain+0x111
tcpip+0x462e9

This suggests that a network buffer/reference count was corrupted before NETIO attempted to dereference it.

I then checked the loaded modules in the dump. Several network-related drivers were loaded, including:

NETIO.SYS
tcpip.sys
fwpkclnt.sys
wfplwfs.sys
WinDivert64.sys

WinDbg confirmed that WinDivert64.sys was loaded:

8: kd> lm m WinDivert*

start end module name
fffff80174700000 fffff8017471c000 WinDivert64 (deferred)

Then I checked the module details:

8: kd> lmvm WinDivert64

start end module name
fffff80174700000 fffff8017471c000 WinDivert64 (deferred)

Image path: WinDivert64.sys
Image name: WinDivert64.sys
Timestamp: Tue Sep 20 04:39:22 2022 (632912C2)
CheckSum: 0001D693
ImageSize: 0001C000
Mapping Form: Loaded

I then searched the system and confirmed that the loaded WinDivert64.sys belongs to ProxyBridge:

C:\Program Files\ProxyBridge\WinDivert64.sys

So the WinDivert driver active during the crash was ProxyBridge’s bundled driver.

This has been tested multiple times. When ProxyBridge is disabled or not running, the computer does not crash. When ProxyBridge is active and routing traffic, the system eventually crashes with the same type of network-stack BSOD. Based on that behavior, plus the dump analysis showing ProxyBridge’s bundled WinDivert64.sys loaded at the time of the crash, ProxyBridge/WinDivert appears to be the direct trigger.

The key points are:

1. The BSOD happened in the Windows network stack.
2. The bugcheck was KERNEL_SECURITY_CHECK_FAILURE (139).
3. Arg1 was 0xe, meaning FAST_FAIL_INVALID_REFERENCE_COUNT.
4. The failure happened in NETIO!NetioDereferenceNetBufferListEx.
5. WinDivert64.sys was loaded in the crash dump.
6. The loaded WinDivert64.sys came from C:\Program Files\ProxyBridge\WinDivert64.sys.
7. The bundled WinDivert64.sys timestamp is from September 2022.
8. The crash has happened multiple times while ProxyBridge was active.
9. The system remains stable when ProxyBridge is not running.

This may indicate an issue with the bundled WinDivert version, or an incompatibility between ProxyBridge’s packet interception/routing logic and newer Windows 11 network stack behavior.

Failed to resolve hostname: localhost
SOCKS5 proxy: :0

Changing the proxy host from localhost to 127.0.0.1 fixed that issue and allowed ProxyBridge to initialize correctly without needing to manually click “Test Proxy Connection”.

Suggestions:

• Consider updating the bundled WinDivert driver to the latest stable version.
• Show the bundled WinDivert version in the UI or logs.
• Log the exact WinDivert driver path being loaded.
• Warn users if multiple WFP/network filtering drivers are detected.
• Handle localhost resolution more safely during startup, or normalize localhost to 127.0.0.1 for local proxy use.
• Add safer error handling or compatibility checks around WinDivert initialization and packet handling.

I can provide the minidump and additional WinDbg output if needed.

Additional Context

No response

[Anof-cyber]

Kernel is not managed by ProxyBridge.

[Anof-cyber]

Can you still confirm your proxy config. ProxyBridge handled by ProxyBridge but it won't do anything with BSOD. BSOD can't be triggered directly from userspace and if its from kernel its not ProxyBridge own kernel its Windivert. Seperate project.

[mehradhm1]

Thanks for the clarification.

I understand that ProxyBridge itself is a userspace application and does not directly manage the Windows kernel. I also understand that the kernel-mode component involved here is WinDivert, which is a separate project.

However, from the user/system perspective, ProxyBridge is the application that bundles, loads, and depends on WinDivert for packet interception/routing. The WinDivert driver loaded during the crash was located at:

C:\Program Files\ProxyBridge\WinDivert64.sys

So while the kernel driver itself is WinDivert, it is still the WinDivert binary distributed and used by ProxyBridge.

The reason I reported it here is that the crash only happens when ProxyBridge is active and routing traffic. When ProxyBridge is not running, the system remains stable. This has happened more than once.

My proxy configuration is:

Host: 127.0.0.1
Port: 10808
Protocol: SOCKS5

This local proxy is provided by v2rayN.

Previously, when the host was set to:

localhost

ProxyBridge failed to initialize the proxy correctly on startup and logged something like:

Failed to resolve hostname: localhost
SOCKS5 proxy: :0

Changing it from localhost to 127.0.0.1 fixed the startup initialization issue.

Regarding the BSOD, the WinDbg crash analysis showed:

KERNEL_SECURITY_CHECK_FAILURE (139)
Arg1: 000000000000000e
FAST_FAIL_INVALID_REFERENCE_COUNT

Failure bucket:

0x139_e_INVALID_REFERENCE_COUNT_NETIO!NetioDereferenceNetBufferListEx

Relevant stack:

NETIO!NetioDereferenceNetBufferListEx+0xf5
NETIO!NetioDereferenceNetBufferListChain+0x111
tcpip+0x462e9

And WinDbg confirmed that WinDivert64.sys was loaded:

lmvm WinDivert64

Image path: WinDivert64.sys
Image name: WinDivert64.sys
Timestamp: Tue Sep 20 04:39:22 2022 (632912C2)
Mapping Form: Loaded

The file on disk is:

C:\Program Files\ProxyBridge\WinDivert64.sys

So I agree that the kernel crash is technically inside/around WinDivert and the Windows networking stack, not ProxyBridge’s own userspace code. But since ProxyBridge ships and uses this WinDivert driver, I think it would still be useful for ProxyBridge to:

• log the exact WinDivert version/path being loaded
• update the bundled WinDivert binary if it is outdated
• warn users about possible conflicts with other network/WFP filters
• improve error handling around local proxy initialization
• possibly allow users to use a newer external WinDivert build

Please let me know what other logs, config details, or dump outputs would help.

[Anof-cyber]

It has nothing to do with ProxyBridge itself ProxyBridge get packet from Windivert, it just inform which packet goes where. Update packet, route, check sum all handled by Windivert. Also packet passed to Windivert comes from Windivert itself.

If its from localhost/dns its a know issue there is already a issue created to fix the dns issue in ProxyBridge. I am 100% if that will cause bsod as same dns is raised by multiple people none face bsod because of that

[Anof-cyber]

See if this can help, i am not working on this project for next few months so may be @copilot

[mehradhm1]

I understand your point, and I’m not trying to blame ProxyBridge directly.

I know ProxyBridge is a userspace app and WinDivert is the kernel-level component. I also understand WinDivert is a separate project.

The reason I’m reporting it here is that before installing ProxyBridge, I did not have WinDivert on my system, and the loaded driver is located inside the ProxyBridge installation folder:

C:\Program Files\ProxyBridge\WinDivert64.sys

So even if the kernel crash is technically caused by WinDivert or the Windows network stack, ProxyBridge is still the app that introduced and uses this WinDivert driver in my setup.

Also, this has been tested multiple times:

• When ProxyBridge is not running, my system stays stable.
• When ProxyBridge is active and routing traffic, the computer eventually crashes with the same type of BSOD.
• The crash dump shows NETIO/tcpip with INVALID_REFERENCE_COUNT, and WinDivert64.sys from the ProxyBridge folder was loaded at the time.

My proxy config is:

Protocol: SOCKS5
Host: 127.0.0.1
Port: 10808
Proxy provider: v2rayN

I understand this is a free project and that you may not have time to work on it right now. I’m only trying to help narrow the issue down and provide useful technical information.

A few questions that may help:

1. Is ProxyBridge expected to bundle and load WinDivert64.sys from its own folder?
2. Is there a way to update or replace the bundled WinDivert build safely?
3. If WinDivert is the problematic part, is there any alternative backend ProxyBridge could use instead?
4. Could ProxyBridge add a log line showing the exact WinDivert path/version it loads?
5. Is there any debug log I can enable to help confirm where the packet handling fails?

I agree the issue may ultimately belong to WinDivert, but from the user side the crash only starts after installing/running ProxyBridge, so I think it is still worth checking the integration, bundled driver, or compatibility layer.

[mehradhm1]

Also, I’m still investigating this on my side to collect stronger evidence and narrow it down more precisely.

If anyone else has experienced a similar BSOD while using ProxyBridge, especially with WinDivert64.sys loaded, please share your dump details, Windows version, proxy config, and any related logs here. It would help confirm whether this is specific to my setup or a more general compatibility issue.

I’m not trying to blame the project; I just want to help document and isolate the problem as clearly as possible.

[mehradhm1]

I found a very specific trigger.

When ProxyBridge is running, if I open Chrome and type my router’s local IP address "192.168.100.1" in the address bar to access the router setup/admin page, the system crashes with BSOD after a few seconds.

Steps:

1. Start ProxyBridge
2. Open Google Chrome
3. Type the router local IP address in Chrome
4. The router setup/admin page starts loading
5. After a few seconds, Windows crashes with BSOD

When ProxyBridge is not running, I can open the same router IP in Chrome without any crash.

So it looks like the issue may be related to ProxyBridge/WinDivert handling local LAN/router traffic from Chrome.

Could you please check whether local/private addresses are being intercepted instead of bypassed?

Examples:

127.0.0.1
192.168.0.0/16
10.0.0.0/8
172.16.0.0/12
::1

In my case, typing the router IP directly in Chrome seems to trigger the crash consistently.

[Anof-cyber]

Can you share the details:

1 bsod happened when localhost used instead of 127...1? - not sure bsod but domain name not working properly in proxy config is known issue.

2. Trying to access private ip like 172 192 etc in browser when ProxyBridge running it crashes? What rules you have in ProxyBridge? As its been tested and ProxyBridge already works with private ip.

[mehradhm1]

Update:

To answer your question about the rules:

At first, I tested with my normal ProxyBridge rules, but then I removed/disabled all custom rules for testing. The BSOD still happened when ProxyBridge was running and I opened the router local IP from Chrome.

So I don’t think this is caused by one specific user rule.

I spent several hours testing and tracing this. I also collected a new dump and netsh/WFP traces while reproducing the issue.

The reproducible trigger was:

1. Start ProxyBridge
2. Open Chrome
3. Open the router local IP: http://192.168.100.1
4. Windows crashes with BSOD after a few seconds

When ProxyBridge is not running, the same router IP works normally.

The dump still shows:

BugCheck 0x139
KERNEL_SECURITY_CHECK_FAILURE
Arg1: 0xe
FAST_FAIL_INVALID_REFERENCE_COUNT

Relevant modules seen in the crash path include:

NETIO.SYS
tcpip.sys
WinDivert64.sys
ProxyBridge.exe
chrome.exe

The WFP/netsh trace also showed local LAN/private traffic around the crash window, including traffic involving:

192.168.100.1
239.255.255.250:1900

After that, I added a high-priority DIRECT rule in ProxyBridge for my LAN/router range:

Applications: *
Target Hosts: 192.168.100.*;127.0.0.1;localhost
Target Ports: *
Protocol: TCP + UDP
Action: DIRECT

After adding this rule, accessing the router page no longer causes BSOD.

ProxyBridge log now shows:

chrome.exe -> 192.168.100.1:80 via Direct

So it looks like bypassing local/private LAN traffic at the ProxyBridge rule level prevents the crash in my case.

This makes me think the issue may be related to how ProxyBridge/WinDivert handles local/private LAN traffic when it is intercepted or processed.

Maybe ProxyBridge should have a built-in default bypass rule for local/private/multicast/broadcast ranges, before any user rules are applied, for example:

127.0.0.0/8
192.168.0.0/16
10.0.0.0/8
172.16.0.0/12
169.254.0.0/16
224.0.0.0/4
255.255.255.255
::1
fc00::/7
fe80::/10

Or even better, these ranges could be excluded as early as possible from WinDivert interception/filtering if the app does not need to process them.

From a user perspective, I think private LAN/router traffic should probably be bypassed by default. Most users do not expect traffic to their router, localhost, LAN devices, SSDP/multicast, etc. to be intercepted or proxied.

I’m not saying this is definitely a ProxyBridge userspace bug, but the behavior strongly suggests that the crash is triggered only when ProxyBridge/WinDivert is active and local LAN traffic is being handled. Adding an explicit DIRECT bypass rule for LAN traffic prevents the crash for me.

Please let me know if you want me to share the dump, netsh trace, WFP trace, or exact ProxyBridge config.

For reference, this was my ProxyBridge configuration during the test:
Current ProxyBridge configuration during the test:

Proxy Settings:

• Proxy Type: SOCKS5
• Proxy IP Address: 127.0.0.1
• Proxy Port: 10808
• Backend proxy: v2rayN / Xray

Proxy Rules during the crash test:

• No custom proxy rules enabled / all rules removed for testing

Global Settings:

• Enable Traffic Logging: ON
• DNS via Proxy: ON
• Localhost via Proxy: OFF
• Close to system tray: ON
• Run at startup: ON
• Language: English

---

Small separate update:

I found another behavior related to ProxyBridge startup.

When ProxyBridge starts with Windows, Windows sometimes shows the Wi-Fi/Internet status as disconnected or “No Internet”. In some cases the internet is still working, but in other cases it actually does not work until I manually reconnect to Wi-Fi or wait for it to recover.

I tested this:

• v2rayN running alone at startup: no issue
• ProxyBridge running at startup: Windows network status becomes incorrect
• Disabling ProxyBridge startup fixes it
• Adding a high-priority DIRECT rule for Windows connectivity/NCSI and local traffic also fixes it

The rule that fixed it for me:

Applications: *
Target Hosts:
www.msftconnecttest.com;msftconnecttest.com;dns.msftncsi.com;www.msftncsi.com;msftncsi.com;192.168.100.*;127.0.0.1;localhost

Target Ports: *
Protocol: TCP + UDP
Action: DIRECT

After adding this rule, Windows no longer falsely shows Wi-Fi/Internet as disconnected.

So this may not be a critical bug, but ProxyBridge seems to interfere with Windows connectivity detection unless NCSI/local traffic is bypassed.

Maybe ProxyBridge should include a default DIRECT/bypass rule for Windows connectivity check domains and local/private traffic.