Win7: "Hibernate" Scheduled Task Runs Even When Missed

January 5, 2011 5:32 AM

I have, to aid in not permitting myself to stay up too late, set Windows 7's Task Scheduler to automatically hibernate at a certain time in the evening that varies according to weekday. However, if I manually hibernate the system beforehand (i.e., go to sleep earlier than the deadline), when I wake it the next morning, it hibernates shortly thereafter. However, importantly, I do not have the "Run task as soon as a scheduled start is missed" checkbox turned on. I've seen this, but Richard's suggestion of only letting the task run after a certain idle period – I don't think it'd be suitable as I don't want activity (either mine or the computer's) to be able to push things past the deadline. Any ideas as to what I can do?
posted by WCityMike to computers & internet (10 answers total)

I don't know how to fix this behavior from your computer. Instead, couldn't you just not hibernate the computer early? How early could it possibly be? An hour or two? The power savings and safety/longevity of your computer won't be that significant unless you're running a really high-power workstation.

Of course, if you have jet-engine level fans or a million LEDs on your case, and the case is right next to your bed, that wouldn't work out, and you should ignore this comment. Also ignore if it does turn out to be an easy fix.
posted by supercres at 5:50 AM on January 5, 2011

If it is of any help, I successfully used GFI Backup to hybernate, and WakeupOnStandBy to wake my PC up for quite some time now. For some reason, trying GFI backup for waking up was not too reliable, hence the combo (I do not have Windows 7; both of the apps are free).
posted by Jurate at 6:00 AM on January 5, 2011

Can't you just set it to automatically hibernate after x minutes of inactivity? That's what I do.
posted by empath at 6:25 AM on January 5, 2011

Hopefully some Windows batch file guru will show up. I have no Windows batch file skills. What I would try: Write a batch file that checks if the hardware clock time == system clock time, if so, hibernate. Assuming your link describes the situation correctly.

If the script is set to run at 9pm, and when run the hardware clock and the system clock both say it's 9pm then it hibernates.

If the script is run in the morning after you manually hibernated early, the script sees that the hardware clock says 6am but the system clock says 9pm and the script does nothing.

This is assuming your link is correct in it's explanation of how Windows sorta runs the system clock really fast after waking up from hibernation to get the system clock to jive with the hardware clock.

On the big picture level, your machine just knows the CMOS clock time, the system clock, and maybe network clock if available. Those are likely the only pieces of information you can use to determine if now is really now. (Unless Windows has some sort of 'hey clock is not syncronized' bit that you can check).
posted by zengargoyle at 6:26 AM on January 5, 2011

What happens if, when you go to sleep early, instead of manually hibernating you run the hibernation task?

empath: "Can't you just set it to automatically hibernate after x minutes of inactivity? That's what I do"

Er, did you read the post?

WCityMike:"to aid in not permitting myself to stay up too late"

" I don't want activity (either mine or the computer's) to be able to push things past the deadline"
posted by turkeyphant at 8:00 AM on January 5, 2011

I don't know about the hardware clock vs system clock thing but you could write some vbscript which prevents the computer from shutting down if it is earlier than, say, 5pm.

Save the following (untested code, sorry) as "shutdown.vbs":

Option Explicit
Dim oShell
Set oShell = WScript.CreateObject ("WScript.Shell")

' Don't shutdown if the hour is less than 17:00 (5pm)
If Hour(Now()) < 17 Then WScript.Quit

' Run the shutdown command with whatever options you want
oShell.Run "shutdown /s"
Set oShell = Nothing


Then set up Windows Task Scheduler to run this instead of your shutdown command. If you want it to not shut down before 8pm then use 20 instead of 17 in the code.
posted by mr_silver at 8:02 AM on January 5, 2011

Not to not answer the question, but is there some reason you couldn't set your account as a "user" account and enable parental controls ? The parental controls allow you fix logon/logout times and are really easy to get around if you need to for some important reason and have admin privs.

Anyway, the machine will cheerfully log you out at the designated time and not let you back in until the time you set. No need for funny mucking about with the hibernating.
posted by Pogo_Fuzzybutt at 11:44 AM on January 5, 2011

Although there were a lot of useful suggestions in this thread, and I thank everyone for them, I think implementing mr_silver's script may end up the best solution for me. (Although I did have to swap in shutdown /h, since shutdown /s evidently is a shutdown proper and not a hibernation.)
posted by WCityMike at 8:39 PM on January 5, 2011

WCityMike: I really wan't to know if the script actually works. If it does then Widows / Tesk Scheduler is broken or confused. I expect it not to work.

script is set to run at 18:00.
manually hibernate computer at 16:30.
awaken computer at 06:00.
when awoken, system clock is still at 16:30 and is sped up (think like moving the minute hand of a clock around and around) until it matches the actual time as retrieved from the hardware clock.

system clock goes: 16:30, 16:31, 16:32, .. 17:59, 18:00, (script runs), 18:01, ... 06:00 (stop running fast, now system clock == hardware clock).

When the script runs, it will think that it's running at 18:00, the Now() function is going to return 18:00, the script will go ahead and hibernate since 18>17.

In general this is how clock adjustments are done on running systems. It's usually bad to reset the clock 'hard' say going from 16:30 -> 06:00 and skipping the times in-between. Any running process that had timeouts, or anything else scheduled to happen during that period would just break. This isn't a hard set rule, but just a generally accepted problem avoidance method, i.e. "don't do that please".

The only time you should do a 'hard' setting of the system clock is on power-on boot early in the process before other programs are started. Usually this happens in the kernel or soon after boot. (in the old days before hardware clocks when you booted a PC the first thing you would get would be a prompt to set the date and time manually). Once running, the clock is kept by the running kernal, not the hardware clock. (the kernel clock is much more precise than the hardware clock).

The same thing goes on when you synchronize to a network time source, NTP or GPS for example. The computer fetches the time and slowly changes the system clock to match the reference time instead of doing a 'hard' setting of the system clock.

And a final bit of weirdness, usually the kernel actually resets the hardware clock to the system clock on shutdown. Especially if you've been using network time. This is because network/kernel time is just so much better than the CMOS hardware clock. You can think of the hardware clock like a really throw away digital watch. It has your basic M/D/Y and H:M:S and does leap-year, but that's it. No milli/micro seconds, drifts seconds or more per year, subject to poor quality crystals and dead batteries. It's just there to keep a rough sense of time when the system is turned off or woken up from hibernation.

I suspect you might get around Task Scheduler weirdness by using one-shot schedule instead of recurring schedule (this might be what the "Run task as soon as a scheduled start is missed" checkbox controls.

Run this script M-F 18:00 every day, every year (recurring)
Run this script at 01/07/2011 18:00 (one-shot)

Really this is a complex issue. The difference between shutting down and restarting; running slowly on reduced power; and suspending state for later resume is a big deal when you factor in real world time vs system time.
posted by zengargoyle at 4:15 AM on January 6, 2011

Well, it appears that this "problem" may have only been a problem in a very limited context -- namely, when I hibernate my computer very shortly before it would've automatically hibernated. In alternate situations, i think it has the opportunity for its system clock to "catch up" to what the current time is, and thus not trigger.

Either that, or, alternatively, the solution offered by mr_silver does appear to be working.

In any case, thank you to everyone who offered solutions and opinions in this thread; I appreciate them.
posted by WCityMike at 4:51 AM on January 18, 2011