Starred Gists
Starred Gists订阅

Hyper-V GPU-PV guest BSOD 0x3B dxgkrnl InitializeMessage (WARP / Basic Render Driver) - cause and fix via ViVeTool

Hyper-V GPU-PV guest: BSOD 0x3B in dxgkrnl (WARP adapter) — cause and fix

TL;DR. A Windows 11 guest with a GPU-PV partition bluescreens with SYSTEM_SERVICE_EXCEPTION (0x3B) in dxgkrnl!DXGVMBUSMESSAGE::InitializeMessage+0xde whenever something probes all video adapters for hardware video-encoder support. The probe reaches the Microsoft Basic Render Driver (WARP), which has no VMBus channel in a GPU-PV guest, and dxgkrnl dereferences NULL. Disabling two Windows feature flags fixes it:

ViVeTool.exe /disable /id:56095990
ViVeTool.exe /disable /id:62328181

After that, games (D3D11/D3D12 and OpenGL), Steam and Task Manager (including the GPU graph) work again. Rollback: ViVeTool.exe /reset /id:56095990,62328181.

Symptoms

  • Guest: Windows 11 with a GPU-PV partition (Add-VMGpuPartitionAdapter), e.g. an Easy-GPU-PV style setup.
  • Bugcheck 0x3B, arg1 c0000005, always the same stack:
dxgkrnl!DXGVMBUSMESSAGE::InitializeMessage+0xde        <- mov rax,[rax+12C4h], rax = 0
dxgkrnl!DXG_GUEST_VIRTUALGPU_VMBUS::VmBusSendIsFeatureEnabled+0x5b
dxgkrnl!DxgkIsFeatureEnabledVmBus+0x65
dxgkrnl!IsFeatureEnabledHost+0xb8
dxgkrnl!IsFeatureEnabledUncached+0x1ec
dxgkrnl!DxgkIsFeatureEnabled+0x4c
dxgkrnl!DpiIsFeatureEnabled+0x5e
dxgkrnl!NtDxgkIsFeatureEnabled+0x33a
  • Crashing process varies — the trigger is a system library, not the app: svchost.exe (Game DVR), steamsysinfo.exe, HYPHelper.exe (HoYoPlay / Honkai: Star Rail launcher), Taskmgr.exe.
  • It can start "out of nowhere" with no file changes in the guest or host — the responsible code paths sit behind feature flags, most likely enabled gradually by Microsoft (in our case the crashes began on 2026-10-20 with no update installed since 2026-10-14).

Fix

  1. Download ViVeTool (https://github.com/thebookisclosed/ViVe/releases), run from an elevated prompt in the guest:
    Feature ID Flag (module) What it gates Crashed via
    56095990 Feature_Servicing_MFTEnumEngineAccessFilter (mfplat.dll) MFTEnumEx(MFT_CATEGORY_VIDEO_ENCODER) → QueryAllAdaptersEngineAccess Game DVR, Steam, HoYoPlay launcher
    62328181 Feature_D3DVideoEncoderExclusiveAccess (D3D12Core.dll) every D3D12CreateDevice → CDevice::EnsureDXGKExclusiveEngineAccessSupport Task Manager (creates a D3D12 device on every DXCore adapter, WARP included)
  2. Check with ViVeTool.exe /query /id:56095990,62328181 → State: Disabled (1), priority User (8). Survives reboots.
  3. Optional: Game DVR is one of the callers; we also turned it off (HKLM\SOFTWARE\Policies\Microsoft\Windows\GameDVR AllowGameDVR=0). Game DVR reaches WARP through the path gated by 56095990, so it should not be needed once that flag is off — but we did not test with Game DVR re-enabled.

Root cause

  • Feature 0x10000009 (OS category, #9) is described in dxgkrnl's static feature table with flags 0x33: "in a VM connected to a host, always ask the host". No registry setting is involved.
  • IsFeatureEnabledHost asks the host through the adapter's own VMBus channel (adapter+0x1258). For the GPU-PV render adapter (vrd.sys) the channel exists. For WARP (BasicRender.sys) it is NULL → crash.
  • Both flags above add "exclusive video-encoder engine access" checks that query this feature on every adapter, including WARP. Microsoft's bug: no NULL check in the guest path.
  • Reproducer (crashes the guest instantly while flag 56095990 is enabled): MFStartup(0x20070) then MFTEnumEx({f79eac7d-e545-4387-bdee-d647d7bde42a}, MFT_ENUM_FLAG_HARDWARE | MFT_ENUM_FLAG_SORTANDFILTER, NULL, NULL, …).

What not to do

  • Do not disable the Microsoft Basic Render Driver (ROOT\BASICRENDER\0000). Disable-PnpDevice reports "Not supported" but still writes ConfigFlags=1; the next boot hangs (no dump), then WinRE "couldn't be repaired". Recovery: mount the VHDX offline, set SYSTEM\ControlSet001\Enum\ROOT\BASICRENDER\0000\ConfigFlags=0. Setting the BasicRender service to Start=4 has the same effect.
  • Do not hand-write FeatureManagement\Overrides\8\ keys. The key name is an obfuscated form of the ID (ViVeTool writes 56095990 as 3985002639); a key named with the raw ID is ignored, even though Windows adds TelemetryFlags=1 to it. Use ViVeTool.

If it comes back after a Windows update

A new code path may query WARP again. To find the caller without kernel debugging (and without turning off Secure Boot), run the suspect app under user-mode cdb with:

bu win32u!NtDxgkIsFeatureEnabled ".if (dwo(@rcx+4)==0x10000009) { k 60; r rax=0xC00000BB; r rip=poi(@rsp); r rsp=@rsp+8; gc } .else { gc }"

It prints the user-mode stack of each feature-9 query and fails the call instead of crashing the guest. Launch it in the interactive session (e.g. a scheduled task with RunLevel Highest) — apps started in session 0 may not reach their GPU code.

Open question

Before the fix, D3D games in the Hyper-V Connect Basic Session without a Moonlight/Sunshine client connected rendered on the CPU only (GPU not initialised, or ~1 FPS). After disabling the flags they render on the GPU in the Basic Session too, and Minecraft (OpenGL) started as well. Which change caused this is not verified yet.

Environment

  • Host: Windows Server 2025 (26100.33438), Hyper-V, NVIDIA driver 617.42 (32.0.16.1742), GeForce RTX 2060 SUPER partitioned at 40 %.
  • Guest: Windows 11 25H2 / 26H2 (26200.9711 → 26300.9711), dxgkrnl 10.0.26100.9711, mfplat 10.0.26100.9949, Gen 2, vTPM.
  • First crash: 2026-10-20. Fixed: 2026-10-27.
参与讨论