One of the issues I am investigating for a fix relates to the auto-suspend feature in Windows. The way it’s supposed to work is you set a time in the Power control panel (Control Panel –> Performance and Maintenance –> Power Options) that controls how long the computer waits until it goes into “standby” or “suspend”. Whether that is S2 or S3 depends on your BIOS settings. What’s going on with the bug I’m looking at is sometimes Windows will not suspend when it should, or indeed, ever, unless you close Media Center or manually select Standby.
This is pretty annoying, especially since my Media Center consumes about 200W while fully active (250-275W if engaged in HDTV playback), and only about 15W in S3 suspend. With electricity around $0.084 / kWh, that works out to $0.40 each day left unchecked. If I let it go all month, that’s another $12, just because of this stupid bug (well, and because I’m lazy and forget to manually suspend… but I should not have to). Lame, lame, lame. Extrapolating to all of the customers affected by this issue, I can see it adding up to a big problem. Say only 250,000 users hit this (a low figure, I bet), that’s $3,000,000 per month in wasted energy costs, based on the rates I pay. Yikes!
While I can fix this problem, I cannot fix all of the things that prevent computers from going into standby automatically, because they should really not be fixed, or because Windows software is not causing the problem in the first place. Several things can cause a computer to fail to go into standby, and figuring out exactly what is causing the problem can be very difficult.
So, what are the most common causes of Windows insomnia? In rough order of likelihood, here is my SWAG:
- There is user activity. This usually means keyboard or mouse activity, but can be “simulated” by applications via SendKeys(), etc.
- Windows is not configured to go into Standby automatically. Since it’s not the default for most computers, this makes the list. Easy to fix.
- An application tells Windows not to go into Standby automatically. Different from user activity simulation because this is what applications are supposed to do to prevent Standby. [ SetThreadExecutionState(state) ]
- An application generates enough system activity (e.g. disk access, network access, CPU usage) that Windows does not consider the machine to be “idle” enough.
- A hardware device driver prevents it.
Case 1 is very unlikely, since really the only applications that do this sort of thing are hacks/trainers/evil programs (and testing programs, if you want a legitimate example). Unless your computer is infected by malware, this is probably not the cause. Run a quality scanner to tell. For case 2, just set Control Panel setting.
For cases 3 and 4, troubleshooting gets trickier. For the average end-user who does not know how to use a Kernel Debugger like WinDbg or SoftICE, and does not have easy access to kernel symbols, figuring out who is keeping the computer up all night takes a little wanton process termination. Before you open up taskmgr and start gunning processes, though, there are a couple of things you can check:
- Are you sharing any folders on the network? If a remote computer is connected to your machine and refreshes the connection (i.e. sends a command), the Server service will call KeInhibitSystemShutdown(), which does exactly what it sounds like it does: resets the system’s idle timer. How do you tell if this is happening? An easy way is to pull up a command window (Start –> Run –> cmd) and type:
If you see any “IN” connections, they can keep you awake. Most well-behaved Windows applications will not needlessly refresh connections over the network, but others don’t play that nicely. A ubiquitous example would be WMP or iTunes–both will scan network folders for changes if you add the path to your “watched folders” list. The best way to solve this problem is to fix the client side (the other computer), but if that’s not possible, you can just deny access to that computer/user. In the worst case, you can stop the Server service (net stop server), but that prevents sharing altogether.
- Check your Application and System event logs for errors or warnings. Often, exceptional situations will be reported there and can provide a clue to why Windows is not going into Standby.
- Hardware (or more appropriately, drivers for hardware) can prevent Windows from entering standby, too. If you used to be able to go into standby, but cannot now, have you added or replaced hardware, or updated drivers? This can be tricky, too, since most people set their Standby timers for longer than is convenient to sit around and wait on, so failure to go into Standby can be missed for days or weeks.
- To eliminate any remote networking cause, isolate your computer from the network (unplug the network cable!). Low-tech, but effective.
If you have eliminated network shares, suspicious event log entries, and hardware from causing the problem, the next thing to do is start killing processes and see which one (or if you’re unlucky, which ones) are doing it. You need to first exclude those processes that are part of Windows itself, since terminating them is not very wise. An easy way to get a fairly complete list of the Windows processes is to boot into Safe Mode, press Start –> Run, and type:
A new file will be created on your system drive (usually C:) that contains the list of processes you shouldn’t touch. Reboot back into normal Windows mode, log in, and:
- Open the SysProcesses.txt file
- Start taskmgr (right click on the taskbar and select Task Manager) and click the Processes tab.
- Set your Standby timer to 1 minute (in the Power Options control panel)
- Let 1 minute elapse. If the computer does not suspend, proceed to the next step.
- Select a process not listed in the SysProcesses.txt file in taskmgr and kill it.
- Go to step 4.
If you run out of processes to kill and the computer still won’t go into Standby, it’s time to start shutting down services in the Services console (Start –> Run –> services.msc). If you have stopped all of the services you possibly can, it’s either a piece of hardware or one of the core Windows processes, and things are a bit tougher. To troubleshoot those, you need the help of a kernel-mode debugger.