[Bug]: Four MTT VDD virtual monitors on Windows build 26200 show repeated DWM/DXGI/IndirectDisplays instability; installed driver predates PR #482

[NickM83]

Which OS?

Win11 Pro

Which release?

Other..

Driver Version

9.44.37.929 Driver date: 2026-05-11

Device Specifications

CPU: 12 logical processors assigned to QEMU/KVM VM
RAM: 64 GB currently assigned
MOBO/Platform: QEMU, Standard PC (Q35 + ICH9, 2009); Proxmox/KVM host per operator setup
OS: Windows reports Windows 11 Pro, 25H2, build 10.0.26200.8457

NVIDIA:

• GPU: NVIDIA RTX PRO 6000 Blackwell Workstation Edition
• pnputil package version: 04/23/2026 32.0.15.9636
• nvidia-smi driver version: 596.36

Display setup:

• 4 active MTT VDD virtual monitors
• Active CCD path count: 4
• VDD adapter: Virtual Display Driver, ROOT\DISPLAY\0000, status OK
• VDD monitor endpoints: DISPLAY\MTT1337 UID256, UID257, UID258, UID259, all status OK
• NVIDIA adapter: NVIDIA RTX PRO 6000 Blackwell Workstation Edition, status OK
• NVIDIA monitor endpoint: DISPLAY\NVD0000, Generic Monitor (NVIDIA VGX), status OK
• nvidia-smi: Display Attached = Yes
• nvidia-smi: Display Active = Disabled

Describe the bug

I am seeing repeated VM instability while running four active MTT VDD virtual monitors.

The installed MTT VDD driver on the affected VM is:

• Provider: MikeTheTech
• Version: 9.44.37.929
• Driver date: 2026-05-11
• Original INF: mttvdd.inf
• Published INF: oem19.inf

The installed MTT VDD package on the affected VM is dated 2026-05-11. PR #482 was merged on 2026-05-18 and is titled:

"Fix multi-monitor swapchain threading for issue #449"

PR #482:
#482

Issue #449:
#449

The affected VM uses 4 active MTT VDD monitors, so issue #449 / PR #482 appear directly relevant. I am not claiming this proves VDD is the sole root cause, but this is the strongest matching driver-side fix boundary I have found.

The failures present in two forms:

1. Silent resets:

• Kernel-Power 41 with BugcheckCode=0
• No fresh MEMORY.DMP/minidump
• No planned User32 restart evidence in the investigated incidents

2. Nonzero bugchecks / hard failures:

• Some incidents produce minidumps or MEMORY.DMP
• WinDbg has classified some as memory_corruption / MEMORY_CORRUPTION_LARGE
• These are not all in the same user process context

Across multiple incidents, final ETW before failure repeatedly shows heavy display/composition activity, especially:

• Microsoft-Windows-Dwm-Core
• Microsoft-Windows-DxgKrnl
• Microsoft-Windows-IndirectDisplays-ClassExtension-Events
• Microsoft-Windows-DXGI
• Microsoft-Windows-Direct3D11

This does not prove VDD is the sole root cause, but the common factor is four active MTT VDD monitors plus repeated DWM/DXGI/DxgKrnl/Direct3D11/IndirectDisplays activity immediately before failure.

Steps to reproduce

I cannot force the failure on demand, but the recurring setup is:

1. Run Windows build 26200 in a QEMU/KVM VM.
2. Install MTT VDD version 9.44.37.929 dated 2026-05-11.
3. Configure 4 active MTT VDD virtual monitors.
4. Run the VM for extended periods with normal desktop/remote-access usage.
5. Observe intermittent silent resets or nonzero bugchecks/hard failures.
6. Review final ETW before failure; the final window repeatedly contains heavy DWM/DXGI/DxgKrnl/Direct3D11/IndirectDisplays activity.

Expected behavior

Four active MTT VDD virtual monitors should remain stable under normal Windows desktop composition and remote-access use, without silent resets, hard locks, or memory-corruption bugchecks.

