Host BSOD 0x3B (SYSTEM_SERVICE_EXCEPTION) in dxgkrnl.sys when WSL2 starts with GPU support (RTX 4000 SFF Ada, Windows 26200.8893)

[KevPat]

Host BSOD 0x3B (SYSTEM_SERVICE_EXCEPTION) in dxgkrnl.sys when WSL2 starts with GPU support

Windows / WSL versions

• WSL version: 2.7.10.0 (kernel 6.18.33.2-2, WSLg 1.0.73.2, Direct3D 1.611.1)
• Windows version: 10.0.26200.8893 (11 Enterprise 25H2)
• dxgkrnl.sys version at crash: 10.0.26100.8875

Hardware / security configuration

• Dell Precision 3460 SFF, i9-14900, 64 GB RAM
• GPUs: NVIDIA RTX 4000 SFF Ada (driver 595.95 / 32.0.15.9595 at crash time; since updated to 596.72) + Intel UHD 770 (32.0.101.7085)
• VBS fully enabled: HVCI (Memory Integrity), Credential Guard, App Control for Business (WDAC) enforced

What happened

Launching a WSL2 session (GPU support at defaults) blue-screened the Windows host approximately 64 seconds after the WSL utility VM began starting. System log shows the WSL Hyper-V switch ("WSL (Hyper-V firewall)"), VfpExt filter attach, and vNIC creation at T+0; bugcheck at T+64s.

BugCheck 0x0000003B (0x00000000C0000005, 0xFFFFF8036CD5670E, 0xFFFF9600A67E5DC0, 0x0000000000000000)

Manual triage-dump analysis (module list + raw stack from the kernel minidump):

• Faulting instruction: dxgkrnl.sys + 0x4670e (access violation)
• Additional dxgkrnl frames on the raw stack: +0x466f8, +0x167ec4, +0x172c04, +0x16ec38, +0x173ae0, +0x17a320
• Other modules referenced on the crashed thread's stack: ntoskrnl.exe, vmswitch.sys, Vid.sys, mssecflt.sys — consistent with the crash occurring during utility-VM device setup (GPU paravirtualization path)

Frequency

Single occurrence so far; first-ever bugcheck on this machine. The 18 MB kernel minidump is available on request.

Question

Is this a known issue in the GPU-PV bring-up path on 26200-series builds? Happy to provide the dump or run additional diagnostics.

[github-actions]

Logs are required for review from WSL team

If this a feature request, please reply with '/feature'. If this is a question, reply with '/question'.
Otherwise, please attach logs by following the instructions below, your issue will not be reviewed unless they are added. These logs will help us understand what is going on in your machine.

How to collect WSL logs

Download and execute collect-wsl-logs.ps1 in an administrative powershell prompt:

Invoke-WebRequest -UseBasicParsing "https://raw.githubusercontent.com/microsoft/WSL/master/diagnostics/collect-wsl-logs.ps1" -OutFile collect-wsl-logs.ps1
Set-ExecutionPolicy Bypass -Scope Process -Force
.\collect-wsl-logs.ps1

The script will output the path of the log file once done.

If this is a networking issue, please use .\collect-wsl-logs.ps1 -LogProfile networking instead, following the instructions in Collect WSL logs for networking issues

Once completed please upload the output files to this GitHub issue.

See Collect WSL logs (recommended method).

If you choose to email these logs instead of attaching them to the bug, please send them to wsl-gh-logs@microsoft.com with the GitHub issue number in the subject, and include a link to your GitHub issue comment in the message body, and reply with '/emailed-logs'.

[shuaiyuanxx]

@KevPat Thanks for the report. The available evidence points to a host-side GPU-PV/dxgkrnl crash, but there is not enough information to identify the responsible component yet.

Could you provide:

1. The dump or complete !analyze -v output, including the stack and loaded modules
2. GPU model and driver version
3. A WSL log captured through reproduction
4. Whether the crash stops when using:

[wsl2]
gpuSupport=false

Run wsl --shutdown after changing the setting. This will help determine whether the crash is specifically in the GPU-PV path.