On Wed Nov 30 16:12:36 2022 +0000, Ivo Ivanov wrote:
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.
Sure, but those are specific races, and driver developers might expect and be able to handle them. On the other hand, I could easily see a driver crashing if a DPC that it thought was only going to execute at most once ends up executing twice. Unless Windows actually does that, we should probably try to avoid it. Which shouldn't be too difficult, I think.
(Note also that the Microsoft documentation can often be inaccurate, or incomplete. Programs may also depend on guarantees weaker or stronger than the documentation gives.)