PRB:No Power Events after booting from HORM

[Guest]

I was receiving SERVICE_CONTROL_POWEREVENT on an older SBC. For this SBC we
were emulating PS/2 keyboard commands so keyboard driver would normally load
and after the system came out of HORM we would receive the
SERVICE_CONTROL_POWEREVENT (both PBT_APMRESUMEAUTOMATIC and
PBT_APMRESUMESUSPEND). We now have a new SBC and are not emulating keyboard,
so we don't have keyboard or mouse. So it's a "headless" type system except
we don't use the headless VGA component as we have a video card. If I
connect the keyboard and mouse to the new SBC and allow it to create the HORM
image and then re-boot, I get the SERVICE_CONTROL_POWEREVENT but not until I
move the mouse or hit a key. I know that PBT_APMRESUMESUSPEND shouldn't be
received until XPE thinks the user is "present", but how come I don't get any
SERVICE_CONTROL_POWEREVENT. I'm at least expecting PBT_APMRESUMEAUTOMATIC.
I wanted to install the NULL keyboard or mouse driver to fake out XPE
thinking there is always a user present but they have been removed (hidden to
0 in Target Designer for SP2). I get the SERVICE_CONTROL_POWEREVENT for
standby just not from resume from hibernate. Any one have any ideas why I do
not get the SERVICE_CONTROL_POWEREVENT? I've tried a Windows App with
WM_POWERBROADCAST and running at the time the HORM is created but when the
system starts I don't get that message either.

Info.
WinLogon
Disk based EWF
XPE SP 2
Service uses RegisterServiceCtrlHandlerEx & SERVICE_ACCEPT_POWEREVENT is
set.
Using "Advanced Configuration and Power Interface (ACPI) PC". SBC is started
from ACPI power button.
BIOS Settings: "ACPI Suspend Type"=S1&S3 "Power Management"=ACPI

Thanks for any help. Michael

 

[KM]

Michael,

This very issue has been discussed in this thread:
http://groups.google.com/group/micr...d/browse_thread/thread/d280c1e8c1aa1f1b?hl=en

I don't think we came up with a fix that time, though.

Also, I remember someone mentioning in the newsgroup that there was a difference in behavior of the system (getting power broadcast
messages in apps) depending on the way how you put it in the hibernated state. If you used Explorer's Hibernate item - everything
seemed to work fine, if you used a command line tool (like xpepm or fba -hibernate) the bug as you reported was showing up.

The only workaround I can suggest is for you to implement a logic in your app where you'd know if you are coming out of the resume
automatically (HORM) or else. Give is a try with API like IsSystemResumeAutomatic.

 

[Guest]

Yeah I found that thread. I guess I expected it to be different because he
was handling WM_POWERBROADCAST. And since it's an application and Windows
Message notification I would expect that he wouldn't get notified until XPE
actually thought there was a user present (mouse movement or keyboard
activity). Running as a Windows Service and support of headless type systems
with XPE, I would expect the OS to be able handle no keyboard, no mouse and
notify the service of the power event.

Thanks, Michael

 

[KM]

Michael,

The bug, in my understanding and please correct me if I am wrong here, is that sometimes PBT_APMRESUMEAUTOMATIC event gets lost on
embedded images at resume from hibernated state. However, the PBT_APMRESUMESUSPEND is always there. Unfortunately, the
PBT_APMRESUMESUSPEND only gets sent if the system detects user activity (documented behaviour of this event). To gather more details
about the issue you may want to check if after the PBT_APMRESUMESUSPEND you are still getting the PBT_APMRESUMEAUTOMATIC (with mouse
or keyboard plugged-in , of course). These events may be showing up out of sequence because of some hardware related timing issues.
It won't help you much in fixing or working around the issue but it will certainly help Microsoft folks if they are going to fix the
issue on XP(e).

I'd love to say the story is different for service vs app but it doesn't seem so. At least on XP where a service is just a bit
different type of application controlled and utilizing service API provided by the SCM (talking about user mode service here). [On
Vista some things have been fixed in that domain since services are launched in a separate window session there now. There you can
definitely call user mode service as a special "type of execution"]

I think what may be happening behind the scene is that SCM just parses the WM_POWERBROADCAST message and sends the
SERVICE_CONTROL_POWEREVENT down to all running services. My point is that if the bug is there for WM_POWERBROADCAST, it is likely
there for SERVICE_CONTROL_POWEREVENT as well.
It may also be possible that the kernel, while handling PnP power notifications, has an exception for SCM and sends the
PBT_APMRESUMEAUTOMATIC event on resume to SCM that dispatches it to all the services (or sent directly to all services who's
registred for accepting power events).Just in case I'd suggest you to check if you have the umpnpmgr library and WMI Win32 Provider
component in your image.

Btw, it this all is a timing issue then the bug should probably be less reproducible on the same hardware running XP Pro. Did you
try XP Pro on the same SBC?
Sorry, can't be of much help here.