Hi,
I apologize if this is posted twice. I have only posted in the NTFSD group in the past, and may have tried to post here before I was granted access to the NTDEV group.
This is actually a user mode question, but since there are so many people intimately familiar with the internals of Windows here, I thought I’d give it a try.
I have a service running in Windows that catches the power broadcast messages. I’m notified whenever the system is going to power off, suspend, or stand by. My problem is I have no way of telling the difference between standby and suspend. It’s stated somewhere in MSDN that PBT_APMSTANDBY is never sent, and that PBT_APMSUSPEND is sent for both standby and suspend. Is there any way of telling what the destination power state of the system is going to be aside from writing a driver? I’m hoping there’s a driver I can interface with rather than going through the process of creating something just for this purpose. I certainly haven’t been able to find anything online so if anyone has any ideas, I would really appreciate it. Thanks!!
Scott
Given that the only effective difference between “standby” and
“suspend” relates to which devices are armed for wake and the exact
number of milliamps drawn in that mode, why do you care?
Curious,
Jake
wrote in message news:xxxxx@ntdev…
> Hi,
>
> I apologize if this is posted twice. I have only posted in the
> NTFSD group in the past, and may have tried to post here before I
> was granted access to the NTDEV group.
>
> This is actually a user mode question, but since there are so many
> people intimately familiar with the internals of Windows here, I
> thought I’d give it a try.
>
> I have a service running in Windows that catches the power broadcast
> messages. I’m notified whenever the system is going to power off,
> suspend, or stand by. My problem is I have no way of telling the
> difference between standby and suspend. It’s stated somewhere in
> MSDN that PBT_APMSTANDBY is never sent, and that PBT_APMSUSPEND is
> sent for both standby and suspend. Is there any way of telling what
> the destination power state of the system is going to be aside from
> writing a driver? I’m hoping there’s a driver I can interface with
> rather than going through the process of creating something just for
> this purpose. I certainly haven’t been able to find anything online
> so if anyone has any ideas, I would really appreciate it. Thanks!!
>
> Scott
>
Sorry for the ambiguity. I’m sure for most, that might be the only effective difference. For me, the big difference is that rather than data being kept available in RAM for a “standby”, it’s flushed to disk for “suspend” (which matters a great deal to this product.) We must differentiate between the two in order to effectively roam between machines.
Again, if it’s not possible to discern the difference in user mode, I’ve resigned to just write a driver and go through WHQL, but I’m really hoping there might be an easier solution. Thanks for taking a look Jake, and I appreciate any suggestions you might have, hopeful or not. 
Actually, “suspend” and “standby” both refer to data being kept in
RAM. “Hibernate” is when the data is written to disk. I believe that
apps can tell the difference for that one.
wrote in message news:xxxxx@ntdev…
> Sorry for the ambiguity. I’m sure for most, that might be the only
> effective difference. For me, the big difference is that rather
> than data being kept available in RAM for a “standby”, it’s flushed
> to disk for “suspend” (which matters a great deal to this product.)
> We must differentiate between the two in order to effectively roam
> between machines.
>
> Again, if it’s not possible to discern the difference in user mode,
> I’ve resigned to just write a driver and go through WHQL, but I’m
> really hoping there might be an easier solution. Thanks for taking
> a look Jake, and I appreciate any suggestions you might have,
> hopeful or not.
>
> Actually, “suspend” and “standby” both refer to data being kept in RAM.
“Hibernate” is when the data is written to disk. I believe that apps can tell the difference for that one.
IIRC, a page that does not get accessed for 4 secs becomes a candidate for paging (certainly, if it refers to pageable memory). Therefore, it looks like if you go to "suspend"or “standby” state , data is going to end up in the swap file anyway…
Anton Bassov
OK, so it’s probably my terminology that’s wrong. I was under the impression from the MSDN documentation that standby was equivalent to sleep, and suspend was equivalent to hibernate. My issue is just that I need to determine betwee sleep and hibernate. The power broadcast messages seem to be the same no matter which state the computer is going to. Anyone know of a way other than the power broadcast messages to tell how far down I’m headed? Or if there is a way to query once I realize the machine is starting to go down? Many thanks to anyone with ideas.
Can’t rule it out entirely, of course, but I’ve looked around a fair
bit, and didn’t find anything except that the documentation for
WM_POWERBROADCAST says that apps can’t tell which state you’re going to:
“WM_POWERBROADCAST messages do not distinguish between different
low-power states. An application can determine only that the system is
entering or has resumed from a low-power state; it cannot determine the
specific power state. The system records details about power state
transitions in the Windows System event log.”
So there’s at least some chance you might be able to figure it out from
the event log. I suspect there’s an unresolvable race condition there,
though. You might only be able to tell once the system resumes. The fact
that they mentioned the log at all in that paragraph implies somewhat
that there isn’t a way to do it.
For a moment, I was thinking you might be able to use a UMDF driver
instead of diving into kernel mode, but it seems they only find out
about device power states and only when there’s an actual device there.
You might be able to convince it to create a virtual device… that’s
not really my area of expertise.
cslong@us.ibm.com wrote:
OK, so it’s probably my terminology that’s wrong. I was under the impression from the MSDN documentation that standby was equivalent to sleep, and suspend was equivalent to hibernate. My issue is just that I need to determine betwee sleep and hibernate. The power broadcast messages seem to be the same no matter which state the computer is going to. Anyone know of a way other than the power broadcast messages to tell how far down I’m headed? Or if there is a way to query once I realize the machine is starting to go down? Many thanks to anyone with ideas.
–
Ray
(If you want to reply to me off list, please remove “spamblock.” from my
email address)
There was a tool named “sleeper” in DDK 1830 (if memory serves…),
it could display all usermode powermode broadcasts.
Regards,
–PA
“Ray Trent” wrote in message
news:xxxxx@ntdev…
> Can’t rule it out entirely, of course, but I’ve looked around a fair bit,
> and didn’t find anything except that the documentation for
> WM_POWERBROADCAST says that apps can’t tell which state you’re going to:
>
> “WM_POWERBROADCAST messages do not distinguish between different low-power
> states. An application can determine only that the system is entering or
> has resumed from a low-power state; it cannot determine the specific power
> state. The system records details about power state transitions in the
> Windows System event log.”
>
> So there’s at least some chance you might be able to figure it out from
> the event log. I suspect there’s an unresolvable race condition there,
> though. You might only be able to tell once the system resumes. The fact
> that they mentioned the log at all in that paragraph implies somewhat that
> there isn’t a way to do it.
>
> For a moment, I was thinking you might be able to use a UMDF driver
> instead of diving into kernel mode, but it seems they only find out about
> device power states and only when there’s an actual device there. You
> might be able to convince it to create a virtual device… that’s not
> really my area of expertise.
>
> cslong@us.ibm.com wrote:
>> OK, so it’s probably my terminology that’s wrong. I was under the
>> impression from the MSDN documentation that standby was equivalent to
>> sleep, and suspend was equivalent to hibernate. My issue is just that I
>> need to determine betwee sleep and hibernate. The power broadcast
>> messages seem to be the same no matter which state the computer is going
>> to. Anyone know of a way other than the power broadcast messages to tell
>> how far down I’m headed? Or if there is a way to query once I realize
>> the machine is starting to go down? Many thanks to anyone with ideas.
>>
>
> –
> Ray
> (If you want to reply to me off list, please remove “spamblock.” from my
> email address)
>
There was a tool named “sleeper” in DDK 1830 (if memory serves…),
it could display all usermode powermode broadcasts.
If this program can’t show the target state, then perhaps nothing else can.
Also, because of the hybrid sleep, the target state is, er… hybrid.
Apps should prepare to hibernate, but the system
can actually sleep in S3 or S1 and never go to S4.
Regards,
–PA
“Ray Trent” wrote in message
news:xxxxx@ntdev…
> Can’t rule it out entirely, of course, but I’ve looked around a fair bit,
> and didn’t find anything except that the documentation for
> WM_POWERBROADCAST says that apps can’t tell which state you’re going to:
>
> “WM_POWERBROADCAST messages do not distinguish between different low-power
> states. An application can determine only that the system is entering or
> has resumed from a low-power state; it cannot determine the specific power
> state. The system records details about power state transitions in the
> Windows System event log.”
>
> So there’s at least some chance you might be able to figure it out from
> the event log. I suspect there’s an unresolvable race condition there,
> though. You might only be able to tell once the system resumes. The fact
> that they mentioned the log at all in that paragraph implies somewhat that
> there isn’t a way to do it.
>
> For a moment, I was thinking you might be able to use a UMDF driver
> instead of diving into kernel mode, but it seems they only find out about
> device power states and only when there’s an actual device there. You
> might be able to convince it to create a virtual device… that’s not
> really my area of expertise.
>
> cslong@us.ibm.com wrote:
>> OK, so it’s probably my terminology that’s wrong. I was under the
>> impression from the MSDN documentation that standby was equivalent to
>> sleep, and suspend was equivalent to hibernate. My issue is just that I
>> need to determine betwee sleep and hibernate. The power broadcast
>> messages seem to be the same no matter which state the computer is going
>> to. Anyone know of a way other than the power broadcast messages to tell
>> how far down I’m headed? Or if there is a way to query once I realize
>> the machine is starting to go down? Many thanks to anyone with ideas.
>>
>
> –
> Ray
> (If you want to reply to me off list, please remove “spamblock.” from my
> email address)
>
Thanks for all the replies so far. I’ve pretty much given up on a ‘user mode’ approach. I gave sleeper a shot, and it was returning the same broadcasts that I got in my service. Thanks for a little glimmer of hope though.
I had actually already started looking at the UMDF/KMDF approach. That’s all very new to me as I’ve only written a file system filter driver in the past, and it was the old fashioned way. I’m loving what I’ve read about the WDF approach though, and sincerely thank those whose names I’ve seen both in its documentation and the OSR forums for creating it. As Ray mentioned, it looks as if that will only give me D states rather than S states when leaving full power. I’m going to experiment with it some tonight to see what I can come up with. If anyone knows already though, I’m all ears.
Thanks again… Scott
You have 2 options in your KMDF driver, neither of which are available in UMDF.
-
register an ex callback and be notified of the Sx transition type right before it happens, http://blogs.msdn.com/doronh/archive/2006/06/13/630493.aspx
-
register a WDM preprocess routine (generic instructions at http://blogs.msdn.com/doronh/archive/2008/04/02/evtdevicepreprocesswdmirp-is-not-entirely-free.aspx) for IRP_MJ_POWER/IRP_MN_SET_POWER and look at system power irps
In either scheme you will need to notify your user mode application of the pending Sx state. The easiest solution is to have your app pend an IOCTL to the driver and at the right point, completes the request. I think the easiest way to do this would be to create a manual queue and fwd the request from your top level dispatch queue into the manual queue (where it will be cancelable until you pop it out).
d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of cslong@us.ibm.com
Sent: Tuesday, May 20, 2008 6:14 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] power transition information in user mode
Thanks for all the replies so far. I’ve pretty much given up on a ‘user mode’ approach. I gave sleeper a shot, and it was returning the same broadcasts that I got in my service. Thanks for a little glimmer of hope though.
I had actually already started looking at the UMDF/KMDF approach. That’s all very new to me as I’ve only written a file system filter driver in the past, and it was the old fashioned way. I’m loving what I’ve read about the WDF approach though, and sincerely thank those whose names I’ve seen both in its documentation and the OSR forums for creating it. As Ray mentioned, it looks as if that will only give me D states rather than S states when leaving full power. I’m going to experiment with it some tonight to see what I can come up with. If anyone knows already though, I’m all ears.
Thanks again… Scott
NTDEV is sponsored by OSR
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
I’m still pretty perplexed why you care about the difference. It’s not
like your app can do anything while in either suspend state, and
everything will be restored from disk to RAM before you ever see a
single CPU cycle when resuming from hibernate.
And also, you’ll need to figure out what to do about Vista’s hybrid
sleep, because it will look exactly like a suspend until after the long
timeout, at which point I don’t think your app will get a chance to do
anything before it hibernates.
cslong@us.ibm.com wrote:
Thanks for all the replies so far. I’ve pretty much given up on a ‘user mode’ approach. I gave sleeper a shot, and it was returning the same broadcasts that I got in my service. Thanks for a little glimmer of hope though.
I had actually already started looking at the UMDF/KMDF approach. That’s all very new to me as I’ve only written a file system filter driver in the past, and it was the old fashioned way. I’m loving what I’ve read about the WDF approach though, and sincerely thank those whose names I’ve seen both in its documentation and the OSR forums for creating it. As Ray mentioned, it looks as if that will only give me D states rather than S states when leaving full power. I’m going to experiment with it some tonight to see what I can come up with. If anyone knows already though, I’m all ears.
Thanks again… Scott
–
Ray
(If you want to reply to me off list, please remove “spamblock.” from my
email address)
Leave the poor guy alone, just because you can’t think of good reason
for him to do it doesn’t mean he doesn’t have one.
-z
Ray Trent wrote:
I’m still pretty perplexed why you care about the difference. It’s not
like your app can do anything while in either suspend state, and
everything will be restored from disk to RAM before you ever see a
single CPU cycle when resuming from hibernate.
And also, you’ll need to figure out what to do about Vista’s hybrid
sleep, because it will look exactly like a suspend until after the
long timeout, at which point I don’t think your app will get a chance
to do anything before it hibernates.
cslong@us.ibm.com wrote:
> Thanks for all the replies so far. I’ve pretty much given up on a
> ‘user mode’ approach. I gave sleeper a shot, and it was returning
> the same broadcasts that I got in my service. Thanks for a little
> glimmer of hope though.
>
xxxxx@xemaps.com wrote:
Leave the poor guy alone, just because you can’t think of good reason
for him to do it doesn’t mean he doesn’t have one.
80% of the time, when someone asks a question like this that doesn’t
seem to have any reasonable justification, the question arises from a
misunderstanding. When that happens, it is far preferable for us to pry
into the roots of the question, rather than give a pat answer that
allows the person to continue down a dead end path.
We aren’t sure which is the case here, of course, but it is not
reasonable for you to scold Ray for his question.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
True, there are quite a few people that come in here that are in way
over their heads and going down blind alleys. That can be tedious, but
you don’t have to reply to them. There is a large talent pool here and
a great deal of collective knowledge, but I think in general we could do
with a bit less arrogance and presumption. I have seen far too many
people chastised here for having curiosity or daring to have new ideas.
None of us has any clue what Scott’s ultimate goal is, and he may not be
at liberty to say. I think he should be applauded for exhausting his
user mode options before jumping into kernel mode.
-z
Tim Roberts wrote:
xxxxx@xemaps.com wrote:
> Leave the poor guy alone, just because you can’t think of good reason
> for him to do it doesn’t mean he doesn’t have one.
80% of the time, when someone asks a question like this that doesn’t
seem to have any reasonable justification, the question arises from a
misunderstanding. When that happens, it is far preferable for us to
pry into the roots of the question, rather than give a pat answer that
allows the person to continue down a dead end path.
We aren’t sure which is the case here, of course, but it is not
reasonable for you to scold Ray for his question.
Thanks again for more information.
I guess I should first say there is indeed a reason that I need to know whether the system is going to sleep or hibernate. Problem is, I can’t really go into detail as to why because it’s an unreleased product. I completely understand being questioned about this as it probably makes no sense to anyone, but it might make more sense to know that it’s not just how drivers/apps work on one system, but in an enterprise roaming environment. I certainly don’t feel like anyone should ‘give me a break’, especially since I’m here pestering people for help, so question me all you want. Flame me even!
Back to the problem, thanks for the tips Doron. If I understand the first link correctly, I still will be unable to determine the destination power state. As the documentation states - “If Argument1 is PO_CB_SYSTEM_STATE_LOCK, Argument2 contains zero if the system is about to leave S0 and one if the system has just reentered S0.” That leaves me looking at option #2 which seems promising. If there’s something undocumented or that I’ve misunderstood about the callback, let me know. For now though, I think I have the most hope in using the preprocess routine for the set_power.
xxxxx@xemaps.com wrote:
True, there are quite a few people that come in here that are in way
over their heads and going down blind alleys. That can be tedious,
but you don’t have to reply to them.
You miss my point. We are doing such people a FAVOR by questioning
their motivations, and hopefully redirecting their thinking down a more
productive path, thereby saving them frustration and wasted time. In
those relatively rare instances where the questioner is not “way over
their heads”, most of us are adult enough to back off.
In this particular case, I don’t think the conversation was ever
anything but polite. That’s partly why I don’t understand your
criticism. There have certainly been many threads here that veer
straight off into disdain and insults, but this was not one of them.
There is a large talent pool here and a great deal of collective
knowledge, but I think in general we could do with a bit less
arrogance and presumption.
Every newsgroup and mailing list has its own personality – its own
ambiance. This one happens to be a bit arrogant, in part because many
of us have been burned by being lumped in with hack driver writers who
try to take the shortcut path to wealth and riches, so to speak, instead
of taking the time to learn how to do things properly. When we see
others asking questions that imply a search for that “shortcut” path, it
naturally causes us to raise up on our haunches and go on the defensive.
OK, I think I’ve used up my metaphor quotient for today.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Wow… I never dreamed this thread would cause such debate. Sorry to provide a platform for battle! I must admit, I really am looking for a shortcut as this requirement came as a surprise late in the development cycle. That’s why I truly would like to write at the worst a KMDF driver. Writing the file system filter without that foundation was a very long path before I arrived at anything remotely stable, where this seems like it would take much less time. Or… if only there were an API in user mode!!
Anyway, just wanted to say sorry that this probably came about because of my inability to describe the exact ‘why’. Let there be peace again.
cslong@us.ibm.com wrote:
Wow… I never dreamed this thread would cause such debate. Sorry to provide a platform for battle!
Heck, this is not a battle. This is simple a polite exchange of
differing opinions.
If you want a BATTLE, just say something like “every driver writer
should be using C++, it’s the only reasonable language for programming.”
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Yes, my mistake. The ex callback does not give you enough information to know which Sx state the machine is going to. Irp_mn_set_power is your own recourse for now. In the next version of KMDF there will be a new API which will give you the target Sx state when called in a power down routine.
d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of cslong@us.ibm.com
Sent: Wednesday, May 21, 2008 5:00 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] power transition information in user mode
Thanks again for more information.
I guess I should first say there is indeed a reason that I need to know whether the system is going to sleep or hibernate. Problem is, I can’t really go into detail as to why because it’s an unreleased product. I completely understand being questioned about this as it probably makes no sense to anyone, but it might make more sense to know that it’s not just how drivers/apps work on one system, but in an enterprise roaming environment. I certainly don’t feel like anyone should ‘give me a break’, especially since I’m here pestering people for help, so question me all you want. Flame me even!
Back to the problem, thanks for the tips Doron. If I understand the first link correctly, I still will be unable to determine the destination power state. As the documentation states - “If Argument1 is PO_CB_SYSTEM_STATE_LOCK, Argument2 contains zero if the system is about to leave S0 and one if the system has just reentered S0.” That leaves me looking at option #2 which seems promising. If there’s something undocumented or that I’ve misunderstood about the callback, let me know. For now though, I think I have the most hope in using the preprocess routine for the set_power.
NTDEV is sponsored by OSR
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