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

## 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.

The report identifies dxgmms2.sys and the VIDMM_GLOBAL::CreateOneAllocation stack entry during WSL2 GPU-PV utility-VM creation, but names no repository source file or test. Start by reviewing the retained kernel minidump and listed WER reports, then reproduce around utility-VM recreation. Done means confirming the cause and validating a fix or mitigation.

Written by the indexing model from the issue text.