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

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.googlegro ups.com...

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?

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


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

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...

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...

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...

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...

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...

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

--PA

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...

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...

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...

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:

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.googlegro ups.com...