Hi,
I wanted to know is there any difference in WaitForSingleObject() in user mode and in kernel mode?
I am using this function in an application with time (example 30 sec). If after running this app, i put my system in sleep state, does it mean the timer will be off? If i wake up after 20 seconds, then i am getting control back after 20+30=50 seconds?
Is there any wait call can be used which is active also during sleep state?
Thanks,
Hitesh
You might try the experient…
Of course, this only tells you what the current OS version, service pack,
and hotfix set do.
joe
Hi,
I wanted to know is there any difference in WaitForSingleObject() in user
mode and in kernel mode?
I am using this function in an application with time (example 30 sec). If
after running this app, i put my system in sleep state, does it mean the
timer will be off? If i wake up after 20 seconds, then i am getting
control back after 20+30=50 seconds?Is there any wait call can be used which is active also during sleep
state?Thanks,
Hitesh
NTDEV is sponsored by OSR
Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
OSR is HIRING!! See http://www.osr.com/careers
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminarsTo unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
>>is there any difference in WaitForSingleObject() in user mode and in kernel mode?
There should not be any; you obviously have to care about IRQL in kernel mode; But the function itself should behave same.
>If after running this app, i put my system in sleep state, does it mean the timer will be off?
What do you mean by put system in sleep state? you are going to put just the calling thread into wait state.
When you call Sleep; the thread is going to be in wait mode; till the associated timer is signaled. It may still not get executed even after the timer is signaled; due to decision taken by thread scheduler. So the time after which the thread will wake will be > time specified in API call.
>Is there any wait call can be used which is active also during sleep state?
Not sure I got your motive here; If you just want to wait for a object for a specified time; can’t you simply specify the timeout in waitforsingleobject ?
Aditya
When using WinDBG and stepping through code, time will pass while the debugee is between steps - so my guess is that the answer is (no, no, yes - WaitForSingleObject). The call will complete after a real 30 seconds has passed, or as soon as you wake the computer any time after 30 seconds has passed.
>after a real 30 seconds has passed
No, after 30 target seconds passed. When the debuggee is stalled in WinDbg, its target time is stalled too.
–
Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com
Hi Max - I just want to understand what you’re saying… I thought I could recall at some point having a module that had a timer that would make a callback every n seconds (let’s call n=10). If I was stepping through this code, if I waited more than 10 seconds before a step, the timer would fire right away. But if I were to step more quickly, the actual time would pass before windbg would break again in the callback. The way I processed this was to think of timed operations as something that triggered at set timestamps, and this time would pass whether threads were suspended or not.
From what you’re saying, my conclusions were incorrect. So ALL time operations are stalled on the target when Windbg has the target stalled - is what you’re saying? CPU counters included?
during kernel debugging the target computer’s time is stalled
.time command will show the debuggees (target ) time
.echotime will show the hosts time
kd> .time;.echotime
Debug session time: Wed Dec 18 02:47:01.097 2013 (UTC + 5:30)
Debugger (not debuggee) time: Wed Dec 18 04:37:43.390 2013 (UTC + 5:30)
kd> g and hit ctrl+break again on windbg
2 hours lag
kd> .time;.echotime
Debug session time: Wed Dec 18 04:39:28.464 2013 (UTC + 5:30)
System Uptime: 0 days 0:09:51.460
Debugger (not debuggee) time: Wed Dec 18 04:39:33.093 2013 (UTC + 5:30)
5 seconds lag
On 12/18/13, xxxxx@comcast.net wrote:
> Hi Max - I just want to understand what you’re saying… I thought I could
> recall at some point having a module that had a timer that would make a
> callback every n seconds (let’s call n=10). If I was stepping through this
> code, if I waited more than 10 seconds before a step, the timer would fire
> right away. But if I were to step more quickly, the actual time would pass
> before windbg would break again in the callback. The way I processed this
> was to think of timed operations as something that triggered at set
> timestamps, and this time would pass whether threads were suspended or not.
>
>
> From what you’re saying, my conclusions were incorrect. So ALL time
> operations are stalled on the target when Windbg has the target stalled - is
> what you’re saying? CPU counters included?
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
Also certain watchdog timers assert when you wait too long between stepping operations. How would that be true if the target computer’s time was stalled?
>>>is there any difference in WaitForSingleObject() in user mode and in
>> kernel mode?
There should not be any; you obviously have to care about IRQL in kernel
mode; But the function itself should behave same.
Logically, no. The major difference is that in the kernel, you supply
pointers to KEVENTs, KMUTEXes, KSEMAPHOREs, etc, (but not fast mutice,
executive resources, or spin locks). Otherwise, behavior is the same,
because all WaitFor… presumably does is convert the handles to addresses
and calls KeWaitFor…
>>If after running this app, i put my system in sleep state, does it mean
>> the timer will be off?
What do you mean by put system in sleep state? you are going to put just
the calling thread into wait state.
I presume the OP meant putting the system into sleep state, that is,
devices will get “move to D1” or “move to D2” power messages ( and the
driver may choose to move the device to D3 state). I will make no
pretensions about understanding the S-states. Power experts are free to
jump on me.
Somehow this thread tured into a discussion of how windbg breakpoints stop
the clock, which seems to have nothing to do with the original question.
Waitable timers, if I recall, have an option to force a wakeup when they
expire; this suggests that timers may be based on absolute time passing,
indpendent of the system state, but I never thought too deeply about it.
My expectation was that in the absence of the wakeup option, tiers tat
expired while the system was in wait state would not be dispatched until
wakeup. But again, this is just my opinion, based on what I thought I
understood.
When you call Sleep; the thread is going to be in wait mode; till the
associated timer is signaled. It may still not get executed even after the
timer is signaled; due to decision taken by thread scheduler. So the time
after which the thread will wake will be > time specified in API call.
But the question stated putting the /system/ into sleep state, not issuing
a Sleep API on a thread.
>>Is there any wait call can be used which is active also during sleep
>> state?
Not sure I got your motive here; If you just want to wait for a object for
a specified time; can’t you simply specify the timeout in
waitforsingleobject ?
The issue here is what happens if the WaitFor… specifies a timeout which
would expire while the system is in sleep (but not hibernate) state. I
offer my opinion that nothing happens, but that when te system returns to
an active state, it finds potentially a lot of WaitFor… calls with
expired timers, and marks those threads as “feasible to run”. Eventually,
depending on what other threads might be runnable, the WaitFor… calls
return with a timeout result code. However, this represents behavior I am
inferring from my readings, and it may not work that way at all.
As far as execution-time counters, if the system is asleep, nothing is
being executed, so my suspicion is that they will stop. Which does
suggest that if absolute time is used, it has to be determined by other
means than the system timers, but everything I’m saying is speculation,
based on my experience in a variety of other systems. Which is why I
suggested the experiment, but if one of te Micosoft folks jumps in, I hope
it will be to state what is actually perceived to happen (and not
nexessarily how this perceived behavior is implemented in various versions
of Windows or variousvplatforms).
joe
Aditya
NTDEV is sponsored by OSR
Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
OSR is HIRING!! See http://www.osr.com/careers
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminarsTo unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
Absolute timeout intervals track changes to system time.
Relative timeout intervals don’t track changes to system time.
With the notable exception of SetWaitableTimer(), absolute timeout intervals are generally not exposed to the Win32 layer, though they are available in kernel mode. (Generally speaking, situations where an absolute timeout is the correct choice are relatively uncommon.). Should one elect to use an absolute timeout interval, scenarios like the user changing the system clock, the time synchronization service changing the system clock, time slip after exiting a kernel debugger break-in, etc. may need appropriate handling.
From: xxxxx@flounder.commailto:xxxxx
Sent: ?Tuesday?, ?December? ?17?, ?2013 ?10?:?56? ?PM
To: ntdevmailto:xxxxx
>>>is there any difference in WaitForSingleObject() in user mode and in
>>> kernel mode?
> There should not be any; you obviously have to care about IRQL in kernel
> mode; But the function itself should behave same.
>
Logically, no. The major difference is that in the kernel, you supply
pointers to KEVENTs, KMUTEXes, KSEMAPHOREs, etc, (but not fast mutice,
executive resources, or spin locks). Otherwise, behavior is the same,
because all WaitFor… presumably does is convert the handles to addresses
and calls KeWaitFor…
>>>If after running this app, i put my system in sleep state, does it mean
>>> the timer will be off?
> What do you mean by put system in sleep state? you are going to put just
> the calling thread into wait state.
>
I presume the OP meant putting the system into sleep state, that is,
devices will get “move to D1” or “move to D2” power messages ( and the
driver may choose to move the device to D3 state). I will make no
pretensions about understanding the S-states. Power experts are free to
jump on me.
Somehow this thread tured into a discussion of how windbg breakpoints stop
the clock, which seems to have nothing to do with the original question.
Waitable timers, if I recall, have an option to force a wakeup when they
expire; this suggests that timers may be based on absolute time passing,
indpendent of the system state, but I never thought too deeply about it.
My expectation was that in the absence of the wakeup option, tiers tat
expired while the system was in wait state would not be dispatched until
wakeup. But again, this is just my opinion, based on what I thought I
understood.
> When you call Sleep; the thread is going to be in wait mode; till the
> associated timer is signaled. It may still not get executed even after the
> timer is signaled; due to decision taken by thread scheduler. So the time
> after which the thread will wake will be > time specified in API call.
But the question stated putting the /system/ into sleep state, not issuing
a Sleep API on a thread.
>
>>>Is there any wait call can be used which is active also during sleep
>>> state?
> Not sure I got your motive here; If you just want to wait for a object for
> a specified time; can’t you simply specify the timeout in
> waitforsingleobject ?
>
>
The issue here is what happens if the WaitFor… specifies a timeout which
would expire while the system is in sleep (but not hibernate) state. I
offer my opinion that nothing happens, but that when te system returns to
an active state, it finds potentially a lot of WaitFor… calls with
expired timers, and marks those threads as “feasible to run”. Eventually,
depending on what other threads might be runnable, the WaitFor… calls
return with a timeout result code. However, this represents behavior I am
inferring from my readings, and it may not work that way at all.
As far as execution-time counters, if the system is asleep, nothing is
being executed, so my suspicion is that they will stop. Which does
suggest that if absolute time is used, it has to be determined by other
means than the system timers, but everything I’m saying is speculation,
based on my experience in a variety of other systems. Which is why I
suggested the experiment, but if one of te Micosoft folks jumps in, I hope
it will be to state what is actually perceived to happen (and not
nexessarily how this perceived behavior is implemented in various versions
of Windows or variousvplatforms).
joe
> Aditya
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
—
NTDEV is sponsored by OSR
Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
OSR is HIRING!! See http://www.osr.com/careers
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer</mailto:xxxxx></mailto:xxxxx>
>changing the system clock, time slip after exiting a kernel debugger break-in
This stops the software timer but NOT the HW code-execution-independent timer like the good old PIT.
Windows sometimes synchronizes the time with this PIT (or HPET or what is used now).
So, just after a break-in, the Windows time (yes, even the one displayed in the screen corner) is back by far, it reflects the time when the kernel was stalled by the break-in.
But Windows sometimes (once per several minutes) synchronizes the times. When this occur after a break-in, all proper interval timers are fired, and the OS time suddenly jumps to the correct one.
–
Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com
Look at my response to Skywing below.
After the break-in, the OS’s software time (a global kernel variable) is seriously back. But, once per several minutes, Windows resyncs it with the code-independent time (from HPET or such), and, during this resync, all your interval timers go fired.
If you’re lucky, this occurs immediately when you say Go in the debugger.
–
Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com
wrote in message news:xxxxx@ntdev…
> Hi Max - I just want to understand what you’re saying… I thought I could recall at some point having a module that had a timer that would make a callback every n seconds (let’s call n=10). If I was stepping through this code, if I waited more than 10 seconds before a step, the timer would fire right away. But if I were to step more quickly, the actual time would pass before windbg would break again in the callback. The way I processed this was to think of timed operations as something that triggered at set timestamps, and this time would pass whether threads were suspended or not.
>
> From what you’re saying, my conclusions were incorrect. So ALL time operations are stalled on the target when Windbg has the target stalled - is what you’re saying? CPU counters included?
>
IIRC Windows kernel uses 2 global variables for time - one is a real-world time affected by time adjustment syscalls (from the UI or from NTP or such), and another is an always-forward notion of some “elapsed time since boot” which is NOT affected by them, and is only usable to measure elapsed times like ( TimeNow - TimeSavedAtStart ).
IIRC there was also 2 different KeXxx calls to query them, and, if you measure some elapsed times in your code and do not want to be broken if a race occurs between time adjustment path and your measurement, you should use the second.
Then the practical fact with WinDbg: immediately after restarting from break-in, the target lags its times by far back, this is even reflected by the clock UI.
Then, after several minutes, some resync occurs and the target returns back to normal time (taken from PIT or some similar thing).
At the moment of this resync, the usual interval (not absolute) KTIMERs are fired.
–
Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com
“Skywing” wrote in message news:xxxxx@ntdev…
Absolute timeout intervals track changes to system time.
Relative timeout intervals don’t track changes to system time.
With the notable exception of SetWaitableTimer(), absolute timeout intervals are generally not exposed to the Win32 layer, though they are available in kernel mode. (Generally speaking, situations where an absolute timeout is the correct choice are relatively uncommon.). Should one elect to use an absolute timeout interval, scenarios like the user changing the system clock, the time synchronization service changing the system clock, time slip after exiting a kernel debugger break-in, etc. may need appropriate handling.
- S (Msft)
From: xxxxx@flounder.com
Sent: ?Tuesday?, ?December? ?17?, ?2013 ?10?:?56? ?PM
To: ntdev
>>>is there any difference in WaitForSingleObject() in user mode and in
>>> kernel mode?
> There should not be any; you obviously have to care about IRQL in kernel
> mode; But the function itself should behave same.
>
Logically, no. The major difference is that in the kernel, you supply
pointers to KEVENTs, KMUTEXes, KSEMAPHOREs, etc, (but not fast mutice,
executive resources, or spin locks). Otherwise, behavior is the same,
because all WaitFor… presumably does is convert the handles to addresses
and calls KeWaitFor…
>>>If after running this app, i put my system in sleep state, does it mean
>>> the timer will be off?
> What do you mean by put system in sleep state? you are going to put just
> the calling thread into wait state.
>
I presume the OP meant putting the system into sleep state, that is,
devices will get “move to D1” or “move to D2” power messages ( and the
driver may choose to move the device to D3 state). I will make no
pretensions about understanding the S-states. Power experts are free to
jump on me.
Somehow this thread tured into a discussion of how windbg breakpoints stop
the clock, which seems to have nothing to do with the original question.
Waitable timers, if I recall, have an option to force a wakeup when they
expire; this suggests that timers may be based on absolute time passing,
indpendent of the system state, but I never thought too deeply about it.
My expectation was that in the absence of the wakeup option, tiers tat
expired while the system was in wait state would not be dispatched until
wakeup. But again, this is just my opinion, based on what I thought I
understood.
> When you call Sleep; the thread is going to be in wait mode; till the
> associated timer is signaled. It may still not get executed even after the
> timer is signaled; due to decision taken by thread scheduler. So the time
> after which the thread will wake will be > time specified in API call.
But the question stated putting the /system/ into sleep state, not issuing
a Sleep API on a thread.
>
>>>Is there any wait call can be used which is active also during sleep
>>> state?
> Not sure I got your motive here; If you just want to wait for a object for
> a specified time; can’t you simply specify the timeout in
> waitforsingleobject ?
>
>
The issue here is what happens if the WaitFor… specifies a timeout which
would expire while the system is in sleep (but not hibernate) state. I
offer my opinion that nothing happens, but that when te system returns to
an active state, it finds potentially a lot of WaitFor… calls with
expired timers, and marks those threads as “feasible to run”. Eventually,
depending on what other threads might be runnable, the WaitFor… calls
return with a timeout result code. However, this represents behavior I am
inferring from my readings, and it may not work that way at all.
As far as execution-time counters, if the system is asleep, nothing is
being executed, so my suspicion is that they will stop. Which does
suggest that if absolute time is used, it has to be determined by other
means than the system timers, but everything I’m saying is speculation,
based on my experience in a variety of other systems. Which is why I
suggested the experiment, but if one of te Micosoft folks jumps in, I hope
it will be to state what is actually perceived to happen (and not
nexessarily how this perceived behavior is implemented in various versions
of Windows or variousvplatforms).
joe
> Aditya
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
—
NTDEV is sponsored by OSR
Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
OSR is HIRING!! See http://www.osr.com/careers
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer