Sleep mode & Power Saver

[Jeremy Collake]

@bertie97: Yes, I struggled with this presentation myself, and had planned to revisit it. You are right, it needs reformed, as it can be confusing.

The two BASIC levels of sleep that get prevented are:
1. Full sleep  (Prevent PC from sleeping)
2. Display sleep   (Prevent display(s) from sleeping)

This will likely change at some point in its presentation, though I'm not sure yet into what form. There is so much to do, I just do as much as I can per day

[bertie97]

OK, now I get it, I was looking at the dialog from the 'other perspective' - ie I want to select to
- keep PC & display awake
- allow display to sleep

Whereas as a disciplined programmer you are trying to keep it in syntax with the heading statement - prevent 'x'  ..prevent sleep, only display/nothing to enter sleep state. .. at least thats what it looks like to me.. 

Main thing is it's working 

[bertie97]

It appears the recent update to beta 6.x.46 has knocked out the prevent sleep function.  Will play around a little & see if it comes back if I re-enter the progs concerned to a cleared dialog.
I notice that adding a prog to display only also adds  whole PC on the line below when I OK & close the dialog.  ie - on my return it has appeared in the list.  Maybe this is intentional but it is a bit puzzling to me
If I del that entry it comes back after I close the dialog.  This is a bit like opening the fridge door to see if the light is still on.... 

Will report back if clearing the dialog completely resets things.

---Hmm it won't let me delete the old entries - I remove, then they reappear after I close & reopen the dialog.  I now will wait & see if the no-sleep becomes active for the new (tho duplicate) entry.
---Killed the old entries in the .ini - now they aren't returning, obviously the dialog wasn't updating the ini for removal of entries. 
Now to see if sleep occurs....

[bertie97]

Prevent sleep didn't work.
Now I've updated to beta x.50 so will let you know of any changes. (x64 on W7x64 btw)

[bertie97]

Now at  beta x.53 & things are working.  & I would say generally this build feels less "clunky" in how it's working behind the scenes. 

Don't know why people get angry about beta errors, that is what a beta is about - fault finding & an opportunity to share in the creative process.
I don't mind a few bugs if it means I get to see a better product at the end. 
Writing code isn't the easiest thing in the world & logic rarely wins against some of the bugs I've seen over the years. 

Update -
No sleep is not working for me (it was in x.51) 

[BenYeeHua]

Now at  beta x.53 & things are working.  & I would say generally this build feels less "clunky" in how it's working behind the scenes. 

Don't know why people get angry about beta errors, that is what a beta is about - fault finding & an opportunity to share in the creative process.
I don't mind a few bugs if it means I get to see a better product at the end. 
Writing code isn't the easiest thing in the world & logic rarely wins against some of the bug I've seen over the years. 

Ya, found a bug in beta is better than found a bug in stable build 
And improving the produce is more harder, a little change will cause more problem coming to developers.

[bertie97]

I'm now up to x.59 & it appears that no sleep is active again 
However it also keeps the monitor on when set to allow monitor to sleep. 
I guess Windows Power management just will not surrender without a fight!   

Now to test Game mode 

[Jeremy Collake]

Thanks Bertie, I will take a look at it. Programmatically, it should be 'surrendering', so I'm not sure what the deal may be - yet. I will figure it out.

[bertie97]

Ya, found a bug in beta is better than found a bug in stable build 
And improving the produce is more harder, a little change will cause more problem coming to developers.

If only all developers agreed with you.   
Very many buggy products released with endless & huge patches in the game industry for example. 
Guess you just have to learn to be patient... 

[Jeremy Collake]

FWIW, PC environments are complex and chaotic. Users have installed all sorts of software on all sorts of editions of Windows on all sorts of hardware. It is like a jungle ;p. Some minidumps I've analyzed had 10 different third-party DLLs injected into my processes! (note: Process Lasso NEVER injects DLLs).

[BenYeeHua]

If only all developers agreed with you.   
Very many buggy products released with endless & huge patches in the game industry for example. 
Guess you just have to learn to be patient... 

