Frequent BSODs with USB4/PD setup – Framework 16 with dual external monitors

[Romano_Tessmer]

Hello Community, Framework Support Team,

I am experiencing recurring BSODs on my Framework 16 when using an external monitor via USB-C with Power Delivery enabled.

System configuration

• Framework 16 (AMD 7940HS + Radeon 7700S)

• Windows 11

• BIOS and USB4 drivers updated to the latest available versions

• Two external monitors: KTC M27P20 Pro 14 (144Hz Setting)

• Cables: Amazon Basics USB4/TB4 40Gbps, 240W, USB-IF certified (1 m)

• Power supply: Power Delivery Monitor 1.

Connection setup when crashes happened

• Monitor 1: connected via USB-C (left side) , providing both video + PD charging to the Framework 16

• Monitor 2: connected via the dedicated dGPU USB-C (DP Alt Mode)

• Framework was being charged directly from the monitor via PD (no charger connected at that time)

Problem

• While using the monitor with PD enabled, the system experienced frequent BSODs and freezes.

• Crashes show BugCheck/Watchdog events, often pointing to PCIe / USBXHCI / ACPI in the dumps.

• No WHEA Logger entries appear – the system goes directly into a BugCheck.

• After switching to a setup where I disconnected USB-C PD from the monitor 1 and only use the original Framework charger, stability improved.

• Event Viewer export around the time of crashes

Already tested

• Full memory test – no errors

• Reinstalled AMD graphics and chipset drivers

• Tested both Hybrid mode and dGPU-only mode in Adrenalin – issue persists

• Switched to USB-IF certified USB4/TB4 cables – issue persists

• Eventually removed monitor PD Monitor1. (Framework now charged only via original power adapter) and connected via Cable Matters USB-C → DP 2.1 VESA certified – Monitor2 USB-C dGPU DP-AltMode - no crashes

• Conclusion:
  The problem seems strongly linked to USB-C Power Delivery from the external monitor in combination with USB4/PCIe stability on the Framework 16.
  Since certified cables and multiple driver versions were tested, this appears to be a firmware/controller issue.

Could you tell me if a firmware fix or workaround exists?

Thank you very much,
Romano from Berlin

[Romano_Tessmer]

Hello again,

Unfortunately, I experienced another system crash today (dump file) even after fully isolating my setup as advised.

Current setup (stable configuration test)

• Framework 16 (AMD 7840HS + Radeon 7700S)

• BIOS, EC, and USB4 firmware up to date

• Official Framework charger connected on the right-side USB-C port (power only)

• Monitor 1: connected via Cable Matters USB-C → DisplayPort 2.1 (VESA certified) – video only, no PD

• Monitor 2: connected via rear dGPU USB-C (DP Alt Mode)

• Cables: all USB-IF certified USB4/TB4 (40 Gbps, 240 W)

• PD (Power Delivery) from both monitors completely disabled

Problem persists

Even under this configuration — with certified cables, PD isolated, and stable power supply — I still encountered a BugCheck/Watchdog crash.
The dump shows the same recurring modules as before:

• USBXHCI.SYS

• PCI.SYS

• ACPI.SYS

This suggests a USB4/PCIe communication failure at hardware or firmware level.

There are no WHEA-Logger events in the Event Viewer; the system goes directly into a BugCheck.

Attached

• New minidump

• System Event Viewer export around the crash time

• Previous dumps and configuration summary for reference

Summary

All external factors (cables, PD, drivers, monitors) have been verified and ruled out.
At this point, the issue seems to originate from the USB4/PCIe controller firmware or hardware.

Could you please escalate this to engineering for review, and confirm whether a new firmware or NVM update for USB4/Thunderbolt stability is in progress?

Thank you very much for your continued assistance,
Romano from Berlin

[James3]

Hi.
This community forum is mainly other users like you.
If you wish official FW support, you need to raise the support request via the FW web site.
I am another user like you.
It might be a power issue.
Try to make sure that all devices connected use 3 pin mains plugs.
While 2 pin devices are OK on their own, once you connect multiple devices together, each with their own mains plug, they need to be 3 pin plugs.

So, one test of that theory might be remove monitor 2, so only monitor 1 remains, and thus only one mains cable in use.

The problem is not related to doing PD or not. It is that the 0V / GND can drift and mismatch when only 2pin mains plugs are used.

[Romano_Tessmer]

Hi, thanks for your reply, but I don’t think the grounding explanation applies in this case.

