WdfTimerStart returns false

I have a lower filter HID class driver where in Device Add, I create a WdfTimer via WdfTimerCreate. The timer is created successfully. Later on, I call on WdfTimerStart and pass in this timer. This function returns false and I’m not sure why. The timer is valid before I call on WdfTimerStart.

From the docs: WdfTimerStart returns TRUE if the timer object was in the system’s timer queue. Otherwise, this method returns FALSE

What exactly is the system’s timer queue and how can I see if my timer was added to it? Under what circumstances would a timer not be added?

What does !wdfkd.wdflogdump (your driver name) say about the function call?

Bent from my phone


From: 30571420200n behalf of
Sent: Friday, September 7, 2018 10:48 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] WdfTimerStart returns false

I have a lower filter HID class driver where in Device Add, I create a WdfTimer via WdfTimerCreate. The timer is created successfully. Later on, I call on WdfTimerStart and pass in this timer. This function returns false and I’m not sure why. The timer is valid before I call on WdfTimerStart.

From the docs: WdfTimerStart returns TRUE if the timer object was in the system’s timer queue. Otherwise, this method returns FALSE

What exactly is the system’s timer queue and how can I see if my timer was added to it? Under what circumstances would a timer not be added?


NTDEV is sponsored by OSR

Visit the list online at: https:

MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at https:

To unsubscribe, visit the List Server section of OSR Online at https:</https:></https:></https:>

It doesn’t really say much of anything related to the timer

1: FxIFRStart - FxIFR logging started
2: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x0000767848097FD8 !devobj
0xFFFF8987B4AB17D0 entering PnP State WdfDevStatePnpInit from
WdfDevStatePnpObjectCreated
3: FxPkgPnp::Dispatch - WDFDEVICE 0x0000767848097FD8 !devobj
0xFFFF8987B4AB17D0, IRP_MJ_PNP, 0x00000000(IRP_MN_START_DEVICE) IRP
0xFFFF8987B55D7010
4: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x0000767848097FD8 !devobj
0xFFFF8987B4AB17D0 entering PnP State WdfDevStatePnpInitStarting from
WdfDevStatePnpInit
5: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x0000767848097FD8 !devobj
0xFFFF8987B4AB17D0 entering PnP State WdfDevStatePnpHardwareAvailable from
WdfDevStatePnpInitStarting
6: FxPkgPnp::NotPowerPolicyOwnerEnterNewState - WDFDEVICE
0x0000767848097FD8 !devobj 0xFFFF8987B4AB17D0 entering not power policy
owner state WdfDevStatePwrPolStarting from WdfDevStatePwrPolObjectCreated
7: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x0000767848097FD8 !devobj
0xFFFF8987B4AB17D0 entering Power State
WdfDevStatePowerStartingCheckDeviceType from WdfDevStatePowerObjectCreated
8: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x0000767848097FD8 !devobj
0xFFFF8987B4AB17D0 entering Power State WdfDevStatePowerD0Starting from
WdfDevStatePowerStartingCheckDeviceType
9: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x0000767848097FD8 !devobj
0xFFFF8987B4AB17D0 entering Power State
WdfDevStatePowerD0StartingConnectInterrupt from WdfDevStatePowerD0Starting
10: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x0000767848097FD8 !devobj
0xFFFF8987B4AB17D0 entering Power State WdfDevStatePowerD0StartingDmaEnable
from WdfDevStatePowerD0StartingConnectInterrupt
11: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x0000767848097FD8 !devobj
0xFFFF8987B4AB17D0 entering Power State
WdfDevStatePowerD0StartingStartSelfManagedIo from
WdfDevStatePowerD0StartingDmaEnable
12: FxPkgIo::ResumeProcessingForPower - Power resume all queues of
WDFDEVICE 0x0000767848097FD8
13: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x0000767848097FD8 !devobj
0xFFFF8987B4AB17D0 entering Power State WdfDevStatePowerDecideD0State from
WdfDevStatePowerD0StartingStartSelfManagedIo
14: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x0000767848097FD8 !devobj
0xFFFF8987B4AB17D0 entering Power State WdfDevStatePowerD0 from
WdfDevStatePowerDecideD0State
15: FxPkgPnp::NotPowerPolicyOwnerEnterNewState - WDFDEVICE
0x0000767848097FD8 !devobj 0xFFFF8987B4AB17D0 entering not power policy
owner state WdfDevStatePwrPolStarted from WdfDevStatePwrPolStarting
16: FxPkgPnp::NotPowerPolicyOwnerEnterNewState - WDFDEVICE
0x0000767848097FD8 !devobj 0xFFFF8987B4AB17D0 entering not power policy
owner state WdfDevStatePwrPolStartingSucceeded from WdfDevStatePwrPolStarted
17: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x0000767848097FD8 !devobj
0xFFFF8987B4AB17D0 entering PnP State WdfDevStatePnpEnableInterfaces from
WdfDevStatePnpHardwareAvailable
18: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x0000767848097FD8 !devobj
0xFFFF8987B4AB17D0 entering PnP State WdfDevStatePnpStarted from
WdfDevStatePnpEnableInterfaces
19: FxPkgPnp::Dispatch - WDFDEVICE 0x0000767848097FD8 !devobj
0xFFFF8987B4AB17D0, IRP_MJ_PNP, 0x00000014(IRP_MN_QUERY_PNP_DEVICE_STATE)
IRP 0xFFFF8987B5527010
20: FxPkgFdo::HandleQueryPnpDeviceStateCompletion - WDFDEVICE
0x0000767848097FD8 !devobj 0xFFFF8987B4AB17D0 returning PNP_DEVICE_STATE
0x0 IRP 0xFFFF8987B5527010
21: FxPkgPnp::Dispatch - WDFDEVICE 0x0000767848097FD8 !devobj
0xFFFF8987B4AB17D0, IRP_MJ_PNP, 0x00000007(IRP_MN_QUERY_DEVICE_RELATIONS)
type BusRelations IRP 0xFFFF8987BC6C8B40
22: FxPkgPnp::HandleQueryBusRelations - WDFDEVICE 0000767848097FD8
returning 2 devices in relations FFFFA08719E7A1B0
23: FxPkgPnp::Dispatch - WDFDEVICE 0x0000767848097FD8 !devobj
0xFFFF8987B4AB17D0, IRP_MJ_PNP, 0x00000007(IRP_MN_QUERY_DEVICE_RELATIONS)
type BusRelations IRP 0xFFFF8987BC6C8B40
24: FxPkgPnp::HandleQueryBusRelations - WDFDEVICE 0000767848097FD8
returning 2 devices in relations FFFFA0871D1DCF50