Okey, as I saying is some known big bugs that will affect the normal use of the software(or os).
Just like using the software and bang!
BSOD, crash...... 
----
And the core parking(ProBalance) have some issues, if the ProBalance is restrain, and the update running and end the PL, after the update is finish, they will found that the core parking is changed to 100%.
Maybe the updater need the function that make sure the ProBalance is stopped, so that it will not causing the issues like this.
----
Correction about core parking.
It still 100% after the ProBalance restrain...(by using ParkControl to checking it)
And it will affect power consumption/temp on having >4 core when idle even after disable/uninstall PL.
----
Correction again 
Checked with Resource Monitor, the core still remain parking when ProBalance restrain, using ParkControl to checking it, but it still showing 100%(and after restrain also)
Bug on ParkControl(with showing wrong, but working correctly when click apply) and ProBalance, or ProBalance only disable core parking with logical core, but not "fake" core?

[Jeremy Collake]

Showing 100% of the minimum cores that must remain unparked, you mean?

ProBalance's setting to optionally disable CPU Parking is hopefully working correctly, but please report if not. I did test it and it seemed to be fine. The *one area* where I have concern is on hardware that does not support CPU parking. In these cases, there is nothing to disable, and nothing to enable - thus the user may be confused as to why it doesn't get 'enabled' by ParkControl. Detecting these situations is on the agenda for the future, though they will become less common by then - ironically. Most who would want to disable core parking surely have it .

Sorry to hear about the BSOD, but the one thing I can say for sure is that Process Lasso has no kernel mode code, so can't generate BSODs . (most of this written for people reading, as you already know) These are normally driver issues, as I'm sure you know, but can sometimes end up being overheating or voltage irregularities that cause an error in the computational function of your PC (e.g. RAM error or CPU error), inducing a crash. That's a big reason they added the new 'RAM Tester' in Windows Vista and above, which will reboot your PC and do a pre-boot check of your RAM. It is a good PC stability tester. Once you know your PC is stable, then you have to take a hard look at every kernel mode component, including your security suite.

[bertie97]

FWIW, PC environments are complex and chaotic. Users have installed all sorts of software on all sorts of editions of Windows on all sorts of hardware. It is like a jungle ;p. Some minidumps I've analyzed had 10 different third-party DLLs injected into my processes! (note: Process Lasso NEVER injects DLLs).

I sometimes wonder how anyone gets anything to work.  It is a minefield & there are some dubious configs out there.  Unfortunately for devs relatively few people realize this or will tolerate the new product not working... 
Then there are some releases that are just obeying some ill-advised management & give the coders no chance to fully debug etc.

Personally, I would like to see (some) devs & MS Win give better error reports to help identify what is happening.  Often there isn't even a starting point for an end-user.  Just a CTD or whatever.
Not that any of this applies to PL of course.   

[Jeremy Collake]

Well, we/I do have minidumps to use, but sometimes these are surprisingly unhelpful. What happens is if you get stack corruption, or have an invalid path of execution, the call stack gets totally corrupted and the minidump is near useless. However, they are good at identifying *some* obvious errors. Problem is, most errors aren't obvious, lol. Also, when the error is in third-party code, there isn't much you can do about it, even if you can track down their error. Often times I have to work around third party problems. Oh well ;o.

[bertie97]

Well bitsum.support ------- That is the quixotic life of the code warrior! 

On the power front I found pre- x.62 the PC wouldn't sleep at all if a process was in the no-sleep list, whether it was allow display or not.
Now running x.62 & the PC sleeps regardless.

I bet you are glad you started this now! 

[BenYeeHua]

Showing 100% of the minimum cores that must remain unparked, you mean?

ProBalance's setting to optionally disable CPU Parking is hopefully working correctly, but please report if not. I did test it and it seemed to be fine. The *one area* where I have concern is on hardware that does not support CPU parking. In these cases, there is nothing to disable, and nothing to enable - thus the user may be confused as to why it doesn't get 'enabled' by ParkControl. Detecting these situations is on the agenda for the future, though they will become less common by then - ironically. Most who would want to disable core parking surely have it .

