. wrote:

Applications can mark their threads as not idle. This is how Media Player
disables the screensaver while playing video.

Can you point me to some Microsoft documentation on the ability of a program
to defeat the screensaver timeout? I've been chasing a problem for which
that sounds like the explanation for some time (involving unattended systems
not going into screenlock), and getting nothing useful from Microsoft.

Is it possible to have a (privileged, of course) program scan the active
user-context threads and turn off the "force not-idle" setting?

Joe Morris

On Mon, 8 Mar 2010 07:00:16 +0530, witan wrote:

"Steven L." wrote in message
m...


"Gene E. Bloch" wrote in message
:

On Thu, 4 Mar 2010 19:42:34 -0500, GSalisbury wrote:

"The Learner" wrote in message
...
I have an HP laptop using Vista SP-2. Until recently, the power
settings
worked the way I set them (especially shutting off the display after
15
minutes of idle time). Now, this particular setting doesn't work (the
display stays on all the time). I haven't checked the other settings
yet. Tried Google but couldn't find anything that applied.
Suggestions
for a solution?

Control Panel / Power Options

Did you notice that he has already set the power options, but that they
recently stopped working?

I would be glad to offer a suggestion to the OP, but I often have the
same
problem (not consistently, unfortunately) and haven't solved it.

I have a thought that the Windows Search Indexer is implicated, but I'm
not
sure. And previously I had a wireless mouse & keyboard that added a
reproducible 5 minute delay to the Screen Saver and Screen Dark
timeouts...The new KB & mouse don't have that problem. Weird...

Another thing that's implicated is Windows Update.

If you have your computer set to automatically download updates from
Microsoft (whether or not you choose to automatically install them),
Windows Update seems to wake up the computer out of a sound sleep to
accept the new Updates onto its hard drive.

And yet another thing that's implicated are some virus checkers. Norton,
in particular, uses idle time to scan for malware and cookies. It will
wake up the computer to accomplish this.



-- Steven L.




I have been having the same problem, on and off. It seems to have something
to do with applications that are running. If all applications are minimized,
the screensaver does kick in after the set time.

However, both in 7 and earlier versions of Windows, I got to see my bubbles
moving in front of open app windows. It's only recently that the screen
saver has been rejecting me (sob!).

I should look into other apps, though. For example, I recently installed a
system tray app to show when CapsLock, etc, are on -- I got tired of not
realizing my wireless keyboard, which lacks indicator lights, had CapsLock
on...Maybe it's too talkative :-)

Earlier this afternoon I just turned off the Indexer Service. That's my
current experiment. I'll look into the CapsLock app if that fails.

Re another suggestion: I have Windows set only to notify when updates are
available; my downloading and installing are both manual. Others here might
want to look into that setting, though.

--
Gene E. Bloch letters0x40blochg0x2Ecom

On Mon, 8 Mar 2010 07:00:16 +0530, witan wrote:

"Steven L." wrote in message
m...


"Gene E. Bloch" wrote in message
:

On Thu, 4 Mar 2010 19:42:34 -0500, GSalisbury wrote:

"The Learner" wrote in message
...
I have an HP laptop using Vista SP-2. Until recently, the power
settings
worked the way I set them (especially shutting off the display after
15
minutes of idle time). Now, this particular setting doesn't work (the
display stays on all the time). I haven't checked the other settings
yet. Tried Google but couldn't find anything that applied.
Suggestions
for a solution?

Control Panel / Power Options

Did you notice that he has already set the power options, but that they
recently stopped working?

I would be glad to offer a suggestion to the OP, but I often have the
same
problem (not consistently, unfortunately) and haven't solved it.

I have a thought that the Windows Search Indexer is implicated, but I'm
not
sure. And previously I had a wireless mouse & keyboard that added a
reproducible 5 minute delay to the Screen Saver and Screen Dark
timeouts...The new KB & mouse don't have that problem. Weird...

Another thing that's implicated is Windows Update.

If you have your computer set to automatically download updates from
Microsoft (whether or not you choose to automatically install them),
Windows Update seems to wake up the computer out of a sound sleep to
accept the new Updates onto its hard drive.

And yet another thing that's implicated are some virus checkers. Norton,
in particular, uses idle time to scan for malware and cookies. It will
wake up the computer to accomplish this.



-- Steven L.




