Can system Timer functions cause re-entrant problem(s) if called with a lock held

NTDEV
1

I experienced a problem where I saw my own function called by system in the context of KeCancelTimer() which is previously called at DispatchLevel and my lock held from my code it self, I am not sure if I could replicate this problem or not.

My general question is that can these system timer function(s) like KeSetTimer, KeQuerySystemTime, or KeCancelTimer can cause re-entrant issue. If the answer is yes, I need to take care of this. I would love to read if there is any reference available regarding this.

Thanks in Advance for your help.

Regards,
Tarun Singh

2

xxxxx@yahoo.com wrote:

I experienced a problem where I saw my own function called by system in the context of KeCancelTimer() which is previously called at DispatchLevel and my lock held from my code it self, I am not sure if I could replicate this problem or not.

KeCancelTimer does not cause any driver functions to be called. I think
you have misunderstood something. Now, sometimes people will free
resources after the KeCancelTimer call, without realizing that the timer
DPC could still be running.

My general question is that can these system timer function(s) like KeSetTimer, KeQuerySystemTime, or KeCancelTimer can cause re-entrant issue. If the answer is yes, I need to take care of this. I would love to read if there is any reference available regarding this.

The timer is an asynchronous resource. The timer routine will start
when its time comes, regardless of whatever else your driver might be doing.

Those three routines will not directly cause any other functions to be
called, but it’s always possible for the scheduler or an interrupt to
cause another thread to be scheduled. That can happen at any time.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

3

>I experienced a problem where I saw my own function called by system in the context of >KeCancelTimer() which is previously called at DispatchLevel and my lock held from my code it self, I >am not sure if I could replicate this problem or not.

Do you check a return value of KeCancelTimer? If the function return FALSE it means that a DPC has begun executing. In this case you could consider that a timer DPC canceled but in fact it executing and could held a SpinLock.
You could also use a Driver Verifier and !lock command in WinDbg to resolve this problem.

Igor Sharovar

4

>I experienced a problem where I saw my own function called by system in the context of >KeCancelTimer() which is previously called at DispatchLevel and my lock held from my code it self, I >am not sure if I could replicate this problem or not.

Do you check a return value of KeCancelTimer? If the function return FALSE it means that a DPC has begun executing. In this case you could consider that a timer DPC canceled but in fact it executing and could held a SpinLock.
You could also use a Driver Verifier and !lock command in WinDbg to resolve this problem.

Igor Sharovar