On Tue Nov 29 17:01:12 2022 +0000, Zebediah Figura wrote:
That sounds believable, although it'd be nice to be sure. More concerning to me, though, is that currently we can execute the "wrong" DPC if the callback was triggered during/after a concurrent KeSetTimer().
Here is a quote from the MS documentation: _"However, if the timer is about to expire when KeCancelTimer is called, expiration might occur before KeCancelTimer has a chance to access the time queue, in which case signaling and DPC queuing will occur."_ https://learn.microsoft.com/en-us/windows-hardware/drivers/kernel/using-a-cu...
And also: _"If a second driver routine calls KeSetTimer or KeSetTimerEx to run the same CustomTimerDpc routine before the interval specified by the first caller expires, the CustomTimerDpc routine is run only after the interval specified by the second caller expires. In these circumstances, the CustomTimerDpc does none of the work for which the first routine called KeSetTimer or KeSetTimerEx."_
In general they warn of many race conditions that can occur when using DPCs with kernel timers, and that it is responsibility of the developer to avoid them.