The power supplies of my KTC monitors are Class II (double-insulated, 2-pin, no protective earth) by design, which means they are galvanically isolated and do not introduce a ground loop or 0V reference drift into the system. This is compliant with IEC/EN 62368-1 and normal for most USB-C/PD monitors today.

Also:

• USB-C with Power Delivery uses isolated DC negotiation, not earth reference.

• USB4/PD systems are specifically designed to work safely in floating ground environments.

• If this were a grounding issue, I would expect noise, flickering, USB disconnects, or coil whine – but instead I get repeated BugCheck/Watchdog crashes related to USBXHCI/PCIe, which clearly point to the USB4/PD stack.

I already tested:
Different outlets and power strips
Different certified USB4/TB4 cables
Disabled monitor PD by powering the laptop only via the Framework charger
Reproduced crashes consistently when using USB-C displays

So this is not an AC mains or grounding issue, but rather a USB4/PCIe controller stability problem, confirmed by multiple minidumps.

I appreciate your help, but I’m going to escalate this to Framework Support with full crash diagnostics, as this seems firmware/USB4 related.

[James3]

Regarding the 2pin vs 3pin.
I only mentioned it because another user solved their problems moving to 3pins on all plugs. They were even seeing small sparks when connecting usb cables!

Sparks are coming from the USB-C Ports when inserting cable of Hub

The 3 different monitors, do they have two pin or three pin (with ground) AC power cords? The ugreen charger is the only one you have for your Framework? Any with a 3 pin grounded AC cord? Even if it’s fairly low wattage / not something you would normally use.

So, maybe don’t discount it immediately.

Just for clarity, the cause you are suggesting is also just as likely to be right.

It might also be related to these problems:

USB-C Problems with USB-PD cycling every second (ANG)

[FW16-180W-PSU] This is a image of the FW16 Laptop being connected to the FW 180W PSU with the oscilloscope on the CC1 pin. I hope you can see that image OK. The oscillations on the left are what one sees on the FW16 USB-C port before one plugs in a FW16 180W PSU into it. As you can see, a majority of the level is at 1.6V (during idle time) with a small bit in the middle where it is at 0.88V (during idle time). If you leave the scope on, you continue to see the occasional pulse of a CC mes…

And also possibly the DP failing to properly negotiate swing and pre-emphasis.

[Romano_Tessmer]

Crash Dump
Analysis

---

Crash dumps are enabled on your computer. This system is not configured for
complete or automatic crash dumps. For best results, configure your system to
write out complete or automatic crash dumps. Select Tools->Crash Dump
Configuration from the main menu to configure your system to write out complete
memory dumps.

Crash dump directories:

C:\WINDOWS

C:\WINDOWS\Minidump

On Fri 10.10.2025 23:02:46 your computer crashed or a problem was reported

|
|
|----|

Crash dump
file:

|
|
|----|

C:\WINDOWS\Minidump\101025-17062-01.dmp
(Minidump)

|
|
|----|

Bugcheck code:

|
|
|----|

0x1000007E(0xFFFFFFFFC0000005,
0xFFFFF806A78A70C7, 0xFFFFD90730665F78, 0xFFFFD90730665780)

|
|
|----|

Bugcheck name:

|
|
|----|

SYSTEM_THREAD_EXCEPTION_NOT_HANDLED_M

|
|
|----|

Bug check
description:

|
|
|----|

This indicates
that a system thread generated an exception which the error handler did not
catch.

|
|
|----|

Analysis:

|
|
|----|

This is likely a
software problem which means that it was probably caused by a bug in a
driver.

There is a possibility that this is caused by memory corruption. Memory
corruption can be caused by a faulty driver, faulty RAM, overheating and
more. Read this article on memory corruption. Read this article on thermal
issues

On Tue 30.09.2025 21:48:54 your computer crashed or a problem was reported

|
|
|----|

Crash dump
file:

|
|
|----|

C:\WINDOWS\Minidump\093025-15609-01.dmp
(Minidump)

|
|
|----|

Bugcheck code:

|
|
|----|

0x3B(0xC0000005,
0xFFFFF80098D4AB8B, 0xFFFFBA81E7B7D8F0, 0x0)

|
|
|----|

Bugcheck name:

|
|
|----|

SYSTEM_SERVICE_EXCEPTION

|
|
|----|

Driver or
module in which error occurred:

|
|
|----|

dxgmms2.sys
(dxgmms2+2ab8b)

|
|
|----|

File path:

|
|
|----|

