App doesn't seem to be receiving resume message after hibernate

  • Thread starter Thread starter james
  • Start date Start date
J

james

I seem to be having the same problem that was posted in the thread
below, but there was no solution posted for it.
http://groups.google.com/group/micr...dowsxp.embedded&rnum=4&hl=en#8d509b2282a41690

My system is non-ACPI, using the Standard PC HAL with Windows Logon.
There is a launcher application that I open before putting the system
into hibernation. Upon return from hibernation, the application is
supposed to capture the WM_POWERBROADCAST PBT_APMRESUMEAUTOMATIC and
launch an executable. It works on the exact same system running XP Pro
(the device manager under "system devices" in XP Pro on that system
indicates that it is using the Standard PC HAL). Instead, nothing
happens until the mouse is moved or a keyboard key is pressed, then the
screen goes black for about a second, but nothing happens after that.

In the thread above, there was suspicion about the video driver, but
then he tried a new one only to get the same undesired results. I'm
thinking that maybe there's something missing from the OS. Or there is
a setting in the power meter control panel that I need to change. Has
anyone experienced anything like this and solved the problem?
 
Hi

I am the one who had the problem posted below. I never found a solution. I
got around this by using the system clock to tell if I came out of
hibernation. When entering the app I read system clock then loop and read
current time until two minute or greater, this gives me time to hibernate
while in the loop. I then fall thru to init code when current time is two
minutes greater then read time. Now when the system comes out of
hibernation and checks clock it is always more then two minutes difference
so it falls out of the loop right away. Not completely tested but seems to
work.

Jay
 
I found a work around to the problem, well at least on my system. When
implementing Hibernate Once Resume Many (HORM), the HORM documentation
says to put the system into hibernation using the command "xpepm
-hibernate". Instead, I found that when I put the system into
hibernation by pressing Start->Shutdown and then selecting "hibernate"
from the shutdown options, upon resume from hibernation, the "launcher"
app that I had open just before hibernating was able to detect the
powerbroadcast message upon resuming from hibernation and launch the
"main" application; the problem was solved. Apparently, putting the
system into hibernation using "xpepm -hibernate" is different than
putting it into hibernation via Start->Shutdown->Hibernate. Maybe
someone from Microsoft can determine exactly what the differences are
between the two methods of putting a system into hibernation. Something
else I had to do before putting the system into hibernation using
Start->Shutdown->Hibernate was get into the power options control panel
(powercfg.cpl), select the advanced tab, and uncheck "Prompt for
password when computer resumes from standby" to in order to supress a
logon screen upon resuming from hibernation.

While I'm on the subject of obscure issues that have potential to waste
time trying to figure out, I found something out about deploying an OS
image to the target device that might be worth mentioning. My typical
method for transferring all of the OS files from a development system
to a single-partitioned target system consisted of booting the target
to the WinPE CD, performing any needed preparation of the disk and
partition, mapping a drive letter to the network share on my dev system
containing the OS files using "net use ...", and then executing "xcopy
<source> <destination> /e /h", where the "/e /h" is supposed to direct
xcopy to copy hidden/system files and copy and preserve the directory
structure of the source directory on the destination. One of my remote
customers was having problems with every image that I built for him. I
would build an image, test it on the device in my office to make sure
that no errors occurred, and then upload the pre-FBA image (in a
compressed folder) onto an FTP site for him to download and deploy to
an identical device at his location. When he downloaded and deployed
the OS image and booted the system, he got some errors upon booting up,
and certain things that worked on my end wouldn't work on his end, such
as device manager and regsvr32.exe. I was not able to duplicate the
problems on my end. After combing through my TD configuration with a
fine-tooth comb to make sure that everything necessary was included, I
found out that he was downloading and extracting the OS image files
from the FTP site to a Windows 2000 system, and then deploying the OS
image files to the target device from the Win2k system using the WinPE
method that I was using on my end (I was doing it from my dev system
running XP Pro). As soon as he tried downloading, uncompressing, and
deploying the OS image from a Windows XP Professional system using
WinPE and xcopy, everything worked fine.

I just thought that it might be worth mentioning in case someone else
runs across this problem. I also read somewhere that there might be a
problem with xcopy not always working as expected (not copying every
single file), so robocopy should be used instead. I'm not sure if the
problem that my customer experienced was related to downloading and
uncompressing the image files using a Win2k system, or related to using
xcopy to transfer the files from a Win2k system to the device. I wasn't
able to see if robocopy got around the problem since I don't have a
Windows 2000 system and couldn't duplicate the problem on my end. Hope
this helps someone out there.

-Beau Cseri
bSquare Corporation
 
I found a work around to the problem, well at least on my system. When
implementing Hibernate Once Resume Many (HORM), the HORM documentation
says to put the system into hibernation using the command "xpepm
-hibernate". Instead, I found that when I put the system into
hibernation by pressing Start->Shutdown and then selecting "hibernate"
from the shutdown options, upon resume from hibernation, the "launcher"
app that I had open just before hibernating was able to detect the
powerbroadcast message upon resuming from hibernation and launch the
"main" application; the problem was solved. Apparently, putting the
system into hibernation using "xpepm -hibernate" is different than
putting it into hibernation via Start->Shutdown->Hibernate. Maybe
someone from Microsoft can determine exactly what the differences are
between the two methods of putting a system into hibernation. Something
else I had to do before putting the system into hibernation using
Start->Shutdown->Hibernate was get into the power options control panel
(powercfg.cpl), select the advanced tab, and uncheck "Prompt for
password when computer resumes from standby" to in order to supress a
logon screen upon resuming from hibernation.

While I'm on the subject of obscure issues that have potential to waste
time trying to figure out, I found something out about deploying an OS
image to the target device that might be worth mentioning. My typical
method for transferring all of the OS files from a development system
to a single-partitioned target system consisted of booting the target
to the WinPE CD, performing any needed preparation of the disk and
partition, mapping a drive letter to the network share on my dev system
containing the OS files using "net use ...", and then executing "xcopy
<source> <destination> /e /h", where the "/e /h" is supposed to direct
xcopy to copy hidden/system files and copy and preserve the directory
structure of the source directory on the destination. One of my remote
customers was having problems with every image that I built for him. I
would build an image, test it on the device in my office to make sure
that no errors occurred, and then upload the pre-FBA image (in a
compressed folder) onto an FTP site for him to download and deploy to
an identical device at his location. When he downloaded and deployed
the OS image and booted the system, he got some errors upon booting up,
and certain things that worked on my end wouldn't work on his end, such
as device manager and regsvr32.exe. I was not able to duplicate the
problems on my end. After combing through my TD configuration with a
fine-tooth comb to make sure that everything necessary was included, I
found out that he was downloading and extracting the OS image files
from the FTP site to a Windows 2000 system, and then deploying the OS
image files to the target device from the Win2k system using the WinPE
method that I was using on my end (I was doing it from my dev system
running XP Pro). As soon as he tried downloading, uncompressing, and
deploying the OS image from a Windows XP Professional system using
WinPE and xcopy, everything worked fine.

I just thought that it might be worth mentioning in case someone else
runs across this problem. I also read somewhere that there might be a
problem with xcopy not always working as expected (not copying every
single file), so robocopy should be used instead. I'm not sure if the
problem that my customer experienced was related to downloading and
uncompressing the image files using a Win2k system, or related to using
xcopy to transfer the files from a Win2k system to the device. I wasn't
able to see if robocopy got around the problem since I don't have a
Windows 2000 system and couldn't duplicate the problem on my end. Hope
this helps someone out there.

-Beau Cseri
bSquare Corporation
 
Back
Top