Conception de minuteries haute résolution avec affinité processeur et gestion sécurisée du retrait matériel dans les pilotes noyau Windows

Question

Nous souhaitons implémenter un mécanisme de temporisation ultra-précis lié à un cœur CPU spécifique via un CustomTimerDPC. Cependant, les frameworks modernes WdfTimerxxx et ExxxxTimer n’exposent pas de paramètres permettant d’injecter des appels de procédure différée (Deferred Procedure Calls) personnalisés définis par l’utilisateur, tandis que l’architecture héritée KeTimer ne fournit pas intrinsèquement la précision haute fidélité requise.

Nous avons exploré une solution alternative reposant sur un thread de travail dédié ancré via KeDelayExecutionThread(); toutefois, cette approche introduit un défaut critique lors du cycle de destruction du composant. Plus précisément, nous ne parvenons pas à identifier de méthode programmatique permettant d’interrompre instantanément l’état d’attente du thread si le périphérique physique associé est brutalement débranché du châssis.

Quelle serait la stratégie architecturale optimale pour obtenir une planification haute résolution verrouillée sur un cœur processeur spécifique tout en gérant proprement les éjections matérielles soudaines ? Merci d’avance pour votre aide !

Answer 1

Héllo Jaxon Bailey,

Comment se passe ton problème ? Est-ce que cela a été résolu ? Si c'est le cas, merci d 'accepter la réponse car cela aide aussi d'autres personnes partageant le même problème. Merci :)

VPHAN

Answer 2

Hi!

To achieve sub-millisecond precision pinned to a specific core, you should transition from a worker thread to a high-resolution KTIMER and KDPC architecture. By initializing your timer via KeInitializeTimerEx with the TimerHighResolution flag, you utilize the high-frequency hardware clock to bypass the standard 15.6ms clock tick. To solve the affinity requirement, you must manually associate a KDPC with this timer and call KeSetTargetProcessorDpc to bind its execution to your target processor's interrupt queue.

For handling sudden hardware ejections, the asynchronous nature of a DPC-based timer is inherently safer than a blocked worker thread. In your PnP cleanup callbacks, specifically EvtDeviceSurpriseRemoval, calling KeCancelTimer will instantly dequeue the timer and prevent any subsequent DPC execution, ensuring the driver does not attempt to access unmapped hardware registers. If your design necessitates a persistent thread, replace KeDelayExecutionThread with KeWaitForMultipleObjects. This allows the thread to wait simultaneously on a kernel timer and a "Stop Event" signaled by your PnP removal routine, providing a programmatic mechanism to break the wait state and terminate the thread gracefully before the device object is destroyed.

Hope this answer brought you some useful info. If it does, please consider "accepting the answer". Thank you :)

VPHAN