Having a i3-2330m on Asus K43SJ.
Yes, tested and it don't work, but the ParkControl is showing 100% of the minimum cores that must remain unparked when the Probalance restraint the process, and it still showing 100% after restraint.(But apply it by using ParkControl is without problem)
But after having a window 7 restart, or changing the power plan(switch to another and switch back), the CPU Parking is disable.
Just like the os not re-read the CPU Parking setting and set it correctly.
Don't know it is matter of Power4Gear Hybrid or not.

So I have disable the function to disable CPU Parking as only the fake core are parked.

Sorry for reply late, as I normally using the function up there(Show unread posts since last visit.) and it not showing this post(and some new post too...)

[bertie97]

Do you have any media player active by chance? I apologize if I already asked this.

No, just a program I use for downloads that since the new mobo isn't recognised by Win7 as a function that needs an awake PC.   
PL had totally fixed that & when u intro'd the 'allow the display to sleep' I was in PM nirvana. 

Now somehow it's all back to 'normal' - ie win does what it wants regardless. 

Games however do not allow sleep, & when the Steam stuff is updating it seems to be OK, though nothing has been over 10 mins to download yet...
& as a side-note - the overall gaming response & feel of the PC is now better than it has been, so #6 is certainly making a difference in positive ways.

[Jeremy Collake]

Glad the code base of version 6 is generally good - it should be to be honest. Lots of improvements were made that the user doesn't see. Sadly, some minor cosmetic errors here and there in the first build or two were probably more noticeable than all the countless hours of internal code refactoring. BUT, that's life .

[EDIT - truncated for future readers]

[bertie97]

The 'Prevent  (i.e. allow ) Display Sleep' entry alone = sleep. 
I added an extra 'prevent whole PC' to the list & the whole PC has remained awake with no attempt to shut anything down.  Power management profile switching has occurred correctly.
I thus imagine that the 'prevent display' process is broken.  It did work previously as I noted above in the x.5x builds.

The .log shows power profile switch & priority throttling etc.  No errors appear to be present.  However the addition of  the 2nd entry for the same .exe, has show this -

Code Select Expand

29-07-2012 18:42:44.017,B-PC,B,tired.exe,8012,Entering 'Prevent Display Sleep' mode,This process is configured to prevent the display(s) from sleeping.,"C:\Program Files (x86)\tired\tired.exe"
29-07-2012 18:42:48.089,B-PC,B,tired.exe,8012,Sleep prevention continues,A sleep preventing process ended? but other sleep preventing processes are still running.,"C:\Program Files (x86)\tired\tired.exe"
29-07-2012 18:43:06.340,B-PC,B,tired.exe,6056,Sleep prevention continues,A sleep preventing process ended? but other sleep preventing processes are still running.,"C:\Program Files (x86)\tired\tired.exe"
29-07-2012 18:43:06.356,B-PC,B,tired.exe,6900,Leaving no sleep mode,The PC is now allowed to sleep when set to.,"C:\Program Files (x86)\tired\tired.exe"

It seems that for some reason the display setting permitted sleep but the presence of the additional Prevent sleep for whole PCcommand caught the lapse.  No red stop lights so far that I have noticed.
HTH

[Jeremy Collake]

Thanks Bertie! That is what I needed to know. Don't worry about those duplicate log entries (some same messages for both types of prevent sleep), that was just me being lazy (with all the translations and all).

I will do more research and testing ASAP.

[bertie97]

Just updated to x.64 so I will see how it's looking in the ongoing war on Win PM 
I really like the right-click function on these PM settings btw.
I found I needed to manually edit the ini for the no sleep processes (ie removal of entries).

You have plenty of vital stuff to do so without nagging in any way (!) I notice that dialogs & docs still refer to 'disallow display to sleep' as opposed to allow only display to sleep. 
Not a problem really but a reminder as it may be confusing to newcomers.   
Should be a straightforward SAR for you I guess.   

[Jeremy Collake]

Ok, I think I've figured out the confusion ... it was my fault in the implementation, AND my fault in not communicating effectively. The GOOD news is that it *is* working like it is supposed to (I believe).

1. In context menu, I made it an either/or operation, but it should be a consolidated option - BOTH should be allowed on the same process.
    In fact, they are BOTH allowed on the same process in the configuration dialog, and in the rules - just not shown in the checkboxes.
