[Bug]:Windows BSOD

[mrbcntxts]

Preflight checks

• I am running the latest version of the app available for my platform.
• I understand that incomplete reports may be closed without investigation.
• I have searched existing issues and this bug has not already been reported.

Describe the bug

Windscribe spilit tunel cause BSOD on windows

Operating system

Windows 11

OS details

25H2

App version

v2.24.8

Steps to reproduce

i get randomly BSOD while enable spilit tunneling in wdinscribe

i check your source code found something , i am not 100% sure about it but you can take look into it

What happened

I started getting random BSODs while using Windscribe split tunneling together with ExitLag in WFP mode.

I checked several minidumps and they all point to the same path:

PROCESS_NAME: Windscribe.exe

NETIO!FeApplyModifiedLayerData
fwpkclnt!FwpsApplyModifiedLayerData0
WindscribeSplitTunnel

The bugcheck is always:

KMODE_EXCEPTION_NOT_HANDLED (0x1E)
Exception code: 0xC0000005

The failure bucket is also consistently:

AV_NETIO!FeApplyModifiedLayerData

I initially thought this might be hardware or another driver, but after checking multiple dumps the same Windscribe split tunnel path keeps showing up.

Why ExitLag may be involved

The crashes seem to happen when ExitLag is running in WFP mode at the same time as Windscribe split tunneling.

I dumped the WFP state and there are other third-party callouts active on layers including:

FWPM_LAYER_ALE_CONNECT_REDIRECT_V4
FWPM_LAYER_ALE_BIND_REDIRECT_V4
FWPM_LAYER_INBOUND_TRANSPORT_V4/V6
FWPM_LAYER_OUTBOUND_TRANSPORT_V4/V6
FWPM_LAYER_STREAM_V4

So it looks like there are multiple WFP components touching the networking stack at the same time.

I also noticed that Windscribe walks the previousVersion chain and checks whether its own filter already modified the request:

if (pConnectRequest->modifierFilterId == filter->filterId)
{
    timesRedirected++;
}

I am wondering whether there may also be an issue when another WFP redirector has already modified the same connect/bind request before Windscribe gets it.

The biggest one is handling of a connection already redirected by another WFP driver. Windscribe checks the previousVersion chain only to count how many times its own filterId appears:

for (FWPS_CONNECT_REQUEST* pConnectRequest = connectRequest->previousVersion;
     pConnectRequest;
     pConnectRequest = pConnectRequest->previousVersion)
{
    if (pConnectRequest->modifierFilterId == filter->filterId)
        timesRedirected++;
}

But I don't see Windscribe checking localRedirectHandle, redirectRecords, or using FwpsQueryConnectionRedirectState.

That matters because Microsoft specifically documents multi-redirector scenarios. If another callout already redirected the connection, the driver is supposed to inspect that state and avoid incorrectly redirecting a connection that belongs to another local proxy/redirector. Microsoft even shows checking the previous version's localRedirectHandle when multiple redirectors are involved.

Environment

Windows 11

Windscribe split tunneling enabled

ExitLag running in WFP mode

Windows build around 26100 / 26200

The crashes normally happen after a few hours, not immediately.

Reproduction

1. Enable Windscribe split tunneling
2. Run ExitLag in WFP mode
3. Use the PC normally
4. After some time the system BSODs
5. Check the dump in WinDbg

The stack has been the same across multiple crashes:

NETIO!FeApplyModifiedLayerData
fwpkclnt!FwpsApplyModifiedLayerData0
WindscribeSplitTunnel

Would it be possible to check whether using FWPS_CLASSIFY_FLAG_REAUTHORIZE_IF_MODIFIED_BY_OTHERS here is correct for this classify path, and whether the split tunnel driver is expected to work correctly when another WFP redirector is also modifying the connection?

I can provide the minidumps, full !analyze -v output and WFP state dump if needed.

Expected behavior

i should not get BSOD

Actual behavior

i get BSOD

Debug log or username

send logs as primemb

081226-16984-01.dmp

081226-17500-01.dmp

081426-19218-01.dmp

Is this a regression?

Not sure

Screenshots

No response

Additional context

No response

[bernerdad]

Thank you for the bug report. We've created an issue on our internal board to investigate and resolve this in the next version after 2.24.