I have been having the same problem, on and off. It seems to have something
to do with applications that are running. If all applications are minimized,
the screensaver does kick in after the set time.

However, both in 7 and earlier versions of Windows, I got to see my bubbles
moving in front of open app windows. It's only recently that the screen
saver has been rejecting me (sob!).

I should look into other apps, though. For example, I recently installed a
system tray app to show when CapsLock, etc, are on -- I got tired of not
realizing my wireless keyboard, which lacks indicator lights, had CapsLock
on...Maybe it's too talkative :-)

Earlier this afternoon I just turned off the Indexer Service. That's my
current experiment. I'll look into the CapsLock app if that fails.

Re another suggestion: I have Windows set only to notify when updates are
available; my downloading and installing are both manual. Others here might
want to look into that setting, though.

--
Gene E. Bloch letters0x40blochg0x2Ecom

SetThreadExecutionState

Enables applications to inform the system that it is in use, thereby
preventing the system from entering the sleeping power state or turning off
the display while the application is running.


EXECUTION_STATE SetThreadExecutionState(
EXECUTION_STATE esFlags
);

Parameters
esFlags
[in] The thread's execution requirements. This parameter can be one or more
of the following values. Value Meaning
ES_CONTINUOUS
0x80000000 Informs the system that the state being set should remain in
effect until the next call that uses ES_CONTINUOUS and one of the other
state flags is cleared.
ES_DISPLAY_REQUIRED
0x00000002 Forces the display to be on by resetting the display idle timer.
ES_SYSTEM_REQUIRED
0x00000001 Forces the system to be in the working state by resetting the
system idle timer.

Return Value
If the function succeeds, the return value is the previous thread execution
state.

If the function fails, the return value is NULL.

Remarks
Activities that are automatically detected include local keyboard or mouse
input, server activity, and changing window focus. Activities that are not
automatically detected include disk or CPU activity and video display.

Calling SetThreadExecutionState without ES_CONTINUOUS simply resets the idle
timer; to keep the display or system in the working state, the thread must
call SetThreadExecutionState periodically.

To run properly on a power-managed computer, applications such as fax
servers, answering machines, backup agents, and network management
applications must use ES_SYSTEM_REQUIRED | ES_CONTINUOUS when they process
events. Multimedia applications, such as video players and presentation
applications, must use ES_DISPLAY_REQUIRED when they display video for long
periods of time without user input. Applications such as word processors,
spreadsheets, browsers, and games do not need to call
SetThreadExecutionState.

The SetThreadExecutionState function cannot be used to prevent the user from
putting the computer in standby mode. Applications should respect that the
user expects a certain behavior when they close the lid on their laptop or
press the power button.

This function does not stop the screen saver from executing either.



--
..
--
"Joe Morris" wrote in message
...
. wrote:

Applications can mark their threads as not idle. This is how Media Player
disables the screensaver while playing video.

Can you point me to some Microsoft documentation on the ability of a
program to defeat the screensaver timeout? I've been chasing a problem
for which that sounds like the explanation for some time (involving
unattended systems not going into screenlock), and getting nothing useful
from Microsoft.

Is it possible to have a (privileged, of course) program scan the active
user-context threads and turn off the "force not-idle" setting?

Joe Morris

SetThreadExecutionState

Enables applications to inform the system that it is in use, thereby
preventing the system from entering the sleeping power state or turning off
the display while the application is running.


EXECUTION_STATE SetThreadExecutionState(
EXECUTION_STATE esFlags
);

Parameters
esFlags
[in] The thread's execution requirements. This parameter can be one or more
of the following values. Value Meaning
ES_CONTINUOUS
0x80000000 Informs the system that the state being set should remain in
effect until the next call that uses ES_CONTINUOUS and one of the other
state flags is cleared.
ES_DISPLAY_REQUIRED
0x00000002 Forces the display to be on by resetting the display idle timer.
ES_SYSTEM_REQUIRED
0x00000001 Forces the system to be in the working state by resetting the
system idle timer.

Return Value
If the function succeeds, the return value is the previous thread execution
state.

If the function fails, the return value is NULL.

Remarks
Activities that are automatically detected include local keyboard or mouse
input, server activity, and changing window focus. Activities that are not
automatically detected include disk or CPU activity and video display.

