What is that mean ? KeSetTimerEx?

sample source)


KTimer Timer;
LARGE_INTEGER dueTimer = 0xfff0bdc0;
LARGE_INTEGER period = 0xffffffff;

KDPC dpc;

KeInitializeTimerEx(&Timer, SynchronizationTimer);
KeInitializeDpc(&dpc,
(PKDEFERRED_ROUTINE)TimerRoutine,
devicecontext);
KeSetTimerEx(&Timer, dueTimer , period );


I wonder that dueTimer, period argument in tKeSetTImerEx.
It have too much value.

help this, thanks

Don
Wed Dec 28 12:07:39 CST 2005

DueTime is the time at which the timer will go off, period if it is non-zero
is the number of milliseconds the timer will wait after the first callback
before it does it again, for example 1000 says go off every second after the
initial countdown.

Note in your code below, you are saying the timer should have gone off a
long time ago since you are giving a positive number for dueTime which is
100-nanoseconds since January 1, 1601. Your period is incorrect since it
should be a LONG not a large integer, and is further incorrect since it is a
negative value. Finally your call is missing the forth argument, namely the
dpc.

I recommend you take a course in Windows driver writing, or at least get a
good book on the subject such as Walter Oney's "Programming the Windows
Driver Model Second Edition" and take a bunch of time to read it.


--
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply



"Eric Ahn" <byungwook.ahn@gmail.com> wrote in message
news:1135792565.094067.99800@g14g2000cwa.googlegroups.com...
> sample source)
>
>
> KTimer Timer;
> LARGE_INTEGER dueTimer = 0xfff0bdc0;
> LARGE_INTEGER period = 0xffffffff;
>
> KDPC dpc;
>
> KeInitializeTimerEx(&Timer, SynchronizationTimer);
> KeInitializeDpc(&dpc,
> (PKDEFERRED_ROUTINE)TimerRoutine,
> devicecontext);
> KeSetTimerEx(&Timer, dueTimer , period );
>
>
> I wonder that dueTimer, period argument in tKeSetTImerEx.
> It have too much value.
>
> help this, thanks
>

Eric
Wed Dec 28 12:51:43 CST 2005

LARGE_INTEGER DueTime;
ULONG Period = 5000;/* 5sec */

DueTime.QuadPart = -1;//(LONGLONG)IP_TIMEOUT * 10000;
KeSetTimerEx(
&Globals.KeyboardExtension->UserTimer,
DueTime,
Period,
&Globals.KeyboardExtension->InsertDpcObj);

thanks.

If run a dpc routine after 10ms, What is the DueTIme, Period value?

Mark
Wed Dec 28 14:23:15 CST 2005

On 28 Dec 2005 10:51:43 -0800, "Eric Ahn" <byungwook.ahn@gmail.com>
wrote:

>LARGE_INTEGER DueTime;
>ULONG Period = 5000;/* 5sec */
>
>DueTime.QuadPart = -1;//(LONGLONG)IP_TIMEOUT * 10000;
>KeSetTimerEx(
> &Globals.KeyboardExtension->UserTimer,
> DueTime,
> Period,
> &Globals.KeyboardExtension->InsertDpcObj);
>
>thanks.
>
>If run a dpc routine after 10ms, What is the DueTIme, Period value?


DueTime should be set to the appropriate value for 10ms * -1. Period
will determine the frequency in ms after the initial timer expires. So
if your period is 5s then after the initial 10ms your dpc will fire
every 5s.

The DDK docs appear to have no explanation for the Period parameter's
relationship to the DueTime parameter.

In your code segment above you appear to be setting DueTime to -1,
which I think is one 10ns tick. Is that what you intended? Wouldn't
(-1 * 10000 * 5000) or 5s in the future be more appropriate?
=====================
Mark Roddy DDK MVP
Windows Vista/2003/XP/2000 Consulting
Device and Filesystem Drivers
Hollis Technology Solutions 603-321-1032
www.hollistech.com

Doron
Wed Dec 28 16:44:29 CST 2005

IIRC, -1 is a magic value and it means that the timer should fire
immediately

d

--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.