2. The message I show on EITHER is that the 'PC' will not be allowed to sleep - this causes confusion.

I will fix this up in .66 (the next final).

To summarize things I've attached a picture of the Windows Power Options for a Power Profile. The Display's Timeout is what is affected by this new option.

(regarding attached screenshot of Windows Power Profile options in Windows 7)
- Prevent Display from Sleeping perpetually resets the TOP sleep timer. (Display Sleep Timeout)
- Prevent Whole PC from Sleeping perpetually resets the BOTH sleep timers. (PC Sleep Timeout)

[Jeremy Collake]

I trimmed some messages, edited my last one, and will add this to the documentation - along with the cleanup in the next build. Does it makes sense now and behave as you would expect it to, given this new information? Granted, if I checked something that said 'don't let my displays sleep' and then my PC slept, turning off my displays, I'd be confused too! So, again, it is my fault in not making this distinction clear. In fact, whether the prevent displays from sleeping is even generally useful, I don't know, but its there now - so ...

[bertie97]

I believe that it is now working as you outline above so thanks for looking at all this.
But....
Originally  I had wanted to prevent the PC from sleeping whilst running some processes Win7 didn't think were important enough to stay awake for; When you added this function I wondered if would be possible to keep the box awake but let the monitor(s) sleep.
You implemented this & I had my perfect PM setup.   
Then in the Beta run this functionality broke.

Somewhere along the line the allow monitor to sleep but keep the box awake has switched to keep monitors awake even if box is asleep.  Which as you rightly say is something of a questionable option.

Is that a logical assessment from your perspective?   

[Jeremy Collake]

Originally  I had wanted to prevent the PC from sleeping whilst running some processes Win7 didn't think were important enough to stay awake for; When you added this function I wondered if would be possible to keep the box awake but let the monitor(s) sleep.
You implemented this & I had my perfect PM setup.   

Ah, I think I see you needed the *inverse* of what I actually offered. Now we are finally beginning to get on the same page. I am sorry, for some reason we've had communication problems, likely my fault. Note that I never implemented anything like that, so it was probably an illusion that any build did that.

This would require a third power option, "Let displays sleep, but keep PC awake". Which is why you were talking about the grammar in the inverse way. I just didn't 'get' what you needed I suppose.

Good news, is *is* possible. I can keep your PC awake, but let your displays sleep. That is the *only* other function possible, so might as well add it. The fourth combination would be impossible (keep display awake, let PC sleep).

So, I will see what I can do.. I'll add it to a beta or test build and let you see if it does what you want . It would be 'Allow displays to sleep, but prevent PC from sleeping'.

[Jeremy Collake]

How about this (finally I get your message ;p)?

[Jeremy Collake]

Somewhere along the line the allow monitor to sleep but keep the box awake has switched to keep monitors awake even if box is asleep.  Which as you rightly say is something of a questionable option.

And I never implemented this, so want to correct this statement. Whilst confused about what you wanted (maybe because of the v6 final pressure and haste), this obviously makes no sense ;p. Now, keeping the displays from sleeping UNTIL the PC is set to sleep might be useful to *somebody*, so I will keep it. See screenshot in previous message for early development of new (and last) anti-sleep option. I think I FINALLY have you covered.

I very much apologize for miscommunicating. I just didn't get what you want, maybe skimmed.. But, you politely beat it into my head, and I thank you for that

[Jeremy Collake]

I have also fixed the bug that prevented removal of these settings from within the anti-sleep configuration dialog. Thanks again Bertie!

Fix is in v6.0.0.69 beta and above.

[bertie97]

Sorry for giving you all this extra work!!! 

I am sure the excitement with the important core components of v6 were responsible for the miscommunication.  I know PM isn't what PL is fundamentally about, but this feature does solve a huge irritation (for me at least ).

Looking at how you have had to apply some lateral logic in the implementation of this gives one an indication of the reason why it would be easy to go off on a different tack.  Windows loves being illogical & it wants everyone to follow suit! 