dxgmms2.sys

|
|
|----|

Description:

|
|
|----|

DirectX Graphics
MMS

|
|
|----|

Product:

|
|
|----|

Microsoft®
Windows® Operating System

|
|
|----|

Company:

|
|
|----|

Microsoft
Corporation

|
|
|----|

Bug check
description:

|
|
|----|

This indicates
that an exception happened while executing a routine that transitions from
non-privileged code to privileged code.

|
|
|----|

Analysis:

|
|
|----|

This is a typical
software problem. Most likely this is caused by a bug in a driver. A DirectX
driver was identified on the stack. Since there is no other responsible
driver detected, it is suggested that you look for an updated driver for your
graphics hardware. It’s also possible that your graphics hardware was
non-functional or overheated.

On Fri 26.09.2025 10:45:51 your computer crashed or a problem was reported

|
|
|----|

Crash dump
file:

|
|
|----|

C:\WINDOWS\Minidump\092625-17140-01.dmp
(Minidump)

|
|
|----|

Bugcheck code:

|
|
|----|

0x3B(0xC0000005,
0xFFFFF804816502AC, 0xFFFFAB80878AD8D0, 0x0)

|
|
|----|

Bugcheck name:

|
|
|----|

SYSTEM_SERVICE_EXCEPTION

|
|
|----|

Bug check
description:

|
|
|----|

This indicates
that an exception happened while executing a routine that transitions from
non-privileged code to privileged code.

|
|
|----|

Analysis:

|
|
|----|

This is a typical
software problem. Most likely this is caused by a bug in a driver.

On Wed 24.09.2025 01:25:25 your computer crashed or a problem was reported

|
|
|----|

Crash dump
file:

|
|
|----|

C:\WINDOWS\Minidump\092425-15953-01.dmp
(Minidump)

|
|
|----|

Bugcheck code:

|
|
|----|

0x3B(0xC0000005,
0xFFFFF80239D0AB8B, 0xFFFFA981D537D8D0, 0x0)

|
|
|----|

Bugcheck name:

|
|
|----|

SYSTEM_SERVICE_EXCEPTION

|
|
|----|

Driver or
module in which error occurred:

|
|
|----|

dxgmms2.sys
(dxgmms2+2ab8b)

|
|
|----|

File path:

|
|
|----|

dxgmms2.sys

|
|
|----|

Description:

|
|
|----|

DirectX Graphics
MMS

|
|
|----|

Product:

|
|
|----|

Microsoft®
Windows® Operating System

|
|
|----|

Company:

|
|
|----|

Microsoft
Corporation

|
|
|----|

Bug check
description:

|
|
|----|

This indicates
that an exception happened while executing a routine that transitions from
non-privileged code to privileged code.

|
|
|----|

Analysis:

|
|
|----|

This is a typical
software problem. Most likely this is caused by a bug in a driver. A DirectX
driver was identified on the stack. Since there is no other responsible
driver detected, it is suggested that you look for an updated driver for your
graphics hardware. It’s also possible that your graphics hardware was
non-functional or overheated.

On Sat 20.09.2025 18:01:23 your computer crashed or a problem was reported

|
|
|----|

Crash dump
file:

|
|
|----|

C:\WINDOWS\Minidump\092025-17203-01.dmp
(Minidump)

|
|
|----|

Bugcheck code:

|
|
|----|

0x1000007E(0xFFFFFFFFC0000005,
0xFFFFF8067A8E1D54, 0xFFFFE008E5D7EE38, 0xFFFFE008E5D7E620)

|
|
|----|

Bugcheck name:

|
|
|----|

SYSTEM_THREAD_EXCEPTION_NOT_HANDLED_M

|
|
|----|

Bug check
description:

|
|
|----|

This indicates
that a system thread generated an exception which the error handler did not
catch.

|
|
|----|

Analysis:

|
|
|----|

This is likely a
software problem which means that it was probably caused by a bug in a
driver.

There is a possibility that this is caused by memory corruption. Memory
corruption can be caused by a faulty driver, faulty RAM, overheating and
more. Read this article on memory corruption. Read this article on thermal
issues

On Thu 21.08.2025 09:28:24 your computer crashed or a problem was reported

|
|
|----|

Crash dump
file:

|
|
|----|

C:\WINDOWS\LiveKernelReports\UcmUcsiCx.sys-20250821-0928.dmp
(Kernel memory dump)

|
|
|----|

Bugcheck code:

|
|
|----|

