What Are Deferred Procedure Calls?
By Julie Davoren
Updated September 26, 2017
A deferred procedure call (DPC) is an interrupt-handling mechanism in the Microsoft Windows operating system to which drivers can reference when running certain processes. DPC allows a task to be activated, but not executed, from a highly prioritized interrupt request level (IRQL). This permits a driver to process a high-level interrupt service routine (ISR) quickly while deferring the execution of lower-level IRQL codes. Drivers use DPCs to schedule input/output (I/O) operations. Drivers are software used by Windows to communicate with hardware devices.
A kernel mode device driver conventionally handles the transfer of an audio or video data stream from or to an external device. The data processing of the device drivers is interrupt-driven. The external hardware routinely generates interrupts to request the device driver to transfer the next batch of data. A device driver cannot process data instantly in its interrupt routine; thus, the operating system needs to trigger a callback routine, which is the DPC. The kernel mode, or system mode, and the user mode are the modes of operation of your central processing unit. The kernel controls all system processing activities.
The concept of a deferred procedure call exists in kernel mode only. The operating system keeps the DPCs scheduled by the device drivers in a queue. If your system needs to process interrupts, the kernel checks the DPC queue and executes the first DPC if there are no interrupts and no DPC processes running. The DPC is the highest prioritized thread in the system, as the DPC queue processing occurs before the dispatcher chooses a thread and assigns this to the CPU. DPCs have three priority levels: low, medium and high.
Each DPC is linked with one system-defined DPC object. When a driver registers a DPCForslr routine, the system initializes the previously defined DPC object. If more than one DPC is required, a driver creates additional DPC objects known as CustomDPC routines. The DPCForlsr routine handles several processes; it completes the I/O operation described by the input/output request packets (IRP), deques the next IRP, sets the input/output status in the received IRP and the process to complete the request.
Normally, a device driver that has an interrupt service routine has at least one DPCForIsr or CustomDPC routine to complete the processing of interrupt-driven I/O operations. According to Open Systems Resources, Inc., the fundamental reason a driver has a single DPCForlsr routine, a set of CustomDPC routines or both depends on the nature of its underlying device and the set of I/O requests it must support. A driver’s ISR needs to call IoRequestDPC for interrupt-driven I/O operations using DPCForlsr routines. Conversely, for overlapped operations, interrupt-driven I/O operations using CustomDPC routines, ISR needs to call KeInsertQueueDPC.