The VM intermittently silently resets or bugchecks. Multiple investigated incidents show final ETW activity concentrated in the Windows display/composition path involving DWM, DxgKrnl, DXGI, Direct3D11, and IndirectDisplays.

Log File

Verified current system state:

• OS reports: Windows 11 Pro, 25H2, build 10.0.26200.8457
• VM platform reports: QEMU, Standard PC (Q35 + ICH9, 2009)
• Logical processors: 12
• Current RAM: approximately 64 GB
• Active display path count: 4
• MTT VDD adapter status: OK
• NVIDIA adapter status: OK
• Four MTT monitor endpoints are present and OK
• NVIDIA monitor endpoint is present and OK
• nvidia-smi reports Display Attached = Yes
• nvidia-smi reports Display Active = Disabled

Selected verified incidents:

2026-05-29 14:15:43:

• Kernel-Power 41 BugcheckCode: 0
• Classification: silent reset
• Fresh dump count after reset: 0
• Manual ETW slice from 14:14:00 to 14:14:07 contained 39,071 events:
  • Dwm-Core: 21,007
  • DxgKrnl: 6,427
  • IndirectDisplays-ClassExtension: 4,940
  • DXGI: 2,685
  • Direct3D11: 1,911

2026-05-28 18:26:07:

• Kernel-Power 41 BugcheckCode: 0
• Classification: silent reset
• No fresh MEMORY.DMP, minidump, or WDF dump found in the saved review
• No planned restart evidence found in the saved review

2026-05-24 02:00:43:

• Classification: nonzero bugcheck
• Bugcheck: 0xA IRQL_NOT_LESS_OR_EQUAL
• Dump produced
• WinDbg classified it as memory_corruption / MEMORY_CORRUPTION_LARGE
• Final 10 seconds ETW:
  • IndirectDisplays: 864
  • Dwm-Core: 448
  • DxgKrnl: 288
  • DXGI: 100
  • Direct3D11: 14
• Excel was not present in final 10-minute PID recorder rows
• PowerToys was not present in final 10-minute PID recorder rows

2026-05-23 06:37:

• Classification: nonzero bugcheck
• Bugcheck: 0xD1 DRIVER_IRQL_NOT_LESS_OR_EQUAL
• Fresh minidump produced
• WinDbg classified it as memory_corruption / MEMORY_CORRUPTION_LARGE
• Final 10 seconds ETW:
  • Dwm-Core: 2,824
  • DXGI: 722
  • DxgKrnl: 512
  • Direct3D11: 495
  • IndirectDisplays-ClassExtension: 440

Contact Details

Please contact me through this GitHub issue. I can provide redacted logs or selected summaries if useful.

[NickM83]

1. Does the latest signed release include PR Fix multi-monitor swapchain threading for issue #449 #482 / the fix for issue [Bug]: Performances drop when declaring 3 virtual screens and more #449?
2. If not, is there a signed beta/test build containing the per-monitor swapchain fix?
3. Is 4-monitor use expected to be stable on Windows build 26200?
4. Are there recommended settings for 4-monitor stability, for example disabling hardware cursor or limiting mode lists?
5. Is it expected that \.\pipe\MTTVirtualDisplayPipe is created with broad local access and can accept RELOAD_DRIVER / SETDISPLAYCOUNT style commands?
6. Could reload/display-count changes during active DWM composition destabilize multi-monitor swapchain handling?
7. Is the current ReloadDriver path expected to use the named pipe handle for WDF context lookup, or should reload be routed through the actual adapter/device context?

[stg43x]

I have BSODs too on 2 real physical pc 9600x + 5070ti. And a lots of errors in event manager like "A runtime error occurred in the user driver MttVDD.dll, and the hosting process was terminated. This may temporarily disrupt access to devices. For more information about this issue, contact the device manufacturer or driver provider." Im using win11 25h2. Any fix? 25h2 isnt supported?