"Mark Roddy" <markr@hollistech.com> wrote in message
news:lds5r15egja2f5m6ia243eskn4gude2mr0@4ax.com...
> On 28 Dec 2005 10:51:43 -0800, "Eric Ahn" <byungwook.ahn@gmail.com>
> wrote:
>
>>LARGE_INTEGER DueTime;
>>ULONG Period = 5000;/* 5sec */
>>
>>DueTime.QuadPart = -1;//(LONGLONG)IP_TIMEOUT * 10000;
>>KeSetTimerEx(
>> &Globals.KeyboardExtension->UserTimer,
>> DueTime,
>> Period,
>> &Globals.KeyboardExtension->InsertDpcObj);
>>
>>thanks.
>>
>>If run a dpc routine after 10ms, What is the DueTIme, Period value?
>
>
> DueTime should be set to the appropriate value for 10ms * -1. Period
> will determine the frequency in ms after the initial timer expires. So
> if your period is 5s then after the initial 10ms your dpc will fire
> every 5s.
>
> The DDK docs appear to have no explanation for the Period parameter's
> relationship to the DueTime parameter.
>
> In your code segment above you appear to be setting DueTime to -1,
> which I think is one 10ns tick. Is that what you intended? Wouldn't
> (-1 * 10000 * 5000) or 5s in the future be more appropriate?
> =====================
> Mark Roddy DDK MVP
> Windows Vista/2003/XP/2000 Consulting
> Device and Filesystem Drivers
> Hollis Technology Solutions 603-321-1032
> www.hollistech.com

Alexander
Wed Dec 28 17:52:51 CST 2005

Note that in some recent Windows versions, the Period math got broken and
its value is limited to MAX_UINT/10000 ms (which is about 430 seconds).
Search for "timeSetEvent() wraps after inteval of 429496" thread in
microsoft.public.win32.programmer.mmedia in June 2005.

"Mark Roddy" <markr@hollistech.com> wrote in message
news:lds5r15egja2f5m6ia243eskn4gude2mr0@4ax.com...
> On 28 Dec 2005 10:51:43 -0800, "Eric Ahn" <byungwook.ahn@gmail.com>
> wrote:
>
>>LARGE_INTEGER DueTime;
>>ULONG Period = 5000;/* 5sec */
>>
>>DueTime.QuadPart = -1;//(LONGLONG)IP_TIMEOUT * 10000;
>>KeSetTimerEx(
>> &Globals.KeyboardExtension->UserTimer,
>> DueTime,
>> Period,
>> &Globals.KeyboardExtension->InsertDpcObj);
>>
>>thanks.
>>
>>If run a dpc routine after 10ms, What is the DueTIme, Period value?
>
>
> DueTime should be set to the appropriate value for 10ms * -1. Period
> will determine the frequency in ms after the initial timer expires. So
> if your period is 5s then after the initial 10ms your dpc will fire
> every 5s.
>
> The DDK docs appear to have no explanation for the Period parameter's
> relationship to the DueTime parameter.
>
> In your code segment above you appear to be setting DueTime to -1,
> which I think is one 10ns tick. Is that what you intended? Wouldn't
> (-1 * 10000 * 5000) or 5s in the future be more appropriate?
> =====================
> Mark Roddy DDK MVP
> Windows Vista/2003/XP/2000 Consulting
> Device and Filesystem Drivers
> Hollis Technology Solutions 603-321-1032
> www.hollistech.com

Doron
Wed Dec 28 19:24:48 CST 2005

you are referring to a UM api. I don't know if it just thunks to the kernel
(i doubt it), but a bug here does not mean there is a bug in KeSetTimerEx

d

--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.


"Alexander Grigoriev" <alegr@earthlink.net> wrote in message
news:OA56TnADGHA.4004@tk2msftngp13.phx.gbl...
> Note that in some recent Windows versions, the Period math got broken and
> its value is limited to MAX_UINT/10000 ms (which is about 430 seconds).
> Search for "timeSetEvent() wraps after inteval of 429496" thread in
> microsoft.public.win32.programmer.mmedia in June 2005.
>
> "Mark Roddy" <markr@hollistech.com> wrote in message
> news:lds5r15egja2f5m6ia243eskn4gude2mr0@4ax.com...
>> On 28 Dec 2005 10:51:43 -0800, "Eric Ahn" <byungwook.ahn@gmail.com>
>> wrote:
>>
>>>LARGE_INTEGER DueTime;
>>>ULONG Period = 5000;/* 5sec */
>>>
>>>DueTime.QuadPart = -1;//(LONGLONG)IP_TIMEOUT * 10000;
>>>KeSetTimerEx(
>>> &Globals.KeyboardExtension->UserTimer,
>>> DueTime,
>>> Period,
>>> &Globals.KeyboardExtension->InsertDpcObj);
>>>
>>>thanks.
>>>
>>>If run a dpc routine after 10ms, What is the DueTIme, Period value?
>>
>>
>> DueTime should be set to the appropriate value for 10ms * -1. Period
>> will determine the frequency in ms after the initial timer expires. So
>> if your period is 5s then after the initial 10ms your dpc will fire
>> every 5s.
>>
>> The DDK docs appear to have no explanation for the Period parameter's
>> relationship to the DueTime parameter.
>>
>> In your code segment above you appear to be setting DueTime to -1,
>> which I think is one 10ns tick. Is that what you intended? Wouldn't
>> (-1 * 10000 * 5000) or 5s in the future be more appropriate?
>> =====================
>> Mark Roddy DDK MVP
>> Windows Vista/2003/XP/2000 Consulting
>> Device and Filesystem Drivers
>> Hollis Technology Solutions 603-321-1032
>> www.hollistech.com
>
>

