Where is GetThreadExecutionState?

jimc

unread,

Jun 26, 2008, 11:41:02 AM6/26/08

to

I am investigating a problem with many computers that refuse to sleep when
expected. We have investigated the problem and found that it is caused by an
unknown program calling SetThreadExecutionState(SYSTEM_REQUIRED). This most
often happens after a long user session BUT if the user logs out the flag
stays set forever.

You can use SetThreadExecutionState to set the execution state of the
current thread. This can be used to prevent the computer sleeping. You can
also use CallNTPowerInformation to GET the state for the entire system.

There doesn't seem to be a GetThreadExecutionState function. You can use
SetThreadExecutionState to determine the state for the current thread but
not for an arbitary thread/process.

Is there any way to find which process(s) are keeping the system awake by
finding the Execution State for a specific process/thread?

James

Kellie Fitton

unread,

Jun 26, 2008, 1:16:11 PM6/26/08

to

Hi,

Is your application processing the following Windows message:

WM_POWERBROADCAST

http://msdn.microsoft.com/en-us/library/aa373247(VS.85).aspx

Kellie.

jimc

unread,

Jun 27, 2008, 3:54:01 AM6/27/08

to

> Is your application processing the following Windows message:
>
> WM_POWERBROADCAST
>
> http://msdn.microsoft.com/en-us/library/aa373247(VS.85).aspx
>

Yes, I process WM_POWERBROADCAST. I MSDN documentation doesn't mention
anything about recieving messages when the SYSTEM_REQUIRED flag is set/unset
and I haven't noticed any messages during development. I think you may be
hinting that this message will tell me when the status changes - if it does,
how would it tell me which process had set/unset the flag?

James

Volodymyr M. Shcherbyna

unread,

Jun 27, 2008, 4:43:53 AM6/27/08

to

You can boot suspected machine in debug mode, attach WinDbg, set breakpoint
to SetThreadExecutionState and look at the call stack when it is being
called.

--
V.
This posting is provided "AS IS" with no warranties, and confers no
rights.
"jimc" <ji...@discussions.microsoft.com> wrote in message
news:C54554EB-2011-4507...@microsoft.com...

jim clark

unread,

Jun 27, 2008, 4:54:50 AM6/27/08

to

Thank you for the suggestion.

I'm not an expert with kernel debugging but I have used WinDbg on a local
machine to look at the EThread.PowerState field (which contains this
information). If there was a way to do this from user mode I think that
would be ideal.

However, I don't think setting a breakpoint would be that useful as I need
to know the cause of the problem *after* it has happened on a production
computer (that is in real-world use).

James

"Volodymyr M. Shcherbyna" <v_sch...@online.mvps.org> wrote in message
news:%23%23aD6HD2...@TK2MSFTNGP04.phx.gbl...

Volodymyr M. Shcherbyna

unread,

Jun 27, 2008, 5:23:06 AM6/27/08

to

"jim clark" <nospa...@ergo.co.uk-nospam> wrote in message
news:QT19k.86451$zs1....@newsfe28.ams2...
[...]

> However, I don't think setting a breakpoint would be that useful as I need
> to know the cause of the problem *after* it has happened on a production
> computer (that is in real-world use).
>
> James

Well, hopefully breakpoint will answer your main question: you will be able
to get the name of the process which is calling this function. If I type in
WinDbg:

bp 7C8392B5

(which sets bp to SetThreadExecutionState in XP SP2) and after the
breakpoint hit, just look at call stack, switch to caller and type:

0: kd> !process

PROCESS 81815810 SessionId: 0 Cid: 0ff8 Peb: 7ffde000 ParentCid: 0ff0
DirBase: 02940380 ObjectTable: e105ba30 HandleCount: 7.
Image: BADPROCESS.EXE
VadRoot 81db4650 Vads 20 Clone 0 Private 34. Modified 0. Locked 0.
DeviceMap e12d5230
Token e114fd48
ElapsedTime 00:00:00.031
UserTime 00:00:00.015
KernelTime 00:00:00.015
QuotaPoolUsage[PagedPool] 11452
QuotaPoolUsage[NonPagedPool] 800
Working Set Sizes (now,min,max) (147, 50, 345) (588KB, 200KB, 1380KB)
PeakWorkingSetSize 147
VirtualSize 5 Mb
PeakVirtualSize 5 Mb
PageFaultCount 140
MemoryPriority BACKGROUND
BasePriority 8
CommitCharge 42

THREAD 81eb37f0 Cid 0ff8.0ffc Teb: 7ffdd000 Win32Thread: 00000000
RUNNING on processor 0

For sure you can also debug the rest of the code and answer your further
questions.

jim clark

unread,

Jun 27, 2008, 6:03:54 AM6/27/08

to

Thank you. I will try this.

I guess there is no way of getting it easily from user mode?

James

"Volodymyr M. Shcherbyna" <v_sch...@online.mvps.org> wrote in message

news:Orhr0dD2...@TK2MSFTNGP02.phx.gbl...

Volodymyr M. Shcherbyna

unread,

Jun 27, 2008, 6:35:02 AM6/27/08

to

The reason I suggested to use WinDbg in remote debugging is because it can
set system wide breakpoints. You can use WinDbg to debug application, for
this you would need to attach to EACH application, and set breakpoint ... I
think this will be a waste of time.

--
V.
This posting is provided "AS IS" with no warranties, and confers no
rights.

"jim clark" <nospa...@ergo.co.uk-nospam> wrote in message

news:yU29k.82646$312....@newsfe12.ams2...