BSOD 0x7E: NULL dereference in dxgmms2!VIDMM_GLOBAL::CreateOneAllocation during WSL2 GPU-PV allocation

[xeniorn]

Summary

Repeated SYSTEM_THREAD_EXCEPTION_NOT_HANDLED (0x7E / 0x1000007E) bugchecks in
dxgmms2.sys, faulting in the VidMm worker thread while servicing a GPU allocation for
the WSL2 utility VM over GPU paravirtualisation. The faulting instruction dereferences a
NULL pointer:

dxgmms2!VIDMM_GLOBAL::CreateOneAllocation+0x4f:
    mov     cl, byte ptr [rax+15Bh]      ds:002b:00000000`0000015b=??
    rax = 0000000000000000

Every analysed dump reports the identical Attempt to read from address 000000000000015b,
at the identical module offset +0x5D39B, across two different driver builds. This looks
like a missing NULL check rather than memory corruption or a data race.

Environment

• Windows 10 22H2, OS build 19045.7663 (also reproduced on 19045.7548)
• dxgmms2.sys 10.0.19041.7663 and 10.0.19041.7548 — both affected
• GPU: NVIDIA RTX A2000 12GB, driver 32.0.15.8270
• WSL 2.7.12.0, kernel 6.18.33.2-2, WSLg 1.0.73.2
• Distros in the utility VM: Ubuntu, docker-desktop, podman-machine-default
• Host: 128 GB RAM, Hyper-V role enabled

Bugcheck detail

BUGCHECK_CODE:  7e   (reported once as 1000007e)
BUGCHECK_P1: ffffffffc0000005   (access violation)
BUGCHECK_P2: fffff8012963d39b   (dxgmms2!VIDMM_GLOBAL::CreateOneAllocation+0x4f)
PROCESS_NAME: vmmem
FAILURE_BUCKET_ID: AV_dxgmms2!VIDMM_GLOBAL::CreateOneAllocation

EXCEPTION_RECORD Parameter[1]: 000000000000015b
Attempt to read from address 000000000000015b

rax=0000000000000000 rbx=0000000000000040 rcx=ffffd88cdc7135d0
rdx=00000000746c6644   ("Dflt" pool tag)
rsi=0000000000001000 r9=0000000000001000 r14=0000000000000040

Stack

dxgmms2!VIDMM_GLOBAL::CreateOneAllocation+0x4f          <-- NULL deref
dxgmms2!VIDMM_PAGE_TABLE_BASE::CreateVidMmObjects+0x14c
dxgmms2!VIDMM_PAGE_TABLE::InitializePageTable+0xda
dxgmms2!CreatePageTable+0x97
dxgmms2!VIDMM_PAGE_DIRECTORY::CommitVirtualAddressRange+0x6ce
dxgmms2!VIDMM_PAGE_DIRECTORY::CommitVirtualAddressRange+0x9de
dxgmms2!CVirtualAddressAllocator::CommitVirtualAddressRange+0x2f6
dxgmms2!CommitVirtualAddressRangesInList+0xa7
dxgmms2!VIDMM_GLOBAL::PageInOneAllocation+0x65c
dxgmms2!VIDMM_GLOBAL::LockInAperture+0x99
dxgmms2!VIDMM_GLOBAL::LockInternal+0x1e8
dxgmms2!VIDMM_GLOBAL::ProcessDeferredCommand+0x1131
dxgmms2!VIDMM_WORKER_THREAD::Run+0xe5e
dxgmms2!VidMmWorkerThreadProc+0x9
nt!PspSystemThreadStartup+0x55
nt!KiStartSystemThread+0x28

Frame offsets between CreateOneAllocation and CommitVirtualAddressRange differ between
.7548 and .7663 (so the code did change between builds), but the faulting instruction and
the NULL operand are identical in both.

Occurrences

When (local)	dxgmms2 build	Fault address	Read address
2026-07-29 02:13:33	.7548	(dump not retained)	-
2026-09-03 03:34:11	.7548	fffff8028436d39b	000000000000015b
2026-09-03 16:07:32	.7663	fffff805529cd39b	000000000000015b
2026-09-04 16:31:12	.7663	fffff8012963d39b	000000000000015b

WER Report IDs: d768dd8c-2730-4818-a585-338d59846586,
141e351e-a301-4370-b39b-fcf7be1b6557, 46dd06d7-3ec6-432a-8203-8a613de845b3.

Possible trigger (unconfirmed)

The WSL2 utility VM is recreated on a ~4 hour cadence on this machine (new VM GUID each
time, GPU-PV device PCI\VEN_1414&DEV_008E attached at creation). All three recent crashes
occurred within -9 s to +21 s of when the next VM creation was due, and no
"started successfully" event was logged for those slots - consistent with the bugcheck
happening during utility-VM creation / vGPU setup. The cadence itself ran ~38 times without
incident beforehand, so VM creation alone is not sufficient.

Ruled out

Hardware (GPU and all SSDs report healthy), system memory pressure (73 GiB available and
commit at 47% of limit at crash time), disk errors, and any host-side memory-reclaim
activity. A NULL constant operand is not consistent with corruption.

Dump availability

A kernel minidump for the 2026-09-04 crash is retained locally and can be provided through a
private channel on request. It is deliberately NOT attached here: a Windows small memory dump
embeds the machine hostname, AD domain/SPN strings, the local username in file paths, and the
loaded module and process list, none of which belong in a public tracker.

The WER Report IDs above should let the crash reports be retrieved from Microsoft-side
telemetry without any upload.

[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'.

[xeniorn]

The log collection should be initiated prior to the error occuring? But the error leads to BSOD, would the logs really end up being saved even if it's reproduced?