I can see that the net result is some useful PM options, for which I am very grateful (& I expect I will not be the only one!)
I look forward to trying them out when they are ready. 
Thanks for the allocation of your time to this during a busy period in PLs life-cycle.

[Jeremy Collake]

It is no problem, and I actually feel really bad for misunderstanding what you wanted. I am always so overwhelmed, taking time to slow down is important - as this demonstrates.

Also, I wish I could say I had finished implementation in .69 beta, but I just worked on the GUI .. the next final should FINALLY have you the feature you need .

[Jeremy Collake]

Implementation now complete in core engine. Still needs tested, but just an update. Not yet released.

[Jeremy Collake]

I am still working (so much to do it is unreal) so have NOT yet tested or reviewed the code, but TEST builds are here:

32-bit: http://bitsum.com/files/test/prolasso.zip
64-bit: http://bitsum.com/files/test/prolasso64.zip

I am going to try to stay awake all night and finish the new final if possible, or get very close to it.

[bertie97]

You realize that all this implies your personal power management may need tweaking now, (i.e. body clock-wise) 
I know what you mean about sticking with it tho, sometimes sleeping kills the focus. 
- Win7 (& possibly 8 ) take note!

I did the upgrade to .71 & noticed the dialog entries had changed (allow display to sleep keep PC awake had appeared) then when I reopened the dialog that entry had disappeared.  To the point where I thought I'd imagined it.   
It is now back to the Keep display awake or keep PC awake format....

I guess I should get some screen recording s/w so at least I can prove to myself I hadn't imagined it.
Could this be ini related?    Maybe I'll try a clean install...

Thanks again for the effort on this.  Everything is feeling much smoother with these 6.x builds. 

***

Update -
I decided to completely uninstall/reinstall, (& I am happy to say the process went smoothly & my key was revalidated without any issues.).
I had saved the old ini before nuking it all so I have been able to compare the 2 files.
I have found the AllowDisplaysPreventPC wasn't a mirage.   
It will no longer appear in the PL GUI however.  With all files & logs erased that is a bit of a puzzle because I obviously did see it the very first time I opened the dialog.... 
I find that manually editing the ini allows the feature to be displayed in the GUI No Sleep dialog.
But only until I close it, the next time I open it the display has reverted to the old statement 'prevent display'. 
Closing the dialog at this point returns the ini entry to the display= .exe from the AllowDisplaysPreventPC= .exe setting.
(Hope that is a clear description!)

So I have manually added my exe's to the necessary point in the ini & will see how it works if I avoid opening the no sleep dialog. 

I have not completely merged the old & new ini's so I will be playing around with it a bit more now & will report back. 

[edkiefer]

So if you right click on a process you don't see 3 options now with .71beta ?

I have not tested but see these in the pop up menu .

[bertie97]

The right click function is there it is the selection via the configure no sleep dialog (Via Options->) that I am referring to.
Sorry I should have specified that the selections are present in that RC option. 
I was totally focused on the behaviour outlined above & watching the ini change... 

[Jeremy Collake]

Now all fixed up and operating correctly, here is what it will look like in the FINAL I'm about to issue in a few hours .... My big regret is obviously not having this right on v6 final. It was a quick addition and I paid more attention to the process context menu items than anything else. This will be in (most likely) v6.0.0.74 final.

The caption is a bit 'off', but I likely won't correct it this build because of the translations.

As for the setting in the INI file - Yes, it doesn't appear until it is used. For better or worse, this is how it was designed. I can change it if desired. Many settings are like that.

[Jeremy Collake]

Note during code review I fixed a bug in this last beta pointed out by Ed - the dialog could save the type of sleep wrong. This will be fixed in the final I'm about to issue.

[bertie97]

Note during code review I fixed a bug in this last beta pointed out by Ed - the dialog could save the type of sleep wrong. This will be fixed in the final I'm about to issue.

pointed out by Ed      You mean it wasn't me watching the ini update itself mysteriously throughout those long hours?  Damn PL mirages!

Actually it is kinda funny I got hooked by the Dialog behaviour when I find the RMB functions so cool now....
The ini processing is fine & it is logical in operation esp. when one is watching it!  Made it easier to follow that the ''bug' was dialog & not Right-Click related.

