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
- 1 2