HYPERVISOR_ERROR (0x00020001) on hybrid iGPU+dGPU system

[biolau]

Summary

On a Ryzen 9 7950X3D (Radeon iGPU) + RTX 5090 system, DisplayLink 12.3 caused 17 kernel bugchecks over four days. Disabling the AMD integrated GPU in Device Manager stopped them completely. The dGPU and the USB monitor are both still in use - only the iGPU is off.

I believe the IDD was selecting the iGPU as its render adapter while the desktop was on the RTX 5090, making every frame a cross-adapter copy. I have not been able to confirm that attribution directly, so I'm reporting the evidence and letting you judge the mechanism.

System

• Windows 11 Pro 25H2, build 26200.9457
• MSI PRO B650-P WIFI (MS-7D78), BIOS 1.M3
• Ryzen 9 7950X3D (integrated Radeon, PCI\VEN_1002&DEV_164E)
• NVIDIA RTX 5090, driver 32.0.16.1692
• AMD Radeon(TM) Graphics, driver 32.0.21045.5002
• 128 GB DDR5 (4x32 GB), running at 3600, no EXPO/XMP
• ASUS MB169B+ USB monitor (VID_17E9 / PID_FF0B), single USB 3.0 connection
• DisplayLink Graphics 12.3.5011.0

Two active displays: a Vizio V405-G9 at 3840x2160 (primary) on the RTX 5090, and the MB169B+ at 1920x1080 as the secondary, via DisplayLink. Onboard video output is not connected to anything.

Symptoms

Two failure modes, which I now think are the same event with different outcomes.

1. Soft hang (survivable). Dragging a window onto the MB169B+ - Spotify was the reliable trigger - freezes the whole machine for a few seconds. The primary display goes black as if it's about to bugcheck, then recovers and everything continues normally.

2. Hard bugcheck. Starting a Microsoft Teams screen share with the MB169B+ connected crashes the machine within seconds. Not always on the first share, but reliably within a few attempts.

The bugcheck is identical every time, across all 17 occurrences:

BugCheck 0x00020001 (HYPERVISOR_ERROR)
Arguments: 0x0000000000000028, 0x0000000000000002,
           0x6500000000000000, <varying pointer>
Faulting stack: amdppm!HvRequestIdle

Worth flagging for anyone who finds this thread by searching the stack: the amdppm frame is a red herring. HvRequestIdle is the CPU idle path. What that stack records is where the NMI watchdog found a parked core when the system stalled - not the code that stalled it. I spent three days chasing CPU power management because of it.

Isolating test

This is the part I'd point an engineer at:

1. MB169B+ unplugged -> started a Teams meeting, shared the primary screen for several minutes. No hang, no crash.
2. MB169B+ plugged back in -> crashed almost immediately.

Nothing else changed between the two runs.

Workaround

Disabling the integrated GPU:

Disable-PnpDevice -InstanceId 'PCI\VEN_1002&DEV_164E&SUBSYS_7D781462&REV_C9\4&27E89230&0&0041' -Confirm:$false

Since then: zero bugchecks, zero soft hangs, Teams screen sharing works, and the MB169B+ works normally on the RTX 5090. Bugcheck count has stayed frozen at 17.

The cost is losing motherboard video output, the AMD hardware encoder, and any fallback display if the 5090 fails. That's a real cost, and it shouldn't be the price of using a USB monitor.

Ruled out by direct testing

Listing these so nobody repeats them:

• BIOS update 1.M2 -> 1.M3, and a full BIOS reset to defaults
• Global C-state Control = Disabled in BIOS
• powercfg processor idle disabled
• VBS / HVCI / Memory Integrity disabled
• AMD 3D V-Cache service (amd3dvcacheSvc) stopped and disabled
• msconfig clean boot, plus manually disabling every auto-start MSR driver (Ryzen Master V29/V31, AIDA64, NTIOLib)
• Clean DisplayLink uninstall with the Installation Cleaner, 12.2 -> 12.3
• Removing a duplicate stale dlusbaudioext.inf
• Teams as a cause: it updated two days after the first crash

Zero WHEA errors throughout, before anyone suggests hardware - though I'd note a hung core doesn't raise a machine check, so WHEA silence never actually excluded hardware either.

Questions

1. How does the IDD choose its render adapter on a hybrid iGPU + dGPU system?
2. Is there a supported way to pin it to a specific GPU? Windows' own Graphics Settings per-app GPU preference doesn't appear to apply to the virtual display adapter.
3. Should the cross-adapter path be able to hang the system at all? Even if the iGPU is a bad choice here, a stall in a frame copy seems like it ought to fail gracefully rather than take the machine down.
4. Is this specific to the DL-195 generation, or would a newer dock behave the same way?

Two minor things noticed along the way

Installation Cleaner leaves drivers staged. After running DisplayLink Installation Cleaner 11.7.4208.0, pnputil /enum-drivers still showed a DisplayLink INF that had to be removed manually with pnputil /delete-driver oemNN.inf /uninstall /force

Version mismatch after a clean 12.3 install. My currently staged INFs:

oem39.inf  dlidusb.inf          12.3.5011.0   (Display)
oem30.inf  dlusbaudioext.inf    12.3.4372.0   (Extension)
oem38.inf  dlcdcncm.inf         12.3.4372.0   (Net)

The display driver is 5011 but the audio extension and NCM components are still 4372, after a clean install of 12.3.5011.0. Possibly intentional, but it looked wrong enough to mention.

Happy to collect logs, dumps, or run any diagnostic build - I still have all 17 minidumps and can re-enable the iGPU to reproduce on request.