Currently (.73) the GUI still likes to juggle the setting but now it's only the dialog which seems to displays a wrong text value, the actual ini remains ok & RC shows the 'check' in the correct position.
All seems to function as I require so I am happy that it was able to be resolved. 
& I will be playing watch the dialog again shortly 

Given this is a late 'bolt-on' rather than part of the core PL theatre of operations, I'd say the time-frame of the extra debugging etc has been good.  & I can't see this as being an issue when so much else is good.

If anything this little debacle' has instilled greater confidence in your product & your ability as far as I am concerned.

[Jeremy Collake]

Currently (.73) the GUI still likes to juggle the setting but now it's only the dialog which seems to displays a wrong text value, the actual ini remains ok & RC shows the 'check' in the correct position.

Yep, that was exactly the bug Bertie .

I'm glad it has instilled more confidence. Honestly, there are a lot of developers who are more concerned about image than they are about functionality. I mean, they will 'deny, deny, deny', then quietly fix ;p. Myself, I may go too far in the other direction at times - lol. I am very happy you brought this whole thing to my attention because it *finally* delivers what was promised in version 6 - improvements of the No Sleep controls. Many XP users use these I'm sure as the automated power profile management is not available in anything below Vista (Microsoft rewrote the entire power management subsystem, so I made a decision to support only the newer rendition).

Anyway, I have made some last minute changes to some Vista+ related code so am having to do lots of new testing here, but still anticipate the final to come here in a few hours or sooner. As soon as I get these new changes just right (they involve Process Lasso's self-restart on elevation configuration changes).

[Jeremy Collake]

Everything should be good in the final now issued, but if there is a problem, don't hesitate to let me know. Likewise, if it all goes well, then that's great too . I did make those string adjustments at the last minute, but tested them decently - so everything *should* be good.

[Tarnak]

I have read this thread from the beginning, but I don't get it.

I am on XP, and I don't see any benefit in using this feature for me.

I have a desktop which runs 24 hrs, and when I go to bed at night, I just switch of the monitor.

So, forgive me if this a dumb post.

P.S. I missed the v.6.0.0.75 beta, it must have been shortlived.

[bertie97]

Things are behaving as I would like them to now.  Thanks for all the coding! 
No more swearing at the monitor for being on or cursing at the box for being off!   

I have read this thread from the beginning, but I don't get it.

A lot of Win7 users have PM issues (Like me) where the PM doesn't do what it should & refuses to recognize/obey certain processes.
If you actually don't want (or need) PM then you won't need these features. 

But like a lot of things within PL, this provides options.
That is something Win can be terribly short of....

[bertie97]

Decided to resurrect this thread as it seems pertinent (...to me at least!) 

Just found 6.5.0.0 is showing the anti sleep process activating & shutting down but it won't allow the monitor to sleep with the disallow PC allow monitor sleep setting.
I am going to experiment a bit with regular full sleep just in case the issue is a bit more widespread.  i.e. all my anti-sleep settings may be knocked out...

[bertie97]

Looks like PM works normally but PLs allow display to sleep function is acting as a full stay awake option.
No sleep of any kind is allowed in this state. 

[bertie97]

Trying 6.5.0.5b & my display does sleep yet.

[Jeremy Collake]

thanks, I will evaluate this and respond.

[bertie97]

Now on 6.5.0.11b - no change - system will sleep but monitor ill not respond to the monitor only sleep instruction.
The whole system stays awake when selected processes are running.  So it's positive but no cigar.
I see you changed the tags on the settings drop-down.  Nearly had me confused ... 

[Jeremy Collake]

Now on 6.5.0.11b - no change - system will sleep but monitor ill not respond to the monitor only sleep instruction.
The whole system stays awake when selected processes are running.  So it's positive but no cigar.
I see you changed the tags on the settings drop-down.  Nearly had me confused ... 

Yes, I'm still evaluating this issue, and am in the process of changing those strings to something more comprehensible. I should have some news on this very soon.

[Jeremy Collake]

I have determined the problem and patched it up. The fix will be in v6.5.0.13 beta and later.

[bertie97]

OK thanks for your diligence