Alexander
Wed Dec 28 22:21:53 CST 2005

OK, the bug is definitely in the very beginning of WINMM!timeSetTimerEvent
(32-bit multiply by 10000 is used), but I would suggest checking periodic
kernel timer code as well, since the math is similar and such bugs don't go
alone. Could you forward it to the relevant developers, please?

"Doron Holan [MS]" <doronh@nospam.microsoft.com> wrote in message
news:%23CVrTjBDGHA.3992@TK2MSFTNGP12.phx.gbl...
> you are referring to a UM api. I don't know if it just thunks to the
> kernel (i doubt it), but a bug here does not mean there is a bug in
> KeSetTimerEx
>
> d
>
> --
> Please do not send e-mail directly to this alias. this alias is for
> newsgroup purposes only.
> This posting is provided "AS IS" with no warranties, and confers no
> rights.
>
>
> "Alexander Grigoriev" <alegr@earthlink.net> wrote in message
> news:OA56TnADGHA.4004@tk2msftngp13.phx.gbl...
>> Note that in some recent Windows versions, the Period math got broken and
>> its value is limited to MAX_UINT/10000 ms (which is about 430 seconds).
>> Search for "timeSetEvent() wraps after inteval of 429496" thread in
>> microsoft.public.win32.programmer.mmedia in June 2005.
>>
>> "Mark Roddy" <markr@hollistech.com> wrote in message
>> news:lds5r15egja2f5m6ia243eskn4gude2mr0@4ax.com...
>>> On 28 Dec 2005 10:51:43 -0800, "Eric Ahn" <byungwook.ahn@gmail.com>
>>> wrote:
>>>
>>>>LARGE_INTEGER DueTime;
>>>>ULONG Period = 5000;/* 5sec */
>>>>
>>>>DueTime.QuadPart = -1;//(LONGLONG)IP_TIMEOUT * 10000;
>>>>KeSetTimerEx(
>>>> &Globals.KeyboardExtension->UserTimer,
>>>> DueTime,
>>>> Period,
>>>> &Globals.KeyboardExtension->InsertDpcObj);
>>>>
>>>>thanks.
>>>>
>>>>If run a dpc routine after 10ms, What is the DueTIme, Period value?
>>>
>>>
>>> DueTime should be set to the appropriate value for 10ms * -1. Period
>>> will determine the frequency in ms after the initial timer expires. So
>>> if your period is 5s then after the initial 10ms your dpc will fire
>>> every 5s.
>>>
>>> The DDK docs appear to have no explanation for the Period parameter's
>>> relationship to the DueTime parameter.
>>>
>>> In your code segment above you appear to be setting DueTime to -1,
>>> which I think is one 10ns tick. Is that what you intended? Wouldn't
>>> (-1 * 10000 * 5000) or 5s in the future be more appropriate?
>>> =====================
>>> Mark Roddy DDK MVP
>>> Windows Vista/2003/XP/2000 Consulting
>>> Device and Filesystem Drivers
>>> Hollis Technology Solutions 603-321-1032
>>> www.hollistech.com
>>
>>
>
>

Doron
Thu Dec 29 00:53:42 CST 2005

the timer code in the kernel is owned by the very most senior developers in
windows. the impl of KeSetTimerEx has not changed for many years; if there
was a bug computing the period, i think it would have shown up by now.

d

--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.


