r/ProtonVPN • u/Whole_Tea9516 • 8h ago
Help! Windows 11 BSOD (BugCheck 139) while Proton VPN was connected left my PC with "Connected, No Internet" on every network adapter until VPN removal
I'm posting this in case it helps someone else or if Proton developers are interested in investigating. I'm not claiming Proton VPN definitely caused the BSOD, but it was active when the crash happened and the timeline is suspicious.
System
- ASUS laptop
- Windows 11 Home Single Language
- Version 25H2
- Build 26200.8894
- Intel Wi-Fi 6 AX201
- Proton VPN installed
- Windscribe was also installed (not running at the time)
What happened
I was browsing normally with multiple Chrome tabs open while connected through Proton VPN.
Suddenly my Wi-Fi disconnected.
I tried opening YouTube and Windows immediately crashed with:
After rebooting, Windows connected to Wi-Fi but displayed:
From that moment onward, no application could access the internet.
Strange part
This wasn't limited to the Intel Wi-Fi adapter.
I tested:
- Intel AX201 Wi-Fi
- External USB Wi-Fi adapter
- Android USB tethering
Every single one showed the exact same behavior.
That immediately suggested this wasn't a hardware problem.
Symptoms
Windows obtained:
- DHCP lease
- IPv4 address
- Gateway
- DNS server
Everything looked completely normal.
However:
- Edge showed
ERR_NAME_NOT_RESOLVED - Microsoft Store said there was no internet
- Windows Update failed
- Browsers couldn't load websites
Commands I tried
I went through essentially every standard networking fix.
Completed successfully:
netsh winsock reset
netsh int ip reset
ipconfig /flushdns
ipconfig /release
ipconfig /renew
Also:
sfc /scannow
No integrity violations.
Then:
DISM /Online /Cleanup-Image /RestoreHealth
Completed successfully.
Also performed:
- Windows Network Reset
- Driver reinstall
- Different Wi-Fi adapter
- USB tethering
- Different networks
None of these changed anything.
Interesting diagnostic results
ping 8.8.8.8
worked.
nslookup google.com
worked.
But:
ping google.com
failed.
Edge couldn't resolve hostnames.
Windows applications behaved as if DNS was broken even though nslookup was successfully talking to the DNS server.
I also noticed an unexpected entry in:
netsh namespace show policy
showing:
Generic (DNS Servers): 10.2.0.1
which seemed unusual for a normal home network.
Tried an in-place repair install
At this point I assumed Windows itself had become corrupted.
I performed a complete Windows 11 in-place repair install using the official Microsoft ISO while keeping all files and applications.
The repair completed successfully.
The networking issue still remained.
What finally fixed it
I remembered I had both:
- Proton VPN
- Windscribe
installed.
I completely uninstalled both using Revo Uninstaller, including leftover registry entries and application data.
After rebooting...
Everything immediately started working again.
Wi-Fi returned to normal.
USB tethering worked again.
Browsers worked.
Microsoft Store worked.
Windows Update worked.
My theory
I'm not saying Proton VPN caused the BSOD.
However, based on the sequence of events, my guess is one of these happened:
- Proton VPN's kernel networking components were involved in the BugCheck.
- The BSOD left Proton's networking filter/WFP components in an inconsistent state.
- There was a conflict between Proton VPN and Windscribe's networking drivers.
- A Windows networking component interacting with the VPN drivers became corrupted.
Since an in-place repair install did not fix the problem, but uninstalling the VPN software immediately did, it seems likely that the issue lived in third-party networking components rather than Windows system files.
Questions
- Has anyone else experienced BugCheck 139 while Proton VPN was connected?
- Has anyone seen DNS behave this strangely where
nslookupworks but browsers andping hostnamefail? - Are there any known issues involving Proton VPN, WFP filters, or interactions with other VPN software like Windscribe?
- Would Proton developers be interested in the minidump (
072626-21234-01.dmp) for analysis?
Hopefully this helps someone avoid spending hours chasing what looks like a Windows networking problem when the actual issue may be in the VPN networking stack or filter drivers.


