Arc Pro B70 + Arc B580 dual-GPU on Windows 11: WDDM graphics stack degrades within minutes

[PoizenJam1]

I am reporting a reproducible stability issue with a heterogeneous Battlemage configuration on Windows 11 that appears closely related to the Sparkle Arc Pro B60 plus Arc B580 case documented in community thread 1725782. My configuration is more recent and the symptom set is more thoroughly diagnosed, so I hope this report adds useful evidence.

The system is an ASUS ProArt Z890-CREATOR motherboard with a Core Ultra processor, BIOS 31.3.0.0, sixty-four gigabytes of DDR5 at JEDEC speeds, a Corsair HX1500i power supply, and Windows 11 build 26100. The graphics configuration is an Intel Arc Pro B70 (BMG-G31, thirty-two gigabytes) on CPU root port 00:07.0 and an Intel Arc B580 (BMG-G21, twelve gigabytes) on CPU root port 00:06.0, with the CPU's x16 link bifurcated x8/x8. The Core Ultra integrated graphics is also enumerated, so Windows reports three display adapters total. All three adapters consistently report Status OK and ProblemCode 0 in Device Manager, on the unified Intel Graphics Driver branch 32.0.101.8735.

The cards enumerate cleanly at boot and the system appears healthy initially. However, within minutes of normal operation, the WDDM graphics stack enters a degraded state that affects all WDDM consumers across all three adapters simultaneously. Specifically: hardware-accelerated transcoding via QuickSync in both Plex Media Server and Jellyfin fails immediately after FFmpeg's init_hw_device qsv call returns successfully but before any frames are encoded; RDP sessions trigger RdpIdd.dll user-mode driver framework bug-checks with ErrorNumber 0x050100040000010f at fxverifierbugcheck.cpp line 188, exhausting the WUDF restart budget within minutes; TeamViewer hangs indefinitely at "Starting Remote Session"; the Start menu and Explorer hang intermittently. The DistributedCOM event log shows continuous ten-thousand-and-ten timeouts on server {283EDD52-69B2-473D-BEB6-2C0B4C01FD73} (the DXCore adapter enumeration COM server) every fifteen to thirty minutes since the B70 was installed.

The most diagnostically interesting finding is that OpenArc, an OpenVINO-based inference server I run as a Windows service, is completely unaffected by these events. OpenVINO inference through the Level Zero compute path continues working normally even when every WDDM-graphics-path consumer is broken. I confirmed empirically that the failure affects all three adapters by reconfiguring transcoding on each in turn during a degraded period; transcoding fails on the iGPU, the B580, and the B70 alike. Recovery requires a full reboot. Restarting individual application services such as Plex Media Server or the Jellyfin Server is not sufficient.

The combination of facts strongly suggests the failure is not a per-adapter dropout but rather corruption of a shared graphics-stack component that all adapters depend on, with the Level Zero compute path unaffected because it does not traverse this component. The most likely candidates are the Intel user-mode display driver state, the WDDM kernel-mode shared adapter state, or DXGI/DXCore adapter enumeration handling.

A Group Policy change disabling hardware graphics adapters for Remote Desktop Services successfully stops the RdpIdd crash loop, but this is a workaround for a single consumer of the broken layer; transcoding, TeamViewer, and shell hangs continue.

I have ruled out several alternative hypotheses through testing. The single fatal WHEA PCIe error during the install sequence has not recurred and appears to have been a one-time event during a chaotic reboot cycle. Memory at JEDEC versus XMP made no difference. Driver installation procedure with Hyper-V and WSL2 fully shut down did not change the symptoms. The cards report no PCIe corrected error events in WHEA-Logger between the initial event and now, indicating the link itself is stable. The Intel-Gfx-Display-External event log shows no recent driver-side errors, suggesting the driver itself does not consider its state unhealthy at the points where consumers are failing.

Because I run several media servers (Plex and Jellyfin) streaming service on this machine, intermittent transcoding failures requiring manual reboots are not viable. I am planning to remove the B580 and run B70-only as the only currently available path to a stable production configuration, matching the resolution that the user in thread 1725782 ultimately adopted.

I would appreciate any of the following from Intel: confirmation whether this class of bug is acknowledged internally, whether a fix is planned for an upcoming driver release, whether there are diagnostic logs Intel would like me to capture before I remove the B580 (I can hold the configuration in its current state for a short additional window if useful), and whether Intel can provide guidance on whether two homogeneous Arc Pro B70 cards on Windows would be expected to avoid this class of failure given that it appears tied to heterogeneous adapter handling.

