The timeout is not specific to USB devices though. You could encounter this with network stack especially when two or more WFP callout filters are trying to keep things secure. Technically this could be any kind of device directly or indirectly related to your driver processing or even unrelated to what you are doing.
Since this is a watchdog, first place to look for it would be system timers. The DPC watchdog timer shows up like below in a listing of all system timers (output has been truncated for brevity).
Note the P in the listing for KiDpcWatchdog, that signifies that it is a periodic timer2. Another interesting bit about the watchdog timer DPC is that it is not a regular DPC but setup as a threaded DPC. Threaded DPCs, available in Vista+, execute at PASSIVE_LEVEL unlike regular DPCs executing at DISPATCH_LEVEL. The reason they are called threaded is that they run in a high priority (priority 31) thread and can be preempted by APCs, non-threaded DPCs and any competing threads at similar priorities.
On Windows 7, the DPC watchdog timer fires the watchdog DPC every 15 seconds3 which resets a countdown tick count4 maintained in the processor control block (PRCB).
In the clock interrupt processing, KeAccumulateTicks (which runs at CLOCK_LEVEL) decrements this tick count and if it sees that the tick count is getting down to zero, fires a timeout NT_ASSERT message that you end up seeing on the debugger output. After the message, the tick count is doubled and system is given another chance to recover from the timeout condition. Since threaded DPCs run at PASSIVE_LEVEL, the timeout means that the processor has been at DISPATCH or higher for too long a time for the overall health of the system.
Hope this helps you track down some of those knarly ISR/DPC problems.
1Please do not use this as an excuse to put NT_ASSERTs in free builds of drivers. In general, it is not a good idea to be using ASSERTs in release builds.
2Timers can be setup to fire once (KeSetTimer) or every so often (KeSetTimerEx with non-zero Period parameter). Most of the system timers are non-periodic.
3The period for this timer is set to half the value of _KeDpcWatchdogPeriod which is set to 30000 milliseconds or 30 seconds
4This tick count is dependent on _KeDpcWatchdogPeriod and _KeMaximumIncrement. Typically 1920 ticks on Windows 7.
- 1 2
Hi, most of this is completely beyond me, but I’m having a problem with several Win 10 machines where I work as an IT guy. They are all crashing once a day with a DPC_WATCHDOG_TIMER code. The weird thing is that they all crash simultaneously. They can be in use, or just sitting there idling, and bang, they all bluescreen at the same time. How can I figure out what is causing this?
Hello Pete,
Thanks for stopping by, and sorry to hear about your troubles.
Are you seeing DPC_WATCHDOG_VIOLATION (0x133) bugchecks? Those are from the DPC watchdog timer described in this post. Essentially, the system spent unusually long time at DISPATCH_LEVEL; usually, this means that something is wrong.
I would start with a list of third-party drivers running on the systems, and see whether there are any updates for those. Some other questions that might help:
a) Are all these machines misbehaving on identical hardware and software? If not, what makes these machines different from the rest of the Windows 10 machines?
b) What information can be gleaned from the memory dumps?