0x1D4(0x0, 0x5,
0xFFFF8B8CBAB05120, 0x102)

|
|
|----|

Bugcheck name:

|
|
|----|

BUGCODE_NDIS_DRIVER_LIVE_DUMP

|
|
|----|

Driver or
module in which error occurred:

|
|
|----|

UcmUcsiCx.sys
(UcmUcsiCx+0x2514E)

|
|
|----|

File path:

|
|
|----|

C:\WINDOWS\System32\Drivers\UcmUcsiCx.sys

|
|
|----|

Description:

|
|
|----|

UCM-UCSI KMDF
Class Extension

|
|
|----|

Product:

|
|
|----|

Microsoft®
Windows® Operating System

|
|
|----|

Company:

|
|
|----|

Microsoft
Corporation

|
|
|----|

Bug check
description:

|
|
|----|

This bug code
indicates that NDIS has captured a live kernel dump. NDIS does not generate a
bug check in this situation.

|
|
|----|

Analysis:

|
|
|----|

This is a NDIS
(network) related crash.

On Sat 05.07.2025 13:34:26 your computer crashed or a problem was reported

|
|
|----|

Crash dump
file:

|
|
|----|

C:\WINDOWS\Minidump\070525-17765-01.dmp
(Minidump)

|
|
|----|

Bugcheck code:

|
|
|----|

0x1000007E(0xFFFFFFFFC0000005,
0xFFFFF80285BB9CA3, 0xFFFFB7835895CCC8, 0xFFFFA780B89ED8D0)

|
|
|----|

Bugcheck name:

|
|
|----|

SYSTEM_THREAD_EXCEPTION_NOT_HANDLED_M

|
|
|----|

Bug check
description:

|
|
|----|

This indicates
that a system thread generated an exception which the error handler did not
catch.

|
|
|----|

Analysis:

|
|
|----|

This is likely a
software problem which means that it was probably caused by a bug in a
driver.

There is a possibility that this is caused by memory corruption. Memory
corruption can be caused by a faulty driver, faulty RAM, overheating and
more. Read this article on memory corruption. Read this article on thermal
issues

---

Conclusion

---

7 crash dumps have been found and analyzed. No offending third party drivers
have been found. Consider using WhoCrashed Professional which offers more
detailed analysis using symbol resolution. Also configuring your system to
produce a full memory dump may help you.

Read the suggestions displayed in the bugcheck analysis above.

The analysis process took 0:00:11 (h:mm:ss).

[Romano_Tessmer]

Update:

1. USB-C / USB4 display output directly from the mainboard (without expansion cards)
Yes, this scenario has effectively already been covered:

• The issue occurs with USB-C → DisplayPort video-only cables, regardless of which expansion slot is used.

• I have tested different port positions and configurations.

• The behavior remains the same:

  • Stable with internal display only

  • Unstable as soon as external USB-C displays are connected

Given that the issue is reproducible across multiple ports and configurations, this strongly suggests that the problem is not isolated to a single expansion card or slot, but rather to the USB-C / USB4 display path itself.

That said, I can repeat this test explicitly with all expansion cards removed and will report back, but based on prior results I do not expect a change in behavior.

---

2. Other USB-C devices
Yes, I have connected other USB-C devices (non-display peripherals).
These devices function normally and do not trigger system instability.

The crashes occur only when USB-C is used for DisplayPort / external display output.
This further narrows the issue to the USB-C / USB4 DisplayPort Alt-Mode path, not general USB-C functionality.

---

Updated consolidated status

• BIOS: 4.02

• Mainboard reset: completed

• Windows integrity: verified (CHKDSK, SFC, DISM – no issues)

• Drivers: clean installs tested, including minimal AMD driver (no Adrenalin)

• Power: original Framework AC adapter only

• Displays:

  • Both external monitors connected via USB-C → DisplayPort (video-only)

  • No Power Delivery from monitors

• Stability:

  • Internal display only → stable for multiple days

  • External USB-C displays → repeated crashes, increasing in frequency

Multiple crash dumps have been provided, including the latest:

• 011926-17937-01.dmp

All available evidence continues to point to a USB-C / USB4 / DisplayPort Alt-Mode instability, independent of expansion cards, drivers, or Power Delivery.

[James3]

I think you might be able to find a more up to date BIOS. 4.0.3
It might be worth a try.
The updated BIOS changes the UCSI interface slightly, that may help with the crashes.

As you have found, the problem appears to be with the USB-C Power delivery from the monitors.