"Alexander Grigoriev" <alegr@earthlink.net> wrote in message
news:ech%23n9CDGHA.140@TK2MSFTNGP12.phx.gbl...
> OK, the bug is definitely in the very beginning of WINMM!timeSetTimerEvent
> (32-bit multiply by 10000 is used), but I would suggest checking periodic
> kernel timer code as well, since the math is similar and such bugs don't
> go alone. Could you forward it to the relevant developers, please?
>
> "Doron Holan [MS]" <doronh@nospam.microsoft.com> wrote in message
> news:%23CVrTjBDGHA.3992@TK2MSFTNGP12.phx.gbl...
>> you are referring to a UM api. I don't know if it just thunks to the
>> kernel (i doubt it), but a bug here does not mean there is a bug in
>> KeSetTimerEx
>>
>> d
>>
>> --
>> Please do not send e-mail directly to this alias. this alias is for
>> newsgroup purposes only.
>> This posting is provided "AS IS" with no warranties, and confers no
>> rights.
>>
>>
>> "Alexander Grigoriev" <alegr@earthlink.net> wrote in message
>> news:OA56TnADGHA.4004@tk2msftngp13.phx.gbl...
>>> Note that in some recent Windows versions, the Period math got broken
>>> and its value is limited to MAX_UINT/10000 ms (which is about 430
>>> seconds). Search for "timeSetEvent() wraps after inteval of 429496"
>>> thread in microsoft.public.win32.programmer.mmedia in June 2005.
>>>
>>> "Mark Roddy" <markr@hollistech.com> wrote in message
>>> news:lds5r15egja2f5m6ia243eskn4gude2mr0@4ax.com...
>>>> On 28 Dec 2005 10:51:43 -0800, "Eric Ahn" <byungwook.ahn@gmail.com>
>>>> wrote:
>>>>
>>>>>LARGE_INTEGER DueTime;
>>>>>ULONG Period = 5000;/* 5sec */
>>>>>
>>>>>DueTime.QuadPart = -1;//(LONGLONG)IP_TIMEOUT * 10000;
>>>>>KeSetTimerEx(
>>>>> &Globals.KeyboardExtension->UserTimer,
>>>>> DueTime,
>>>>> Period,
>>>>> &Globals.KeyboardExtension->InsertDpcObj);
>>>>>
>>>>>thanks.
>>>>>
>>>>>If run a dpc routine after 10ms, What is the DueTIme, Period value?
>>>>
>>>>
>>>> DueTime should be set to the appropriate value for 10ms * -1. Period
>>>> will determine the frequency in ms after the initial timer expires. So
>>>> if your period is 5s then after the initial 10ms your dpc will fire
>>>> every 5s.
>>>>
>>>> The DDK docs appear to have no explanation for the Period parameter's
>>>> relationship to the DueTime parameter.
>>>>
>>>> In your code segment above you appear to be setting DueTime to -1,
>>>> which I think is one 10ns tick. Is that what you intended? Wouldn't
>>>> (-1 * 10000 * 5000) or 5s in the future be more appropriate?
>>>> =====================
>>>> Mark Roddy DDK MVP
>>>> Windows Vista/2003/XP/2000 Consulting
>>>> Device and Filesystem Drivers
>>>> Hollis Technology Solutions 603-321-1032
>>>> www.hollistech.com
>>>
>>>
>>
>>
>
>

pavel_a
Thu Dec 29 07:08:03 CST 2005

430 seconds is *way* too long for multimedia apps
( sounds like 640 kb is way enough for everybody?)

--PA

Alexander
Thu Dec 29 11:34:02 CST 2005

OK, but it would be nice to fix WINMM!timeSetTimerEvent

"Doron Holan [MS]" <doronh@nospam.microsoft.com> wrote in message
news:u3XtcSEDGHA.2912@tk2msftngp13.phx.gbl...
> the timer code in the kernel is owned by the very most senior developers
> in windows. the impl of KeSetTimerEx has not changed for many years; if
> there was a bug computing the period, i think it would have shown up by
> now.
>
> d
>
> --
> Please do not send e-mail directly to this alias. this alias is for
> newsgroup purposes only.
> This posting is provided "AS IS" with no warranties, and confers no
> rights.
>
>
> "Alexander Grigoriev" <alegr@earthlink.net> wrote in message
> news:ech%23n9CDGHA.140@TK2MSFTNGP12.phx.gbl...
>> OK, the bug is definitely in the very beginning of
>> WINMM!timeSetTimerEvent (32-bit multiply by 10000 is used), but I would
>> suggest checking periodic kernel timer code as well, since the math is
>> similar and such bugs don't go alone. Could you forward it to the
>> relevant developers, please?

Doron
Thu Dec 29 13:36:35 CST 2005

i agree. if there is a KB article about it, i am sure there is already a bug
for it

d

--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.


