I suggest you look at your network adapter driver and see whether there is an update available for it. This appears to be the problem driver.
I guess you might want some justification for me pointing at the network driver, so I'll try and explain why I am saying that. This particular BSOD is a DPC_WATCHDOG_VIOLATION, but there are two types of DPC watchdog violation. One has an argument 1 value of 0, indicating that a single DPC ran for too long. These are quite easy to analyse because the driver is on the call stack. The other type, which has an argument 1 value of 1, is where a collection of DPCs ran too long as a group, and you can't debug these from a minidump. Your BSOD is the second type with an argument 1 value of 1 - that's why I asked for the full kernel dump.
A kernel dump contains all the WMI trace structures, so I dumped all the DPC trace records to a file that the Windows Performance Analyzer (WPA) can read, and then used WPA to look at the duration of each of the DPCs that were running when the watchdog timer popped. Here is the relevant WPA display...
By sorting the list of DPCs on the maximum run time column the longest running DPCs appear at the top (and I've done that in the above display). The longest running DPC is ntoskrnl.exe, this is the Windows kernel of course and that's not causing our problem. The next longest running is tcpip.sys, and it runs for over 3 times longer than the next longest running DPC.
You can see in the graphs at the top that tcpip.sys (the second graph down) contains several periods of long running, much longer than any other DPC. This very long running tcpip.sys driver is what's causing the cumulative time for all DPCs to be exceeded.
The tcpip.sys driver is a Microsoft driver and so is not the root cause, we need to look lower down in the networking driver stack at the third-party network adapter driver - and that's what I've suggested you do.