A Deferred Procedure Call (DPC) is where Interrupt Service Routines (ISRs) get most of their work done in Windows. ISRs are meant to not do a whole lot other than queueing a DPC and call it done. This is because at Device IRQL, not much else can go on while the CPU is interrupted and so it is wise to defer work to a later point of time and most importantly to a lower IRQL.

This approach to interrupt processing is routine across operating systems and is not unique to Windows. In Linux this is referred to as top half and bottom half interrupt handlers. You may hear them as First Level Interrupt Handler(FLIH) /Second Level Interrupt Handler (SLIH) or hard/soft interrupt handlers. These terms are essentially equivalent of each other as far as the concept goes.

Now once in a blue moon, when you are paying attention to something else in your driver, you may encounter the following in the debugger

Note that this is an NT_ASSERT in free build of Windows. 1This is the NT_ASSERT I alluded to in an earlier post about ASSERTs in drivers. The assertion does not happen if debugger was not connected since that would bugcheck the system.

I have seen DPC watchdog timeout ASSERTs being reported from machines with external USB drives attached to them. The stack may look something like this

Tagged with →  
Share →

2 Responses to About DPC Watchdog timer in Windows

  1. Pete Wason says:

    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?

  2. Satya Das says:

    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?

Leave a Reply

Your email address will not be published. Required fields are marked *

Looking for something?

Use the form below to search the site:


Still not finding what you're looking for? Drop us a note so we can take care of it!

Visit our friends!

A few highly recommended friends...

Set your Twitter account name in your settings to use the TwitterBar Section.