My PC frequently blue-screens with a DPC_WATCHDOG_VIOLATION when I join a voice channel in Discord while playing Battlefield 6. If I manage to start the game and voice chat separately, the system still crashes after about 20–30 minutes.
So far I have updated the USB, headset, GPU, video, and audio drivers; removed Corsair iCUE; reinstalled Discord; disabled hardware acceleration in Discord and Chrome; and disabled EXPO. I also ran MemTest86 for four passes with no errors.
The system uses a Ryzen 7 7800X3D, RTX 3080 Ti, Gigabyte B650 GAMING X AX V2 motherboard, and a Corsair Virtuoso SE wireless headset with a 2.4 GHz USB dongle. I have uploaded the available minidump files and am trying to determine whether the headset, network drivers, BIOS, chipset, or another device driver is responsible.
4 Answers
The suggestion about Intel Rapid Storage does not apply here: this is an AMD Ryzen system, not an Intel B560 platform. There is no reason to install Intel RST drivers, and Windows normally handles standard storage drivers unless a specific RAID setup is being used. Stick to the correct AMD chipset package, BIOS, network drivers, and device-isolation tests.
Minidumps do not contain enough information to identify the offending driver with confidence. Configure Windows to create kernel or automatic memory dumps, then inspect the next crashes with WinDbg. Running !dpcs and !dpcwatchdog, along with the full Analyze -v output, should provide a much better view of which driver is spending too long at an elevated interrupt priority. Be careful when sharing complete kernel dumps because they can contain data that was present in memory, so sharing the debugger output is safer.
Since the failure happens when the wireless headset becomes active, isolate that hardware first. Try gaming without the Corsair USB receiver, move the receiver to a different USB port, and test with wired audio or a different headset. Also check whether the motherboard's Wi-Fi and LAN drivers are current, because the dump references network-related components and voice chat increases network activity.
The minidumps point more toward the networking stack than directly to the microphone. tcpip.sys and ndu.sys appear consistently, although those Windows components may simply be where the underlying driver failure becomes visible. Update the motherboard BIOS and install the current network and chipset drivers from Gigabyte's support page. If the crashes continue, temporarily test with the wireless headset dongle disconnected or use another audio device to see whether the 2.4 GHz device is triggering the problem.
Thanks for the detailed analysis. I updated the BIOS and will work through the driver and isolation tests before collecting more crash data.
That makes sense. The chipset package was updated to a newer version, and I will avoid installing unrelated Intel storage drivers.