Calling SetThreadExecutionState without ES_CONTINUOUS simply resets the idle
timer; to keep the display or system in the working state, the thread must
call SetThreadExecutionState periodically.

To run properly on a power-managed computer, applications such as fax
servers, answering machines, backup agents, and network management
applications must use ES_SYSTEM_REQUIRED | ES_CONTINUOUS when they process
events. Multimedia applications, such as video players and presentation
applications, must use ES_DISPLAY_REQUIRED when they display video for long
periods of time without user input. Applications such as word processors,
spreadsheets, browsers, and games do not need to call
SetThreadExecutionState.

The SetThreadExecutionState function cannot be used to prevent the user from
putting the computer in standby mode. Applications should respect that the
user expects a certain behavior when they close the lid on their laptop or
press the power button.

This function does not stop the screen saver from executing either.



--
..
--
"Joe Morris" wrote in message
...
. wrote:

Applications can mark their threads as not idle. This is how Media Player
disables the screensaver while playing video.

Can you point me to some Microsoft documentation on the ability of a
program to defeat the screensaver timeout? I've been chasing a problem
for which that sounds like the explanation for some time (involving
unattended systems not going into screenlock), and getting nothing useful
from Microsoft.

Is it possible to have a (privileged, of course) program scan the active
user-context threads and turn off the "force not-idle" setting?

Joe Morris

SetThreadExecutionState controls the request for uninterrupted service for
the thread in which the call occurs. My problem is that I want to be able
to be able to override the use of ES_SYSTEM_REQUIRED by any application in
the machine.

The problem is occurring with computers that are located in meeting rooms.
We're using the WINEXIT screensaver to provide a deadman timer; killing the
user's session after a relatively short idle time reduces the security
exposure created if someone logs on to use the computer, then leaves the
room without logging off. The sticking point is that some applications that
are frequently used in meetings (PowerPoint is the poster child) disable the
system idle timer. What I would like to find is an API through which I can
do something to prevent any application from defeating the screensaver
timer. I would prefer to do it using a published API but might consider
(reluctantly, and only if necessary) front-ending the API and quietly
ignoring the call.

Yes, I know this isn't a programming NG but I was hoping that someone had a
magic answer for me. Thanks anyway for taking time to respond!

Joe

. wrote:

SetThreadExecutionState

Enables applications to inform the system that it is in use, thereby
preventing the system from entering the sleeping power state or turning
off the display while the application is running.

EXECUTION_STATE SetThreadExecutionState(
EXECUTION_STATE esFlags
);

[...]
ES_SYSTEM_REQUIRED
0x00000001 Forces the system to be in the working state by resetting the
system idle timer.
[...]


"Joe Morris" wrote:
. wrote:

Applications can mark their threads as not idle. This is how Media
Player disables the screensaver while playing video.

Can you point me to some Microsoft documentation on the ability of a
program to defeat the screensaver timeout? I've been chasing a problem
for which that sounds like the explanation for some time (involving
unattended systems not going into screenlock), and getting nothing useful
from Microsoft.

Is it possible to have a (privileged, of course) program scan the active
user-context threads and turn off the "force not-idle" setting?

SetThreadExecutionState controls the request for uninterrupted service for
the thread in which the call occurs. My problem is that I want to be able
to be able to override the use of ES_SYSTEM_REQUIRED by any application in
the machine.

The problem is occurring with computers that are located in meeting rooms.
We're using the WINEXIT screensaver to provide a deadman timer; killing the
user's session after a relatively short idle time reduces the security
exposure created if someone logs on to use the computer, then leaves the
room without logging off. The sticking point is that some applications that
are frequently used in meetings (PowerPoint is the poster child) disable the
system idle timer. What I would like to find is an API through which I can
do something to prevent any application from defeating the screensaver
timer. I would prefer to do it using a published API but might consider
(reluctantly, and only if necessary) front-ending the API and quietly
ignoring the call.

Yes, I know this isn't a programming NG but I was hoping that someone had a
magic answer for me. Thanks anyway for taking time to respond!

Joe

. wrote:

SetThreadExecutionState

Enables applications to inform the system that it is in use, thereby
preventing the system from entering the sleeping power state or turning
off the display while the application is running.

EXECUTION_STATE SetThreadExecutionState(
EXECUTION_STATE esFlags
);

