Steve Glendinning

One of the features of Vista that I really like is it’s “sleep”.  Unlike XP, which usually used S1 sleep, Vista puts the system into the much lower power S3 state.  On my Core2Quad workstation, this takes the power usage down to 3W (from ~62W running at idle).  To put this into perspective, the power usage when the system is fully shut down is ~2W, but wakeup is MUCH quicker than a full boot.

Vista allows you to configure which hardware sources can wake up the system from sleep, so for example you can enable or disable Wake On Lan.  It also allows software to schedule a wakeup, and Media Centre is one such beast.  Ever since I started playing with Media Centre, the system has randomly woken up from sleep (and not returned to sleep afterwards), which kinda defeats the purpose of sleep!

It’s quite easy to find out the source of the most recent wakeup (powercfg /lastwake), but this lists all software sources as “RTC”.  It doesn’t identify *which* process (or scheduled task) was responsible.

I found one solution over at thegreenbutton (thanks to mxcrowe):

If you do this, your computer will not auto-wake for any reason (s/w reason - I suppose WOL etc. will still work).  This info was given to me by another poster here on the Green Button:

1. Open a CMD prompt
2. powercfg -setacvalueindex scheme_current sub_sleep bd3b718a-0680-4d9d-8ab2-e1d2b4ac806d 0
3. powercfg -setdcvalueindex scheme_current sub_sleep bd3b718a-0680-4d9d-8ab2-e1d2b4ac806d 0
4. powercfg -setactive scheme_current

This changes and applies a new power scheme that stops the machine from being woken from sleep. In my case, I have a desktop system and probably didn’t need to set the DC option, but I did both anyway.

I finally managed to get to the bottom of my vista blue screen problem, so I thought I’d share how I determined which driver was causing the problems.

Vista keeps a log of application and kernel crashes in Control Panel -> Problems Reports and Solutions -> View problem history:

Double clicking on the latest Windows “shut down unexpectedly” shows the blue screen details. These don’t give much useful information, for example which driver was responsible:

Clicking on “View a temporary copy of these files” opens an explorer window with the crash dump file, which you can copy to your own directory.

To analyse the crash dump you’ll need to install the Microsoft Windows Debugging Tools (17MB msi).  This adds a whole set of command line tools under “C:\Program Files\Debugging Tools for Windows (x86)”.  Use the dumpchk.exe tool to analyse the crash file:

And there’s the culprit: “Probably caused by: eacfilt.sys”.  This is the driver used by Nortel’s Contivity VPN client.  I’m using the “vista friendly” version, which worked fine before I applied Vista SP1, but I guess SP1 broke its driver.  The solution to all my problems? Uninstall it!

Hurrah! My T61’s suspend and hibernate work again!

Since installing service pack 1 on Vista, my shiny new laptop (Thinkpad T61) has a problem coming out of a hibernated or suspended state. When resuming from hibernation or suspend it’ll give me the BAD_POOL_CALLER error (and automatically reboot) roughly 50% of the time. It’s so bad I’ve stopped using hibernate and suspend entirely.

I found a solution on the lenovo forum, apparently the T61’s UPEK fingerprint reader driver 1.9.2.99 can be responsible. I’ve installed version 1.9.2.111 (download directly from UPEK), but I still get blue screens if I hibernate.

Other drivers known to be incompatible with SP1 are listed on Microsoft KB 948343, but I’m pretty sure I’m not running any of them. Any ideas?

Update (16th May 2008): The problem turned out to be Nortel’s Contivity VPN client.  They don’t appear to have released an updated version since SP1 was released.  I no longer have a need for this VPN client, so I simply uninstalled it.  Problem solved!

While I was trying to get to the bottom of this I read many suggestions.  Dodgy memory seems to be a common cause, and this can be checked by booting memcheck and leaving for a few hours.