"Alexander Grigoriev" <alegr@earthlink.net> wrote in message
news:%23$HNR4JDGHA.1028@TK2MSFTNGP11.phx.gbl...
> OK, but it would be nice to fix WINMM!timeSetTimerEvent
>
> "Doron Holan [MS]" <doronh@nospam.microsoft.com> wrote in message
> news:u3XtcSEDGHA.2912@tk2msftngp13.phx.gbl...
>> the timer code in the kernel is owned by the very most senior developers
>> in windows. the impl of KeSetTimerEx has not changed for many years; if
>> there was a bug computing the period, i think it would have shown up by
>> now.
>>
>> d
>>
>> --
>> Please do not send e-mail directly to this alias. this alias is for
>> newsgroup purposes only.
>> This posting is provided "AS IS" with no warranties, and confers no
>> rights.
>>
>>
>> "Alexander Grigoriev" <alegr@earthlink.net> wrote in message
>> news:ech%23n9CDGHA.140@TK2MSFTNGP12.phx.gbl...
>>> OK, the bug is definitely in the very beginning of
>>> WINMM!timeSetTimerEvent (32-bit multiply by 10000 is used), but I would
>>> suggest checking periodic kernel timer code as well, since the math is
>>> similar and such bugs don't go alone. Could you forward it to the
>>> relevant developers, please?
>
>

Alexander
Thu Dec 29 13:43:32 CST 2005

I don't think there is a KB article.

"Doron Holan [MS]" <doronh@nospam.microsoft.com> wrote in message
news:%23kbWv8KDGHA.2912@tk2msftngp13.phx.gbl...
>i agree. if there is a KB article about it, i am sure there is already a
>bug for it
>
> d
>
> --
> Please do not send e-mail directly to this alias. this alias is for
> newsgroup purposes only.
> This posting is provided "AS IS" with no warranties, and confers no
> rights.
>
>
> "Alexander Grigoriev" <alegr@earthlink.net> wrote in message
> news:%23$HNR4JDGHA.1028@TK2MSFTNGP11.phx.gbl...
>> OK, but it would be nice to fix WINMM!timeSetTimerEvent
>>
>> "Doron Holan [MS]" <doronh@nospam.microsoft.com> wrote in message
>> news:u3XtcSEDGHA.2912@tk2msftngp13.phx.gbl...
>>> the timer code in the kernel is owned by the very most senior developers
>>> in windows. the impl of KeSetTimerEx has not changed for many years; if
>>> there was a bug computing the period, i think it would have shown up by
>>> now.
>>>
>>> d
>>>
>>> --
>>> Please do not send e-mail directly to this alias. this alias is for
>>> newsgroup purposes only.
>>> This posting is provided "AS IS" with no warranties, and confers no
>>> rights.
>>>
>>>
>>> "Alexander Grigoriev" <alegr@earthlink.net> wrote in message
>>> news:ech%23n9CDGHA.140@TK2MSFTNGP12.phx.gbl...
>>>> OK, the bug is definitely in the very beginning of
>>>> WINMM!timeSetTimerEvent (32-bit multiply by 10000 is used), but I would
>>>> suggest checking periodic kernel timer code as well, since the math is
>>>> similar and such bugs don't go alone. Could you forward it to the
>>>> relevant developers, please?
>>
>>
>
>

Pavel
Thu Dec 29 20:50:41 CST 2005

Looks like timeSetTimerEvent has already been fixed
in the Vista tree. To get the fix backported to XP/W2K3
you'll probably need to go through PSS.

--
This posting is provided "AS IS" with no warranties, and confers no
rights.

"Alexander Grigoriev" wrote:

>I don't think there is a KB article.
>
>>i agree. if there is a KB article about it, i am sure there is already a
>>bug for it
>>
>>> OK, but it would be nice to fix WINMM!timeSetTimerEvent
>>>
>>>>> OK, the bug is definitely in the very beginning of
>>>>> WINMM!timeSetTimerEvent (32-bit multiply by 10000 is used), but I
>>>>> would suggest checking periodic kernel timer code as well, since the
>>>>> math is similar and such bugs don't go alone. Could you forward it to
>>>>> the relevant developers, please?

Maxim
Sun Jan 01 03:16:03 CST 2006

It is negative value, in 100ns units.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com

"Eric Ahn" <byungwook.ahn@gmail.com> wrote in message
news:1135792565.094067.99800@g14g2000cwa.googlegroups.com...
> sample source)
>
>
> KTimer Timer;
> LARGE_INTEGER dueTimer = 0xfff0bdc0;
> LARGE_INTEGER period = 0xffffffff;
>
> KDPC dpc;
>
> KeInitializeTimerEx(&Timer, SynchronizationTimer);
> KeInitializeDpc(&dpc,
> (PKDEFERRED_ROUTINE)TimerRoutine,
> devicecontext);
> KeSetTimerEx(&Timer, dueTimer , period );
>
>
> I wonder that dueTimer, period argument in tKeSetTImerEx.
> It have too much value.
>
> help this, thanks
>