[...]
ES_SYSTEM_REQUIRED
0x00000001 Forces the system to be in the working state by resetting the
system idle timer.
[...]


"Joe Morris" wrote:
. wrote:

Applications can mark their threads as not idle. This is how Media
Player disables the screensaver while playing video.

Can you point me to some Microsoft documentation on the ability of a
program to defeat the screensaver timeout? I've been chasing a problem
for which that sounds like the explanation for some time (involving
unattended systems not going into screenlock), and getting nothing useful
from Microsoft.

Is it possible to have a (privileged, of course) program scan the active
user-context threads and turn off the "force not-idle" setting?

Not that I know of.

--
..
--
"Joe Morris" wrote in message
...
SetThreadExecutionState controls the request for uninterrupted service for
the thread in which the call occurs. My problem is that I want to be able
to be able to override the use of ES_SYSTEM_REQUIRED by any application in
the machine.

The problem is occurring with computers that are located in meeting rooms.
We're using the WINEXIT screensaver to provide a deadman timer; killing
the user's session after a relatively short idle time reduces the security
exposure created if someone logs on to use the computer, then leaves the
room without logging off. The sticking point is that some applications
that are frequently used in meetings (PowerPoint is the poster child)
disable the system idle timer. What I would like to find is an API
through which I can do something to prevent any application from
defeating the screensaver timer. I would prefer to do it using a
published API but might consider (reluctantly, and only if necessary)
front-ending the API and quietly ignoring the call.

Yes, I know this isn't a programming NG but I was hoping that someone had
a magic answer for me. Thanks anyway for taking time to respond!

Joe

. wrote:

SetThreadExecutionState

Enables applications to inform the system that it is in use, thereby
preventing the system from entering the sleeping power state or turning
off the display while the application is running.

EXECUTION_STATE SetThreadExecutionState(
EXECUTION_STATE esFlags
);

[...]
ES_SYSTEM_REQUIRED
0x00000001 Forces the system to be in the working state by resetting the
system idle timer.
[...]


"Joe Morris" wrote:
. wrote:

Applications can mark their threads as not idle. This is how Media
Player disables the screensaver while playing video.

Can you point me to some Microsoft documentation on the ability of a
program to defeat the screensaver timeout? I've been chasing a problem
for which that sounds like the explanation for some time (involving
unattended systems not going into screenlock), and getting nothing
useful from Microsoft.

Is it possible to have a (privileged, of course) program scan the active
user-context threads and turn off the "force not-idle" setting?

Not that I know of.

--
..
--
"Joe Morris" wrote in message
...
SetThreadExecutionState controls the request for uninterrupted service for
the thread in which the call occurs. My problem is that I want to be able
to be able to override the use of ES_SYSTEM_REQUIRED by any application in
the machine.

The problem is occurring with computers that are located in meeting rooms.
We're using the WINEXIT screensaver to provide a deadman timer; killing
the user's session after a relatively short idle time reduces the security
exposure created if someone logs on to use the computer, then leaves the
room without logging off. The sticking point is that some applications
that are frequently used in meetings (PowerPoint is the poster child)
disable the system idle timer. What I would like to find is an API
through which I can do something to prevent any application from
defeating the screensaver timer. I would prefer to do it using a
published API but might consider (reluctantly, and only if necessary)
front-ending the API and quietly ignoring the call.

Yes, I know this isn't a programming NG but I was hoping that someone had
a magic answer for me. Thanks anyway for taking time to respond!

Joe

. wrote:

SetThreadExecutionState

Enables applications to inform the system that it is in use, thereby
preventing the system from entering the sleeping power state or turning
off the display while the application is running.

EXECUTION_STATE SetThreadExecutionState(
EXECUTION_STATE esFlags
);

[...]
ES_SYSTEM_REQUIRED
0x00000001 Forces the system to be in the working state by resetting the
system idle timer.
[...]


"Joe Morris" wrote:
. wrote:

Applications can mark their threads as not idle. This is how Media
Player disables the screensaver while playing video.

Can you point me to some Microsoft documentation on the ability of a
program to defeat the screensaver timeout? I've been chasing a problem
for which that sounds like the explanation for some time (involving
unattended systems not going into screenlock), and getting nothing
useful from Microsoft.

Is it possible to have a (privileged, of course) program scan the active
user-context threads and turn off the "force not-idle" setting?