On Fri, Sep 7, 2018 at 10:57 AM xxxxx@microsoft.com <
xxxxx@lists.osr.com> wrote:

What does !wdfkd.wdflogdump (your driver name) say about the function call?

Bent from my phone


*From:* 30571420200n behalf of
*Sent:* Friday, September 7, 2018 10:48 AM
*To:* Windows System Software Devs Interest List
*Subject:* [ntdev] WdfTimerStart returns false

I have a lower filter HID class driver where in Device Add, I create a
WdfTimer via WdfTimerCreate. The timer is created successfully. Later on, I
call on WdfTimerStart and pass in this timer. This function returns false
and I’m not sure why. The timer is valid before I call on WdfTimerStart.

From the docs: WdfTimerStart returns TRUE if the timer object was in the
system’s timer queue. Otherwise, this method returns FALSE

What exactly is the system’s timer queue and how can I see if my timer was
added to it? Under what circumstances would a timer not be added?


NTDEV is sponsored by OSR

Visit the list online at: <
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.osronline.com%2Fshowlists.cfm%3Flist%3Dntdev&data=02|01|Doron.Holan%40microsoft.com|acc7fea790de435ac31f08d614ea122c|72f988bf86f141af91ab2d7cd011db47|1|0|636719392901285561&sdata=N8gl7NCDes74opvgmUThqyc7GUvNu8nHsOkGRx1Pi9c%3D&reserved=0\>

MONTHLY seminars on crash dump analysis, WDF, Windows internals and
software drivers!
Details at <
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.osr.com%2Fseminars&data=02|01|Doron.Holan%40microsoft.com|acc7fea790de435ac31f08d614ea122c|72f988bf86f141af91ab2d7cd011db47|1|0|636719392901285561&sdata=0LXmaJ4yuxauWfWdMgycdgpAes%2FnrcKduXE8m256e44%3D&reserved=0\>

To unsubscribe, visit the List Server section of OSR Online at <
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.osronline.com%2Fpage.cfm%3Fname%3DListServer&data=02|01|Doron.Holan%40microsoft.com|acc7fea790de435ac31f08d614ea122c|72f988bf86f141af91ab2d7cd011db47|1|0|636719392901285561&sdata=iuvNoGMknHDFUPYdd2CiSYXqQD2zRPU6O5oqfa7Ys%2Fo%3D&reserved=0\>


NTDEV is sponsored by OSR

Visit the list online at: <
http://www.osronline.com/showlists.cfm?list=ntdev\>

MONTHLY seminars on crash dump analysis, WDF, Windows internals and
software drivers!
Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer&gt;
></http:>

Turn on verbose logging with wdfverifier.exe and then see if there is more information. You can also look at the kmdf source to see if there are reasons it retuns FALSE outside of the KeSetTimer call

d

From: xxxxx@lists.osr.com On Behalf Of xxxxx@gmail.com
Sent: Friday, September 7, 2018 11:03 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] WdfTimerStart returns false

It doesn’t really say much of anything related to the timer

1: FxIFRStart - FxIFR logging started
2: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x0000767848097FD8 !devobj 0xFFFF8987B4AB17D0 entering PnP State WdfDevStatePnpInit from WdfDevStatePnpObjectCreated
3: FxPkgPnp::Dispatch - WDFDEVICE 0x0000767848097FD8 !devobj 0xFFFF8987B4AB17D0, IRP_MJ_PNP, 0x00000000(IRP_MN_START_DEVICE) IRP 0xFFFF8987B55D7010
4: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x0000767848097FD8 !devobj 0xFFFF8987B4AB17D0 entering PnP State WdfDevStatePnpInitStarting from WdfDevStatePnpInit
5: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x0000767848097FD8 !devobj 0xFFFF8987B4AB17D0 entering PnP State WdfDevStatePnpHardwareAvailable from WdfDevStatePnpInitStarting
6: FxPkgPnp::NotPowerPolicyOwnerEnterNewState - WDFDEVICE 0x0000767848097FD8 !devobj 0xFFFF8987B4AB17D0 entering not power policy owner state WdfDevStatePwrPolStarting from WdfDevStatePwrPolObjectCreated
7: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x0000767848097FD8 !devobj 0xFFFF8987B4AB17D0 entering Power State WdfDevStatePowerStartingCheckDeviceType from WdfDevStatePowerObjectCreated
8: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x0000767848097FD8 !devobj 0xFFFF8987B4AB17D0 entering Power State WdfDevStatePowerD0Starting from WdfDevStatePowerStartingCheckDeviceType
9: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x0000767848097FD8 !devobj 0xFFFF8987B4AB17D0 entering Power State WdfDevStatePowerD0StartingConnectInterrupt from WdfDevStatePowerD0Starting
10: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x0000767848097FD8 !devobj 0xFFFF8987B4AB17D0 entering Power State WdfDevStatePowerD0StartingDmaEnable from WdfDevStatePowerD0StartingConnectInterrupt
11: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x0000767848097FD8 !devobj 0xFFFF8987B4AB17D0 entering Power State WdfDevStatePowerD0StartingStartSelfManagedIo from WdfDevStatePowerD0StartingDmaEnable
12: FxPkgIo::ResumeProcessingForPower - Power resume all queues of WDFDEVICE 0x0000767848097FD8
13: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x0000767848097FD8 !devobj 0xFFFF8987B4AB17D0 entering Power State WdfDevStatePowerDecideD0State from WdfDevStatePowerD0StartingStartSelfManagedIo
14: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x0000767848097FD8 !devobj 0xFFFF8987B4AB17D0 entering Power State WdfDevStatePowerD0 from WdfDevStatePowerDecideD0State
15: FxPkgPnp::NotPowerPolicyOwnerEnterNewState - WDFDEVICE 0x0000767848097FD8 !devobj 0xFFFF8987B4AB17D0 entering not power policy owner state WdfDevStatePwrPolStarted from WdfDevStatePwrPolStarting
16: FxPkgPnp::NotPowerPolicyOwnerEnterNewState - WDFDEVICE 0x0000767848097FD8 !devobj 0xFFFF8987B4AB17D0 entering not power policy owner state WdfDevStatePwrPolStartingSucceeded from WdfDevStatePwrPolStarted
17: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x0000767848097FD8 !devobj 0xFFFF8987B4AB17D0 entering PnP State WdfDevStatePnpEnableInterfaces from WdfDevStatePnpHardwareAvailable
18: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x0000767848097FD8 !devobj 0xFFFF8987B4AB17D0 entering PnP State WdfDevStatePnpStarted from WdfDevStatePnpEnableInterfaces
19: FxPkgPnp::Dispatch - WDFDEVICE 0x0000767848097FD8 !devobj 0xFFFF8987B4AB17D0, IRP_MJ_PNP, 0x00000014(IRP_MN_QUERY_PNP_DEVICE_STATE) IRP 0xFFFF8987B5527010
20: FxPkgFdo::HandleQueryPnpDeviceStateCompletion - WDFDEVICE 0x0000767848097FD8 !devobj 0xFFFF8987B4AB17D0 returning PNP_DEVICE_STATE 0x0 IRP 0xFFFF8987B5527010
21: FxPkgPnp::Dispatch - WDFDEVICE 0x0000767848097FD8 !devobj 0xFFFF8987B4AB17D0, IRP_MJ_PNP, 0x00000007(IRP_MN_QUERY_DEVICE_RELATIONS) type BusRelations IRP 0xFFFF8987BC6C8B40
22: FxPkgPnp::HandleQueryBusRelations - WDFDEVICE 0000767848097FD8 returning 2 devices in relations FFFFA08719E7A1B0
23: FxPkgPnp::Dispatch - WDFDEVICE 0x0000767848097FD8 !devobj 0xFFFF8987B4AB17D0, IRP_MJ_PNP, 0x00000007(IRP_MN_QUERY_DEVICE_RELATIONS) type BusRelations IRP 0xFFFF8987BC6C8B40
24: FxPkgPnp::HandleQueryBusRelations - WDFDEVICE 0000767848097FD8 returning 2 devices in relations FFFFA0871D1DCF50

