BSOD VIDEO_DXGKRNL_FATAL_ERROR on USB-C

[Henriik]

I have an "HP ZBook Firefly 14 inch G8 Mobile Workstation PC" with Windows 11 23H2 with GPUs Intel Xe Graphics and Nvidia Quadro T500. I get BSOD "VIDEO_DXGKRNL_FATAL_ERROR" when waking computer from sleep when computer is connected to a Samsung monitor (LC34H890WJUXXE) through USB-C. It can also happen when unplugging and plugging in USB-C cable. It does not happen when connected to same monitor through HDMI. It does also not happen when Nvidia GPU is disabled in windows device manager. Since we have several of these Samsung monitor models in the office I have found at least one monitor where I don't get the BSOD connected on USB-C. Have not been able to replicate the issue connected through USB-C to other monitors though, like Lenovo. I know at least one more person with same computer and monitor having exact same issue so it is not only related to my computer only.

I had a support case with Nvidia since the BSOD dump pointed at a Nvidia file crashing (The dxgkrnl has detected that a violation has occurred.). Nvidia found the BSOD having the code P1:1d4 and this code could indicate a specific hardware issue, but based on the presence of the UcmUcsiCx.sys dump file, it seems related to the USB Type-C Connector System Software Interface (UCSI). This might point to an issue with USB or related power management hardware/software, power loss through the Ports while it goes into the Sleep mode and tries to come back online.

As UcmUcsiCx.sys is involved, it might be related to improper handling of sleep/hibernation states, particularly if a device was connected to a USB-C port during a power state transition. So this confirms that this issue happens only during the power transition. Problems with the UcmUcsiCx.sys driver or the hardware controlling USB Type-C ports could be involved. This could stem from:
- Driver Corruption
- A problematic USB-C device connected during the crash
- Firmware problems involving USB-C

What has been tested without helping the problem

• Run Windows Memory diagnostics (Extended mode/Cache=On) - No errors
• Updated Windows
• Upgraded BIOS
• Upgraded Chipset drivers
• Cleaned Nvidia drivers with DDU and installed latest from Nvidia and HP support pages respectively
• Disabled in Windows "Settings>Bluetooth & Devices>USB>USB battery saver"
• Disable Power-Saving Mode for USB-C Ports (Thunderbolt Controller) in Windows "Device Manager>System devices>Thunderbolt™ Controller – 9A1B>Power Management tab"

Workaround that prevents the BSOD from happening

In the end I found a workaround that does not cause the BSOD
-- Prevent Windows from Turning Off USB Devices to Save Power (Device Manager)
In Device Manager under Universal Serial Bus controllers section. I tested my way through and when I on both “Generic USB Hub” from Power Management tab removed the checkbox from “Allow the computer to turn off this device to save power” I stopped getting the BSOD after sleep.

So the issue seems to happen on a combination involving Nvidia/Samsung/USB-C. So now the question is, whats next.

Anyone experienced this? Or could this be a USB-C firmware issue or issue with the USB-C in the combination with Samsung.
Perhaps I should submit a real support case to HP on this?

[Henriik · Accepted solution]

I submitted a HP support case and we concluded that this looks like a rare compatibility issue since most things have been troubleshooted and ruled out. HP also recommended to contact Samsung which I did. There are no updates for that monitor so they suggested to reset the monitor, and test with another computer model on same monitor in same way. After that if nothing comes up I think we are at a dead end and have to live with the workaround.

[Shimaco]

Hello, I 'm using the same combination (NTB/Display connected via USB-C).

Just want to thank you for workaround. After spending time with driver installation,  display resetting, OS updating only your  solution is working fine. 🙂

[Henriik]

Just to follow up and conclude this topic. The suggestions from Samsung did not help either so the assumption is that this is an compatibility issue. So the described workaround seems to be the only way to avoid the issue in this case. And nice to see that this post at least helped someone. 🙂