Display Power Management

[glorp]

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

I used SetThreadExecutionState() in JkDefrag, but it has some problems and does not work in all cases.

If you can't track it down as an alternative I'd like to be able to avoid having MyD change any power management options at all as an option.

That's exactly what the PreventPowerSaving setting is for.

Jeroen,

Thanks for your reply. I started a new thread about this so as not to hijack the other one. I realize the PreventPowerSaving function is supposed to accomplish this but it didn't seem to work for me as expected. I'm using a slightly customized variant of the FastOptimize script and calling it from Task Manager overnight. As a test I let it run automatically last night after removing all PreventPowerSaving and ScreenSave calls from my custom script and also from your "Settings" script. That worked. Display power management still functions as set originally after the run. So I just have a couple of questions:

You call PreventPowerSaving(yes) in Settings.MyD from every one of your included scripts. So what re-enables Power Saving settings when any of your scripts terminates? Do you read current power management settings before any script processing begins then restore them on exit no matter what PreventPowerSaving calls are made in between? The call to PreventPowerSaving in the Settings script would permanently disable power management anytime someone runs any standard script otherwise.

What happens if a script abnormally terminates or is killed by task scheduler because it runs too long or by a user in Task Manager? What restores power management settings in cases like that? I suspect this may have been the cause of some problems for me.

I do really like the scriptability of the new version.

Thanks.

[jeroen]

Do you read current power management settings before any script processing begins then restore them on exit no matter what PreventPowerSaving calls are made in between?

Yes, that's exactly what the program does. The PreventPowerSaving() command in a script does not read the value again, it only restores the setting to the original value (just like on program exit), or set's it to zero (just like at the beginning of the program). I have now added a test and the program will not set or restore the setting if it is already off. I doubt if it will help, but it will be in the next version and we will see.

What happens if a script abnormally terminates or is killed by task scheduler because it runs too long or by a user in Task Manager?

Then MyDefrag does not get a chance to restore the setting. I asked about this exact possibility in the other thread, but the reply was that the program had never been abnormally terminated or killed.

[Jamin4u]

Hello, 

glorp, were you logged on when you ran MyDefrag overnight.  If not, logging on this morning may have reset the setting.

The reason I ask is that I did the same as you by removing all PreventPowerSaving() entry's from Fast Optimize and the settings script's and it didn't work for me.

I ran Fast Optimize, Fast Update and Analyze only and they all took out the setting. (No Task Manager)

jeroen, is it possible that something else in the settings script or the script interpreter is causing this?

Anyway, I'm getting out of my league here so I will bow out of this unless you have any more questions for me.

Thank you!

[glorp]

@Jamin4u: I *was* logged in as an Administrative account (Vista x86) all night on the computer as the defrag ran. I call the script as a scheduled task from Task Scheduler though so it is not running in my logged on desktop context. When all PreventPowerSaving (and also *all* PreventScreenSaver) calls had been removed from amy possible script or subscript, my PM settings had not changed after the run. I have run a second test overnight (also me logged in) this time with the PreventPowerSaving(yes) call back in "Settings" (still no PreventScreenSaver calls anywhere) and all seems normal. But I have been at the computer continuously today so I haven't had a chance to see if the display shuts off when expected. I'll report back in a few hours after I've given up typing for a while 

I really suspect for me it was a case of aborting MyD while I was developing the custom script I used. I had a few syntax errors and that caused some crashes that may have turned off PM permanently. I imagine this will not be an uncommon problem.

If it will help I can try to see if I can replicate any conditions you have and test. It's a slow process since I find it's best to do my normal, once-per-day defrag runs and then wait to see what happens with the PM rather than try to force testing cases.

[glorp]

The second test case did not affect my PM settings either. I had one PreventPowerSaving(yes) command in the "Settings" file and after the nightly defrag the monitor still shut off as expected after use today. I think it was just the crashes I experienced during the initial script set up that got me.

Thanks.

[glorp]

I'm afraid I was premature with that last message. The bug is very real but it's stranger than I realized. After adding back the single PreventPowerSaving(yes) to the "Settings" file and then having MyDefrag run as a scheduled task the logged in user's power management behaved normally the *first* time. The display came out of power off when the mouse was moved first thing this morning and then went back off after an hour inactivity. I brought it out of the second power off state later and now it *won't* turn off the display again after the required inactivity time.

Some observations:
- I haven't touched the power plan settings for 2 days. I looked at them just now in Control Panel to see how they were set. They had not been changed. Still shows display power off set to 1 hour inactivity but that's no longer being honored.

- Computer hasn't been booted for over 2 days.

- I've been logged in on desktop as the same user for over 2 days nows. No logouts. Logged in as an account with admin privledges. The defrag process runs as a different user (the local SYSTEM user account -- highly privledged).

- I don't have any calls to PreventScreenSaver in any script(s) in case it matters, and the screen saver is disabled for the login account and always has been.

- There really hasn't been anything else that I can think of that would affect PM settings installed or run.

If I can answer any questions or test something for you to try and track it down further I'd be more than happy to.


Regards.

[jeroen]

If I can answer any questions or test something for you to try and track it down further I'd be more than happy to.

Thank you very much for your kind offer, I appreciate it. I think the problem is abundantly demonstrated now, no use doing further tests. Let's wait for the next release and see if the changes have helped.

[glorp]

It looks like v4.1 solved the problem. I wanted to test it for a couple of days/runs and from what I see the monitor is powering on/off as expected per my Power Management plan settings. Great job Jeroen. Thanks for the fix!

I do have one question/comment that I'm not sure was obvious from before but seems clearer to me now. Here is the very end of my .debuglog from my last defrag run:

02:30:03 Finished VolumeSelect.
02:30:03 Finished with disk D:
02:30:03 Executing rule: <Statements> ::=
02:30:03 Finished executing the script.
02:30:03 Resetting ScreenSaverTimeout to 600

The very last line resets the ScreenSaverTimeout to 600 (which I assume is 600 seconds or 10 minutes?) I just wanted to point out that this value isn't what I have set as either the screen saver delay time or the monitor power off time in power management for the logged in desktop user when this script runs. I mentioned before that I run this script from a scheduled task using a different security context than the one I use to log in with and I'd bet that's the screen saver delay for that account. My point is that I think you have to consider account context when you start disabling screen savers which are configurable "Per User". Probably not Power Saving features though since I think those would have to be "Per Machine". It seems like the exe ought to take a look at the context in which it's running before it even tries to manipulate screen saver times. If it's not running with access as a desktop user, disabling/reenabling the screen saver (and possibly power management) may get you into trouble. Just a thought.

Thanks again for a great program.

[jeroen]

It looks like v4.1 solved the problem.

Excellent! Thanks for testing and the feedback, I appreciate it.

It seems like the exe ought to take a look at the context in which it's running before it even tries to manipulate screen saver times.

I think the Windows system call that I am using (SystemParametersInfo(SPI_GETSCREENSAVETIMEOUT)) takes care of that, as your own test with 600 demonstrates. But it's a good point and if anybody reports a problem then I will know where to look.