On Fri, Sep 7, 2018 at 10:57 AM xxxxx@microsoft.commailto:xxxxx > wrote:
What does !wdfkd.wdflogdump (your driver name) say about the function call?

Bent from my phone

________________________________
From: 30571420200n behalf of
Sent: Friday, September 7, 2018 10:48 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] WdfTimerStart returns false

I have a lower filter HID class driver where in Device Add, I create a WdfTimer via WdfTimerCreate. The timer is created successfully. Later on, I call on WdfTimerStart and pass in this timer. This function returns false and I’m not sure why. The timer is valid before I call on WdfTimerStart.

From the docs: WdfTimerStart returns TRUE if the timer object was in the system’s timer queue. Otherwise, this method returns FALSE

What exactly is the system’s timer queue and how can I see if my timer was added to it? Under what circumstances would a timer not be added?


NTDEV is sponsored by OSR

Visit the list online at: https:>

MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at https:>

To unsubscribe, visit the List Server section of OSR Online at https:>


NTDEV is sponsored by OSR

Visit the list online at: http:>

MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at http:>

To unsubscribe, visit the List Server section of OSR Online at http:>
— NTDEV is sponsored by OSR Visit the list online at: MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers! Details at To unsubscribe, visit the List Server section of OSR Online at</http:></http:></http:></https:></https:></https:></mailto:xxxxx>

On Sep 7, 2018, at 10:48 AM, xxxxx@gmail.com wrote:
>
> I have a lower filter HID class driver where in Device Add, I create a WdfTimer via WdfTimerCreate. The timer is created successfully. Later on, I call on WdfTimerStart and pass in this timer. This function returns false and I’m not sure why. The timer is valid before I call on WdfTimerStart.
>
> From the docs: WdfTimerStart returns TRUE if the timer object was in the system’s timer queue. Otherwise, this method returns FALSE
>
> What exactly is the system’s timer queue and how can I see if my timer was added to it? Under what circumstances would a timer not be added?

You are misreading the documentation. If WdfTimerStart returns true, it simply means that you has already called WdfTimerStart and that timer has not yet fired. That is, it returns TRUE if the timer object was ALREADY in the system’s timer queue because of a previous call to WdfTimerStart.

