Verifier breaks in WinDbg on WdfTimerStart

NTDEV
1

Hi All,
I have a one shot timer running in my driver. This timer starts when the driver (D0PostIntrEnable) loads and then stops On (D0PreInterruptDisable). When I do the load unload test on the driver with driver verifier enabled, the driver verifier breaks in to debugger (only sometimes) with the following stack

Blockquote
00 ffffaa03eccc7028 fffff80073fea5fb nt!DbgBreakPoint [minkernel\ntos\rtl\amd64\debugstb.asm @ 61]
01 (Inline Function) ---------------- Wdf01000!Mx::MxDbgBreakPoint+0x7 [minkernel\wdf\framework\shared\inc\primitives\km\MxGeneralKm.h @ 156] 02 ffffaa03eccc7030 fffff80073fd9717 Wdf01000!FxVerifierDbgBreakPoint+0x4b [minkernel\wdf\framework\shared\inc\private\common\fxverifier.h @ 93] 03 ffffaa03eccc7070 fffff80073f8d895 Wdf01000!FxTimer::Start+0x4be67 [minkernel\wdf\framework\shared\core\fxtimer.cpp @ 596] 04 ffffaa03eccc7100 fffff806e5c08b2b Wdf01000!imp_WdfTimerStart+0x45 [minkernel\wdf\framework\shared\core\fxtimerapi.cpp @ 243] 05 ffffaa03eccc7140 fffff800`73f8218c MyDriverCmdTimer+0x33b

MyDriverCmdTimer function is the function which is the timer callback and it restarts the timer. When I look at driver verifier code, I can see that it has "driver rundown checks" which basically says that "Why is driver calling StartTimer when the driver is being run down" . If I ignore the assertion and let the debugger continue, there is not problem and the test continues.

I do not think that I am doing anything illegal here.
Would appreciate any thoughts on this.
Thanks,
Aj

2

This isn't really a one shot timer if you are starting it again each time it fires. Is there a reason that you have coded it that way?

3

Honestly there is no specific reason just that I want to have control. Its a timer which monitors the IO queues. Needs to be running for the life time of the driver. I can make it a auto fire timer, if that what you mean.

But why is the verifier complaining ?

4

I suggest that you try that

5

I tried this. The problem is that when the TimerCallback is scheduled for a PassiveLevel Callback, we cannot specify a specific period. The Period for the periodic timer has to be 0.

_WDF_TIMER_CONFIG (wdftimer.h) - Windows drivers | Microsoft Learn

Effectively it means that you cannot have period timer called at Passive level. Probably that is the reason why I coded it this way.

Any thoughts appreciated!!
Thanks
Aj

6

Did you bother to dump the log with !wdflogdump?

If not, set logging to verbose, repro the problem, and dump the log. That usually will tell you the reason. Usually. Sometimes. If you're fortunate :slight_smile:

7

Debugged this a little more. The Driver is asserting here because it thinks that there is a code in driver which is starting the timer while the driver is running down. I also cannot move the timer from one shot to Periodic because the periodic timers are not supported at passive level.

I modified the code to start the timer only when there is command to time. If not, I do not start the timer. This works.
Thanks
Aj

8

The Verifier breaks in WinDbg on WdfTimerStart issue typically indicates that the Windows Driver Framework (WDF) Timer is encountering problems related to system verification. This break could be due to mismanagement of the timer object, issues with the driver code, or conflicts with other system components. Debugging involves analyzing the call stack and verifying that the timer is correctly configured and managed according to WDF guidelines.

9

Copilot, is that you?

2 Likes
10

Yes. Please don't submit useless AI-generated answers.