Bereitstellen von CustomTimerDpc-Kontextinformationen

Der an KeInitializeDpc übergebene DeferredContext-Zeiger verweist auf einen Kontextbereich, in dem andere Treiberroutinen und die CustomTimerDpc-Routine selbst den Zustand beibehalten können. Der Kernel übergibt den DeferredContext-Zeiger bei jedem Aufruf der DPC-Routine.

Im Gegensatz zu einer IoTimer-Routine weist ein CustomTimerDpc keine besonderen Zuordnungen zu einem vom Treiber erstellten Geräteobjekt auf. Ein Treiber kann jedoch eine CustomTimerDpc-Routine einem vom Treiber erstellten Geräteobjekt zuordnen, indem er einen Zeiger auf das Geräteobjekt in seinen Kontextbereich einschließt.

Der Kontextbereich muss sich in einem vom Treiber zugewiesenen Speicher befinden. In der Regel befindet sich dieser Kontextbereich in einer Geräteerweiterung, kann sich aber auch in einem nicht auslagerten Pool befinden. Wenn der Treiber ein Controllerobjekt verwendet, kann es sich in einer Controllererweiterung befinden. Der Inhalt des Kontextbereichs wird vom Treiber bestimmt.

Wenn eine CustomTimerDpc-Routine Kontextinformationen mit der ISR des Treibers teilt, muss die CustomTimerDpc-RoutineKeSynchronizeExecution verwenden, um eine SynchCritSection-Routine aufzurufen, die auf den freigegebenen Kontext zugreift. Weitere Informationen finden Sie unter Verwenden kritischer Abschnitte.

Wenn customTimerDpc die Kontextinformationen für andere Nicht-ISR-Treiberroutinen freigibt, muss der Bereich unter DeferredContext durch eine Spin-Sperre der Führungskraft geschützt werden. Weitere Informationen finden Sie unter Spin-Sperren.