I have minidumps from the original crash sequence, the full DistributedCOM and DriverFrameworks-UserMode event timeline, and the FFmpeg transcode logs showing the exact failure point. I am happy to share any of these on request.

[VonM_Intel]

Hi PoizenJam1,
Thank you for posting in our Community. I understand that the system runs normally at first with the dual-GPU setup (Arc Pro B70, Arc B580, and iGPU), but within minutes the WDDM graphics stack degrades, affecting all WDDM-based workloads while Level Zero/OpenVINO remains unaffected suggesting a shared graphics stack or driver-layer issue rather than a single GPU failure.

To help me validate this further and narrow down the root cause, could you please assist with the following targeted checks:

• Does the issue still reproduce if you disable the iGPU in BIOS and run only the Arc Pro B70 + Arc B580?
• Have you tested running only one discrete GPU at a time (B70-only and B580-only) under the same workload conditions to confirm stability individually?
• Does the degradation timing change if hardware acceleration is disabled in applications like Plex, Jellyfin, or TeamViewer?
• Are all three adapters actively being utilized at the time the issue occurs, or does it also happen when only one adapter is in use?
• Have you tried switching the primary display adapter in BIOS (e.g., forcing PEG vs Auto)?
• Could you confirm if Resizable BAR (ReBAR) is enabled, and if disabling it changes the behavior?
• Do you observe any changes if you roll back to a previous driver version prior to 32.0.101.8735?
• Are there any differences when running without remote access tools (RDP/TeamViewer) active in the background?

Additionally, since you mentioned having logs and dumps available, we would greatly appreciate it if you could share the following for deeper analysis:

• Intel SSU (System Support Utility) report
• Relevant Event Viewer logs (DistributedCOM, DriverFrameworks-UserMode, WHEA)
• FFmpeg logs showing the exact failure point
• Any available minidumps from the crash sequence

Have a nice day!

Best regards,

Von M.
Intel Customer Support Technician

[PoizenJam1]

Thank you for the follow-up. I can answer some of these from current state; others require returning to the broken dual-GPU configuration, which I'm willing to do in a controlled window.

Already established:

• Single-card stability: B70-only has been fully stable under sustained transcoding, RDP, and TeamViewer load for about a day now. The B580 ran stable for approximately 1.5 years prior to the B70 install, across multiple CPU upgrades (13600K → 14700K → 14900KS → Core Ultra 270K Plus) and motherboard generations (Z690 → Z790 → Z890), always alongside the integrated graphics. No prior history of the symptoms documented in this report.
• Active utilization not required: failures occur even when only one adapter is being used at the application level. Triggering condition appears to be presence of multiple adapters, not concurrent use.
• Remote access not required: failures reproduce on local console with no RDP/TeamViewer connections. The DCOM 10010 cadence (15-30 minute intervals) was the dominant signature in the original configuration, but the controlled reseat test (B70 in primary, B580 in secondary) reproduced the user-facing failures with much quieter or absent DCOM 10010 events. The application-level failures are the constant signal; the DCOM 10010 cadence is configuration-dependent within the heterogeneous space.

Cannot answer without reproduction: iGPU-disabled-in-BIOS test, software-only fallback test, primary display BIOS toggle, ReBAR disabled.

Limited driver-rollback test space: Pro+consumer mixing is only supported on the unified branch from 32.0.101.8629 onward, and the bug is confirmed on both 8629 and 8735. The Pro driver branch doesn't enumerate the B580 (Code 31). No earlier viable target exists.

ReBAR caveat: Jellyfin documentation states ReBAR is required for Battlemage QSV; disabling it can cause media driver crashes independent of this bug. Will run if you want, but the result will need careful interpretation.

Proposed: rather than running these one at a time, I can reproduce the dual-GPU configuration over a single weekend window and test the variables in sequence. Suggested order by diagnostic value: (1) iGPU disabled, (2) software-only fallback, (3) primary display BIOS toggle, (4) ReBAR disabled. Please confirm priority and whether you'd like specific ETW trace providers enabled during capture.

Diagnostic bundle (SSU report, event logs, FFmpeg failure logs with successful working references for diff comparison, minidump analyses, topology data, and screenshots of user-facing errors) is prepared and available on request.