Returning FALSE is not an error condition. WdfTimerStart cannot fail.

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

" You are misreading the documentation. If WdfTimerStart returns true, it
simply means that you has already called WdfTimerStart and that timer has
not yet fired. That is, it returns TRUE if the timer object was ALREADY in
the system’s timer queue because of a previous call to WdfTimerStart."

This doesn’t appear to be the case from what I’m seeing when looking at my
kdprintf output. I trigger the routine that eventually calls on
WdfTimerStart with a 500ms period, where it was never called once before,
and it just returns false. My callback that I setup in Device Add with my
timer is never called upon.

On Fri, Sep 7, 2018 at 5:50 PM xxxxx@probo.com wrote:

> On Sep 7, 2018, at 10:48 AM, xxxxx@gmail.com
> wrote:
> >
> > I have a lower filter HID class driver where in Device Add, I create a
> WdfTimer via WdfTimerCreate. The timer is created successfully. Later on, I
> call on WdfTimerStart and pass in this timer. This function returns false
> and I’m not sure why. The timer is valid before I call on WdfTimerStart.
> >
> > From the docs: WdfTimerStart returns TRUE if the timer object was in the
> system’s timer queue. Otherwise, this method returns FALSE
> >
> > What exactly is the system’s timer queue and how can I see if my timer
> was added to it? Under what circumstances would a timer not be added?
>
> You are misreading the documentation. If WdfTimerStart returns true, it
> simply means that you has already called WdfTimerStart and that timer has
> not yet fired. That is, it returns TRUE if the timer object was ALREADY in
> the system’s timer queue because of a previous call to WdfTimerStart.
>
> Returning FALSE is not an error condition. WdfTimerStart cannot fail.
> —
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list online at: <
> http://www.osronline.com/showlists.cfm?list=ntdev&gt;
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer&gt;
></http:>

xxxxx@gmail.com wrote:

This doesn’t appear to be the case from what I’m seeing when looking
at my kdprintf output. I trigger the routine that eventually calls on
WdfTimerStart with a 500ms period, where it was never called once
before, and it just returns false.

That’s exactly what it’s supposed to do.  “False” means “your routine is
not already pending.”

My callback that I setup in Device Add with my timer is never called
upon.

Perhaps you should post the code.


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

Essentially, if a user holds down the next track key on our keyboard by the
time the timer callback is trigger, the driver will interpret it as a
fast-forward event. This same chunk of code is used in a different driver,
as in, the timer creation and starting sequence, and works as expected for
what that’s worth.

EVT_WDF_TIMER EvtMultimediaKeyTimerFunc;

WDF_TIMER_CONFIG_INIT(&timerConfig,EvtMultimediaKeyTimerFunc);

WDF_OBJECT_ATTRIBUTES_INIT(&timerAttributes);
timerAttributes.ParentObject = device;

status = WdfTimerCreate(&timerConfig,
&timerAttributes,
&pFilterExt->KeyMultimediaHoldTimer
);

if (!NT_SUCCESS(status))
{
KdPrintEx((DPFLTR_IHVDRIVER_ID, DPFLTR_ERROR_LEVEL, “*** [%s:%d]
WdfTimerCreate failed 0x%x\n”, FILE, LINE, status));
goto Cleanup;
}

case HID_USAGE_KEYBOARD_F9:
KdPrintEx((DPFLTR_IHVDRIVER_ID, DPFLTR_TRACE_LEVEL, “Next Track key
pressed\n”));
pFilterExt->MultimediaKey = CONSUMER_USAGE_NEXT_TRACK;
BOOLEAN ret = WdfTimerStart(pFilterExt->KeyMultimediaHoldTimer,
WDF_REL_TIMEOUT_IN_MS(KEY_REPEAT_START));
if (!ret)
{
KdPrintEx((DPFLTR_IHVDRIVER_ID, DPFLTR_TRACE_LEVEL, “TIMER DIDNT
START!!!\n”));
}
pHIDReport[KeyIndex] = 0;
bReturn = TRUE;
break;

On Mon, Sep 10, 2018 at 11:57 AM xxxxx@probo.com wrote:

> xxxxx@gmail.com wrote:
> >
> > This doesn’t appear to be the case from what I’m seeing when looking
> > at my kdprintf output. I trigger the routine that eventually calls on
> > WdfTimerStart with a 500ms period, where it was never called once
> > before, and it just returns false.
>
> That’s exactly what it’s supposed to do. “False” means “your routine is
> not already pending.”
>
>
> > My callback that I setup in Device Add with my timer is never called
> > upon.
>
> Perhaps you should post the code.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list online at: <
> http://www.osronline.com/showlists.cfm?list=ntdev&gt;
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer&gt;
></http:>

xxxxx@gmail.com wrote:

Essentially, if a user holds down the next track key on our keyboard
by the time the timer callback is trigger, the driver will interpret
it as a fast-forward event. This same chunk of code is used in a
different driver, as in, the timer creation and starting sequence, and
works as expected for what that’s worth.

Assuming KEY_REPEAT_START is equal to 500, I don’t see any reason why
this wouldn’t work.  WdfTimerStart calls either ExSetTimer or
KeSetCoalescableTimer, neither of which can fail.

KdPrintEx((DPFLTR_IHVDRIVER_ID, DPFLTR_TRACE_LEVEL, “Next Track key
pressed\n”));
    pFilterExt->MultimediaKey = CONSUMER_USAGE_NEXT_TRACK;
    BOOLEAN ret = WdfTimerStart(pFilterExt->KeyMultimediaHoldTimer,
WDF_REL_TIMEOUT_IN_MS(KEY_REPEAT_START));
    if (!ret)
    {
        KdPrintEx((DPFLTR_IHVDRIVER_ID, DPFLTR_TRACE_LEVEL, “TIMER
DIDNT START!!!\n”));
    }

As I said, your debug message is not an accurate description of the
situation.  The timer will always be started.  A TRUE return just means
the timer had been started once before, so all it did was restart the
counter.  Now, you said the user was holding down the key, right?  Does
that mean you’re getting continuous hits?  Or is it one on make, one on
break?

Does EvtMultimediaKeyTimerFunc print a debug message so you know it has
been fired?


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

I have a log statement inside of EvtMultimediaKeyTimerFunc which is never
generated.
And it is not a continuous hit. For the consumer keys, I get one scancode
on a key press or key hold. On releasing the key, the scancode value is 0
which clears out the old scancode.

Just to humor myself, is there any way I can see that the timer did get
started?

On Mon, Sep 10, 2018 at 2:28 PM xxxxx@probo.com wrote:

> xxxxx@gmail.com wrote:
> > Essentially, if a user holds down the next track key on our keyboard
> > by the time the timer callback is trigger, the driver will interpret
> > it as a fast-forward event. This same chunk of code is used in a
> > different driver, as in, the timer creation and starting sequence, and
> > works as expected for what that’s worth.
>
> Assuming KEY_REPEAT_START is equal to 500, I don’t see any reason why
> this wouldn’t work. WdfTimerStart calls either ExSetTimer or
> KeSetCoalescableTimer, neither of which can fail.
>
>
> > KdPrintEx((DPFLTR_IHVDRIVER_ID, DPFLTR_TRACE_LEVEL, “Next Track key
> > pressed\n”));
> > pFilterExt->MultimediaKey = CONSUMER_USAGE_NEXT_TRACK;
> > BOOLEAN ret = WdfTimerStart(pFilterExt->KeyMultimediaHoldTimer,
> > WDF_REL_TIMEOUT_IN_MS(KEY_REPEAT_START));
> > if (!ret)
> > {
> > KdPrintEx((DPFLTR_IHVDRIVER_ID, DPFLTR_TRACE_LEVEL, “TIMER
> > DIDNT START!!!\n”));
> > }
>
> As I said, your debug message is not an accurate description of the
> situation. The timer will always be started. A TRUE return just means
> the timer had been started once before, so all it did was restart the
> counter. Now, you said the user was holding down the key, right? Does
> that mean you’re getting continuous hits? Or is it one on make, one on
> break?
>
> Does EvtMultimediaKeyTimerFunc print a debug message so you know it has
> been fired?
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list online at: <
> http://www.osronline.com/showlists.cfm?list=ntdev&gt;
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer&gt;
></http:>