As others have said, you need to figure out why your driver spends so much time at dispatch_level. If it were me, I’d add some ETW tracing in the ISR/DPC code and collect data on how much time it spends in different areas. I’d start by sprinkling half a dozen events with some summary data like bytes transferred at interesting places, like at the entry/exit of the DPC. ETW events will be timestamped with a QPC timer, which is often currently processor clock speed / 1024, so around 0.3 uSec resolution. Some of the etw trace decoder tools are silly and only show ms resolution, even though the actual timestamp is much better. I’ve seen etw traces with a million events/sec, but it’s better if you keep the event rate somewhat lower. You CAN still extract ETW trace data if the system crashes, there are windbg commands to write the buffers to a file you can view with your preferred ETW tools. You should also look at non-crashing runs and get a sense of what normal for your driver timing is like.
The DPC watchdog timer is set REALLY long, 0x500 ticks is about 20 seconds (assuming 16ms ticks). Are you really spending 20 seconds in one DPC? Typically, if you spend 20 seconds in a DPC or ISR you’re stuck on a spinlock or something. There also are two forms of DPC_WATCHDOG timeout, one is a per DPC limit, and one is for back-to-back DPCS, which includes DPC’s from different drivers, so your driver might need to be frugal with time if another driver is greedy, which is why your driver should not be greedy.
It’s REALLY easy to add ETW tracing with the TraceLogging API, see my example on this list from 6 months ago, or follow the basic MSFT doc pages. I often use the perfview tool on github to look at trace. Traceview also does the trick, especially if you use the etw name to guid hashing tool (etwguid), then you can just put *MyTraceProvider into traceview instead of the guid. Message analyzer seems to currently be broken (again) for TraceLogging traces.
Some kinds of drivers will absolutely need DPC_WATCHDOG avoidance code, like probably any driver that can received unbounded fast data streams. The classic example is a high speed network card, Ethernet packets just arrive, and you can’t just use more and more DPC time as the received rate goes up.
Jan