Secondary observation, lower severity: While running stable on single B70, Intel Graphics Software (Intel.GraphicsSoftware.App) is logging recurring IGCL exceptions every 20-30 minutes. The pattern is consistent: ctlEnumLeds and ctlMemoryGetBandwidth time out with NTSTATUS STATUS_TIMEOUT (0x40000102 / 1073741834); ctlGetFirmwareProperties returns STATUS_NOT_SUPPORTED (0x4000010D). No user-facing symptoms accompany these errors — transcoding, RDP, and TeamViewer all work normally. The ctlEnumLeds timeout may be expected if the B70 (a workstation card) has no RGB LEDs to enumerate, but the ctlMemoryGetBandwidth timeout is not similarly explained. Flagging as a separate, lower-severity issue distinct from the primary bug; the Intel Graphics Software log export is included in the diagnostic bundle.

(Note: I also have an open ticket via the Intel customer support portal. I've indicated there that the Community thread will be the primary venue for the technical investigation to avoid duplication; I'll mirror major findings to the portal as well.)

[PoizenJam1]

Quick correction/follow-up to the above:

I realized item (2) in my proposed test sequence ("software-only fallback", as queried by @VonM_Intel ) is actually already established by direct observation. During a broken state, switching Plex, Jellyfin, or TeamViewer from hardware-accelerated to software-only mode restores full functionality to those applications immediately, no reboot required. Re-enabling hardware acceleration in any of them re-triggers the failure state

This implies the degradation is specific to the hardware-accelerated request path rather than wholesale kernel-level corruption. software-rendering paths through the same applications continue to function while the broken state persists.

Updated test sequence for the proposed reproduction window: (1) iGPU disabled, (2) primary display BIOS toggle, (3) ReBAR disabled.

To be clear, though, ReBAR disabled is not a workable solution; though may be good for diagnostics.

[VonM_Intel]

Hello PoizenJam1,

I’ll need to conduct additional research on this issue and will post an update in this thread once I have more information about this matter.

Have a nice day!

Best regards,

Von M.
Intel Customer Support Technician

[PoizenJam1]

Interim update

I performed the dual-GPU w/ iGPU disabled. B580 in primary slot, B70 in secondary, monitor on B580, iGPU disabled in BIOS, same driver (32.0.101.8735). Sustained 48 hours under heavy load (continuous transcoding, RDP session churn, multiple TeamViewer sessions, mixed inference and transcode workloads) with zero DCOM events, zero RdpIdd crashes, zero transcoder failures.

This is the longest stable run in any heterogeneous Battlemage configuration tested. Original failing configuration's time-to-failure was variable, ranging from minutes to roughly 12-18 hours.

I'm going to cautiously conclude that the iGPU enabled appears necessary for the bug to surface. The B70 + B580 discrete pair seems stable on Windows when iGPU is disabled. Not conclusive, certainly, but the bug points toward a three-way interaction rather than general heterogeneous Arc incompatibility.

Additional findings since last update:

1. Software-only fallback recovers without reboot. During a broken state, switching Plex, Jellyfin, or TeamViewer to software-only mode restores those apps immediately. Re-enabling hardware acceleration re-triggers the failure. The degradation is specific to the hardware-accelerated request path, not wholesale kernel corruption.
2. Topology-independent within the heterogeneous space. Reseat test (B70 primary, B580 secondary) reproduced the failure. Slot positions don't determine whether the bug occurs, only timing variability.
3. TeamViewer's failure signature is Could not read the current screen resolution: 0 (DXGI desktop duplication can't enumerate output during broken state).

[PoizenJam1]

Two updates:

1. B580 + B70 with iGPU disabled in BIOS: stable for a full week of normal production load. No DCOM 10010 events, no RdpIdd crashes, no transcoder failures. iGPU-disabled looks like a solid workaround.

2. Dual B70 + iGPU enabled: still hit the bug. Got a second B70, tested the homogeneous Pro pair with iGPU re-enabled, transcoding failures came back same as before.

That rules out Pro/consumer heterogeneity as the trigger. Two identical B70s still fail with the iGPU present, so the issue is more about discrete-pair-plus-iGPU than about mismatched cards.

Caveat: this test was on the Arc Pro driver branch (clean DDU install before adding the second card), not the unified branch I used for everything prior. Happy to retest on the unified branch if you want a clean comparison, but the failure shows up either way.

On DCOM 10010: those events showed up in the dual B70 + iGPU run but were absent across the whole week of B580 + B70 + iGPU-disabled. Looks correlated with iGPU presence rather than the card mix, so probably symptomatic rather than causal.

Next step: disabling iGPU on the dual B70 setup and running a soak like the B580 + B70 one. Expecting it to hold but will confirm.