Done Add _powertime and _powercount to POWERMONITOR

[vefatica]

I'm trying to do some tricky timing (a few milliseconds) with POWERMONITOR. It would be useful at have a more accurate time of the event than what I can get in POWERMONITOR's command. Milliseconds would be nice.

And it would be nice if POWERMONITOR's command could display the count without digging it out of the output of POWERMONITOR.

 

[rconn]

Your desire for millisecond timing is not feasible, for a couple of reasons:

1. The thread that examines all of the monitoring requests only wakes up every 33 milliseconds, so you will never get any better resolution than that. (And if you have other monitors running, it can be significantly worse.)
2. POWERMONITOR is looking for PBT_* messages, which Windows does not prioritize.

Why are you trying to get millisecond timing on the power events?

 

[rconn]

Also unclear to me what "_powercount" means.

 

[vefatica]

_POWERCOUNT would be the current count of power events reported. That is, the same number as the "1" below.

Display      (1/FOREVER)   echo %_time - %_lastinput

Aren't you using RegisterPowerSettingNotification and getting notifications via WM_POWERBROADCAST? I was imagining the window process receiving those messages could get the time ASAP. Where does the 33 ms come in?

In a nutshell ... I use SendMessage(HWND_BROADCAST, WM_SYSCOMMAND, SC_MONITORPOWER, (LPARAM) 2) to turn off my monitors. 8-10 minutes later the monitors come on; input of unknown origin is generated and some combination of these is started: RuntimeBroker, AppXSvc, wuauserv, WaaSMedicSvc. I can get the process/service start times accurately with WMI but I can't get an accurate time of the input event. The best I can do is to use _TIME in POWERMONITOR's <command>. Getting the time as soon as TCC receives the power event would be better.

Ultimately, I want to figure out where the mysterious input is coming from and (more important) stop it from happening.

 

[rconn]

_POWERCOUNT would be the current count of power events reported. That is, the same number as the "1" below.

Display      (1/FOREVER)   echo %_time - %_lastinput

Aren't you using RegisterPowerSettingNotification and getting notifications via WM_POWERBROADCAST? I was imagining the window process receiving those messages could get the time ASAP. Where does the 33 ms come in?

In a nutshell ... I use SendMessage(HWND_BROADCAST, WM_SYSCOMMAND, SC_MONITORPOWER, (LPARAM) 2) to turn off my monitors. 8-10 minutes later the monitors come on; input of unknown origin is generated and some combination of these is started: RuntimeBroker, AppXSvc, wuauserv, WaaSMedicSvc. I can get the process/service start times accurately with WMI but I can't get an accurate time of the input event. The best I can do is to use _TIME in POWERMONITOR's <command>. Getting the time as soon as TCC receives the power event would be better.

Ultimately, I want to figure out where the mysterious input is coming from and (more important) stop it from happening.

You are not going to get the time as soon as TCC receives the power event. The event monitoring thread only wakes up and looks for events every 33 ms. So you might get really lucky and get the time a few ms after the event occurred, or if you're unlucky 33ms + the time it took for Windows to send the message. Average times would be between 20 - 100ms, so anything less than .1 second resolution and you're just fooling yourself. I don't think you can get any better resolution than just using _TIME in the POWERMONITOR command.

IMO your _POWERCOUNT wouldn't tell you anything useful - just that you had some number of power events since the last time you looked at it. There's no way of knowing what they were without examining each event. How is that helpful?

 

[vefatica]

I don't understand "event monitoring thread". Whose thread is that? And why does it look for events only every 33 seconds?

 

[rconn]

I don't understand "event monitoring thread". Whose thread is that? And why does it look for events only every 33 seconds?

TCC creates a single thread that handles all of the monitoring commands (events, devices, registry, file system, clipboard, services, yada yada). If it tried to handle them in the main thread, you wouldn't get any monitoring events when TCC was executing an internal command. The thread wakes up once every 33 milliseconds (not every 33 seconds), because the beta testers (that's you) complained that it was slowing things down and using too much CPU when it ran more frequently (or when I tried using a thread per monitor command).

If the hypothetical _POWERCOUNT was > 1, then _POWERTIME would be meaningless, as it would only give you the time of the most recent power message. What you're really asking for here is to have POWERMONITOR return an array. That's a breaking change.

 

[vefatica]

If the hypothetical _POWERCOUNT was > 1, then _POWERTIME would be meaningless, as it would only give you the time of the most recent power message. What you're really asking for here is to have POWERMONITOR return an array. That's a breaking change.

Again, I don't understand. The time of the most recent power event is exactly what I want.

I don't see that it's related at all to (a hypothetical) _POWERCOUNT. As for _POWERCOUNT, I can do it. If you did it that'd save me/us some work.

v:\> powermonitor Display forever `set _powercount=%@inc[%_powercount] & echo %_powercount^t%_time - %_lastinput`

1   16:19:54 - 67
2   16:20:00 - 1463
3   16:20:20 - 7