I’m pretty sure the DPC watchdog limit is a lot longer than 128 uSec, although 20 seconds does seem like an extremely long time. As I remember it get’s checked in the timer ISR/IPI, so a single 16msec timer tick would be way longer than 128 uSec. Perhaps it’s in opaque DPC_WATCHDOG units. The APIs to retrieve it just will tell you what fraction of the way you are to a timeout. I usually pick a number like 25% as a threshold of when to handoff work to a passive level thread.
Perhaps a request for a documentation update is in order, to clarify what unit the watchdog “ticks” are in.
It would be pretty easy for the OP to write a few lines of code to measure what the limit actually is. Raise IRQL to DISPATCH_LEVEL, loop around incrementing a counter with a 10 uSec stall in each loop, see how many times you loop before getting a DPC_WATCHDOG crash.
There also is another watchdog timer which basically detected when a core is no longer responding to timer ticks. All the cores get timer ticks, and there is code that makes sure all cores are responding to those ticks. A core can sometimes be stuck “outside” OS execution, like trapped back to a hypervisor. I believe the number I’ve recently seen is if 4 timer ticks happen, and a core doesn’t react, a timer watchdog timeout bugcheck happens. If for example you have two processor sockets, and one socket get’s into a fatal error state, half the cores will stop responding to timer ticks. Another case happens if for example you go do a PCI config read, and the device keeps responding with a retry status, that core is basically locked on that read and not responding to interrupts. A lot of complex I/O devices process PCI config requests in firmware, so what you see if that firmware locks up while the OS is doing a config cycle is an OS timer watchdog bugcheck.
Even though the watchdog timers can be annoying to developers, I do believe they are a really important feature for detecting hardware and software errors.
Jan