another (new?) Power button problem

[=?ISO-8859-1?Q?Ulf_Jaenicke-R=F6=DFler?=]

Hi,

now that we have a non-trial TD I want to make some "final" image.
(thanks go another time to this group for getting me started!)

I installed all the hotfixes from MS - even Minlogon. However
I have a copy of my project for which I did not upgrade the Minlogon
component.
Everything works fine - with one exception. I found that immediately
after I change the power button action in the energy settings the
power button stops working (with minlogon after the upgrade as well
as with my application that uses WM_POWERBROADCAST with and without
the upgrade of Minlogon).

Any idea?
Thanks!
Ulf

 

[KM]

Ulf,

Did the QFE(s) make any difference in your run time regarding the power
button behaviour? We know it works with at least the old Minlogon.

Does your app get WM_POWERBROADCAST at all?

What settings you choose in the Power Managent section?

KM

 

[=?ISO-8859-1?Q?Ulf_Jaenicke-R=F6=DFler?=]

Did the QFE(s) make any difference in your run time regarding the power
button behaviour? We know it works with at least the old Minlogon.

Hmm, how would I know that? I tried hard to check which component might
be responsible. There are only a few which I suspect:
Primitive: ntdll
WinUser Api
Minlogon
Advanced Configuration And Power Interface (the hottest candidate).

Does your app get WM_POWERBROADCAST at all?

Yes and no :-(
First, I really thought that the behaviour directly depends on the
components and if I upgrade one or another the power button stopps
working. Hence I simply tested by including one component after the
other (it's a real PITA to run FBA everytime... ;-))
However I could include every component and the power button always
worked. Then I figured that as soon as I change the action on pressing
the power button (or don't change: just select the same setting and
"apply") the power button does not work anymore.
My program (as well as the new minlogon btw) do what it should before
this "apply", but not afterwards :-(

What settings you choose in the Power Managent section?

It does not depend on the settings. In fact I just pretend a change
by selecting the same setting again (it's shutdown, btw).

In the meantime I found that I can make a backup of the registry and
restore it after the "change" in power management and it works again.
But how do I keep users from trying a change? :-/

Anyway, it seems to come down to the registry keys AcPolicy and DcPolicy
in HKLM\System\CurrentControlSet(or ControlSet001)\Control\Session Manager\Power
and the key Policies in
HKEY_USERS\.Default\Control Panel\PowerCfg\GlobalPowerPolicy and
HKEY_USERS\S-so-me-thing\Control Panel\PowerCfg\GlobalPowerPolicy

I made a .reg file of these keys (working) and import it when the problem
occurs. Since I do not call any API function for setting the values
I need to reboot - but the my little power button is back again.

Hmm, what could I do to ensure that it will always work?

Regards
Ulf

 

[Slobodan Brcin \(eMVP\)]

Hi Ulf,

I always suspected that this might happen some day, unfortunately I don't have time to play with this option in near future

Try implementing in main loop of your program monitoring and resetting of changes by using something like:
ReadPwrScheme SetActivePwrScheme

Let us know it helps.

Best regards,
Slobodan

 

[=?ISO-8859-1?Q?Ulf_Jaenicke-R=F6=DFler?=]

Hi Slobodan,

I always suspected that this might happen some day,

I'm curious - what made you think that?

Try implementing in main loop of your program monitoring and resetting of
changes by using something like:
ReadPwrScheme SetActivePwrScheme

For tests (so far) I did:

ReadGlobalPwrPolicy
read all PowerSchemes (that is, a maximum of 10, otherwise as long as
ReadPwrScheme is successful - or is there another way to find ID and
name of a scheme?)
GetActivePwrScheme

When the power button becomes inactive I do
WriteGlobalPwrPolicy (the one read above)
SetActivePwrScheme (for the ID read above with data read just before)

Let us know it helps.

Yes, it does!

But - I HATE IT! Sorry for shouting. Why do I need to do that?
And where does the problem come from? Minlogon? Any other update?
My program worked before with Winlogon on Win2000, WinXP and even
WinXPe - before the updates. Any idea what might be responsible?

In any case I'm deeply indebted to you for the advice. Thanks so much!

Ulf

 

[Slobodan Brcin \(eMVP\)]

Hi Ulf,

I'm glad it helped you.

I'm curious - what made you think that?

In my testing WM_POWERBROADCAST was intercepted by few services/programs on regular WinXP but it worked on minlogon images since
there was no service that handled this message before I could get any chance to do this.
I expected that with new minlogon that support power buttons this message will get consumed by minlogon handler.

I guess that these registry changes you set in the first place, made all OS-es uninterested in WM_POWERBROADCAST and that it was a
reason why it worked at your place.

Best regards,
Slobodan

 

[=?ISO-8859-1?Q?Ulf_Jaenicke-R=F6=DFler?=]

I expected that with new minlogon that support power buttons this message will get consumed by minlogon handler.

I guess that these registry changes you set in the first place, made all OS-es uninterested in WM_POWERBROADCAST and that it was a
reason why it worked at your place.

After reading a bit in the SDK, this code, executed at specific moments or if
necessary, does the magic - also with the new Minlogon, btw:

BOOLEAN b;
UINT i;
GLOBAL_POWER_POLICY GlobalPowerPolicy;

b=ReadGlobalPwrPolicy(&GlobalPowerPolicy);
GlobalPowerPolicy.user.PowerButtonAc.Action=PowerActionShutdownOff;
GlobalPowerPolicy.user.PowerButtonAc.Flags=POWER_ACTION_QUERY_ALLOWED | POWER_ACTION_UI_ALLOWED;
GlobalPowerPolicy.user.PowerButtonAc.EventCode=0;

b=GetActivePwrScheme(&i);
b=SetActivePwrScheme(i,&GlobalPowerPolicy,NULL);

(Action became PowerActionNone and EventCode became POWER_USER_NOTIFY_SHUTDOWN,
although I'm unsure what the latter means. And yes, `b' is for error checking.)

Greetings
Ulf

 

[KM]

Hi Ulf,

The reason why I asked you about the PM settings were the policies.

Anyway, you have figured this already out with Slobodan (I slept the entire
conversation ).

Btw, I prefer calling CallNtPowerInformation(SystemPowerPolicyCurrent, ...),
in the SYSTEM_POWER_POLICY structure I change PowerButton field (flags that
you mentioned below).
But it does not really matter for you sicnce
WritePwrScheme/SetActivePwrScheme overwrite the policy scheme settings
anyway.

KM

 

[=?ISO-8859-1?Q?Ulf_Jaenicke-R=F6=DFler?=]

Btw, I prefer calling CallNtPowerInformation(SystemPowerPolicyCurrent, ...),

When I was glancing over CallNtPowerInformation I had the impression that
it does not store the settings, hence I would need to call SetActivePwrScheme
anyway if I want the setting changed permanently. Is this correct?

Greetings
Ulf

 

[KM]

Ulf,

Very good question...
Even though the documentation (MSDN) says the settings set through
CallNtPowerInformation are not persistent, they are persistent in some
cases. I haven't tested all the cases but in my tests the settings were
definitely persistent (registry settings, actually).

I considered that as a bug.

KM