Power button and hotfix Q833642

[Georges Berenger]

For my device, I need to detect that the power button has been pressed,
a problem discussed many times...
I have a message filter that properly intercepts
WM_POWERBROADCAST/PBT_APMQUERYSUSPEND when the power button is pressed,
and I can take the appropriate action (ask the user for a confirmation).
Before installing Q833642, life was good.
Since I applied the hotfix Q833642, I still get the message, but then,
no matter what I do, my system powers down after a few seconds. My apps
aren't quit, the system is simply powered off. In response to the
WM_POWERBROADCAST/PBT_APMQUERYSUSPEND message, I properly return
BROADCAST_QUERY_DENY which should cancel the system's shutdown, but
obviously, that doesn't work.

An obvious short-term solution is to remove the hotfix, which I had
installed in the hope that an other problem would be solved (the monitor
going off after a while), no matter what power saving policy had been set.

Is there something else I could try to prevent the system from powering
down?
Maybe someone at MS can make sure that SP2's Minlogon will behave
properly there, since we will then be unable to select what old-patches
are installed (I am assuming that Q833642 will be built-in SP2, hence my
worry...).
Thanks,
-georges

 

[KM]

Georges,

Have you tried overwriting system power scheme policy?
You can do that through API (SetActivePwrScheme, CallNtPowerInformation(SystemPowerPolicyCurrent, ...), etc.) or directly through
the directly (not recommended).

Try adding/changing PowerActionShutdownOff action policy flags to POWER_ACTION_QUERY_ALLOWED.

Search MSDN for more details. You can start here: http://msdn.microsoft.com/library/en-us/power/base/setactivepwrscheme.asp
And I recall some code has been posted in NG.

 

[Slobodan Brcin \(eMVP\)]

Hi George,

I hope that someone from MS will look into this if some other solution is not found.

This is a problem that I have expected from day one when I saw this QFE. This is a reason why I did not install it, and since I have
solved all other problems (Including monitor goes off) I did not saw point in wasting time with potential new problems with this
QFE.

You can try configuring action for power button to be none. So minlogon itself will not try to shutdown the system.
Since your application is started later regarding the minlogon application the minlogon gets priority in hooking to this message and
it handles it before you get a change to fail this request. So only way if possible is to tell minlogon to do nothing.

I think that Konstantin gave some solution to setting power policies in registry, but I can't find this.
My solution is rather brutal since in existing driver thread that I have made for other purposes I just tell OS that monitor is
required and that reset counter to zero.

Best regards,
Slobodan

PS:
Let us know what you find out.

 

[Georges Berenger]

First, thanks to both for answering.
Yes, I have tried a number of thing using the power APIs. Currently, I
do something like:

SYSTEM_POWER_POLICY policy;
::CallNtPowerInformation(SystemPowerPolicyAc, NULL, 0, &policy,
sizeof(policy));
policy.PowerButton.Action = PowerActionShutdown;
policy.PowerButton.Flags = POWER_ACTION_QUERY_ALLOWED |
POWER_ACTION_UI_ALLOWED;
policy.PowerButton.EventCode = 0;
policy.VideoTimeout = 60*60*24*7;
policy.VideoDimDisplay = FALSE;
::CallNtPowerInformation(SystemPowerPolicyAc, &policy, sizeof(policy),
&policy, sizeof(policy);

With this & the hotfix, I get notified, but the system shuts down no
matter what.
If I replace the power button action with policy.PowerButton.Action =
PowerActionNone;, then I get no notification whatsoever (and no
shutdown), which doesn't solve my problem either.

Other suggestions?

Could someone at MS take note of this potential issue and make sure that
SP2 doesn't have this problem? Thanks!
-georges

 

[KM]

Georges,

Not to fix the main issue you are having but rather to suggest a workaround (or a way to try) for monitor issue you have.

Try to call CallNtPowerInformation( AdministratorPowerPolicy, ...) to set up ADMINISTRATOR_POWER_POLICY structure fields.
Particularly try setting MinVideoTimeout and MaxVideoTimeout parameters to some big value.

When I played with these values I was able to set any timeout on Winlogon/Minlogon images with and without that QFE.


Also, I think it may be better for you to change not just AC policies (I see SystemPowerPolicyAc in your code) but rather
SystemPowerPolicyCurrent. I am not sure if there is any difference but I used SystemPowerPolicyCurrent.
Also verify the policy setting in the system (to be sure about what gets set) - VerifySystemPolicyAc.

 

[Slobodan Brcin \(eMVP\)]

Hi Georges,

I can only guess what can be the problem.
For instance minlogon could instead of unhooking itself from WM_POWERBROADCAST choose to abort this request so you never receive it.

Perhaps if there is no other solution to this you can write service that would respond to this event before minlogon, or somehow use
WMI to pull for current state of power button.

Best regards,
Slobodan

BTW:
You can fill form that Andy Allred posted recently in this NG.
http://groups.google.com/groups?hl=...f=1&selm=#[email protected]

 

[Georges Berenger]

Georges,

Not to fix the main issue you are having but rather to suggest a workaround (or a way to try) for monitor issue you have.

Monitor? I have a power button issue, not a monitor issue... ;-)

Try to call CallNtPowerInformation( AdministratorPowerPolicy, ...) to set up ADMINISTRATOR_POWER_POLICY structure fields.
Particularly try setting MinVideoTimeout and MaxVideoTimeout parameters to some big value.
....

When I played with these values I was able to set any timeout on Winlogon/Minlogon images with and without that QFE.


Also, I think it may be better for you to change not just AC policies (I see SystemPowerPolicyAc in your code) but rather
SystemPowerPolicyCurrent. I am not sure if there is any difference but I used SystemPowerPolicyCurrent.
Also verify the policy setting in the system (to be sure about what gets set) - VerifySystemPolicyAc.

Actually, if I use SystemPowerPolicyCurrent (when setting it), I do get
an error. If I use ac, not only do I not get an error when I place the
call, but I can prove that the call are effective in some ways (changing
the video timeout works more or less, and changing the power button
policy does make a difference).

-georges

 

[KM]

Georges,
workaround (or a way to try) for monitor issue you have.

Monitor? I have a power button issue, not a monitor issue... ;-)

Hmmm.. I thought you put this in the post: "an other problem would be solved
(the monitor
going off after a while)". Did I misread this?

....

KM

 

[Georges Berenger]

Georges,



workaround (or a way to try) for monitor issue you have.



Hmmm.. I thought you put this in the post: "an other problem would be solved
(the monitor
going off after a while)". Did I misread this?

Indeed, I wrote that, sorry.
It is in facts because what you suggest doesn't work the way it should
that I tried to update minlogon in the first place.
BTW, in the meantime, I have found an easy way around the monitor issue.
Just make the call:
::SetThreadExecutionState(ES_DISPLAY_REQUIRED | ES_CONTINUOUS);

Cheers,
-georges

 

[Slobodan Brcin \(eMVP\)]

Hi Georges,

In my main driver thread I have been using:
PoSetSystemState(ES_USER_PRESENT | ES_DISPLAY_REQUIRED | ES_SYSTEM_REQUIRED);

Although usage of PoRegisterSystemState <=>SetThreadExecutionState should also be ok.

Best regards,
Slobodan