Page 1 of 1

T410s, XP, how can I disable hibernation for good?

Posted: Fri Jun 11, 2010 9:39 pm
by FragrantHead
When I press Fn-F12, the machine hibernates. If I turn hibernation off in Windows XP, then press Fn-F12, the machine still hibernates. After coming out of hibernation the option in XP has been turned back on. I do not want hibernation! I do not want it by accident, as I will be running Truecrypt full disk encryption and there is a question mark over Truecrypt working reliably with hibernation. I do not wish to take any chances with my data. How do I disable the stupid Fn-F12 key for good?

(Don't you just hate engineers who are too clever? Who do Lenovo think they're doing a favor by disrespecting a legitimate option in Windows?)

Re: T410s, XP, how can I disable hibernation for good?

Posted: Sat Jun 12, 2010 12:27 am
by dr_st
I guess one thing you can do is remove the Thinkpad Power Management Driver...
http://www-307.ibm.com/pc/support/site. ... MIGR-68268

If I were you, though, I would think more than twice before trusting my data to a piece of software that is suspected not to work properly with a legitimate and very useful function in Windows...

Re: T410s, XP, how can I disable hibernation for good?

Posted: Sat Jun 12, 2010 11:50 pm
by Navck
dr_st wrote:If I were you, though, I would think more than twice before trusting my data to a piece of software that is suspected not to work properly with a legitimate and very useful function in Windows...
I think I trust the engineers more than some oddball coder or group of coders that doesn't work with a legitimate function in Windows.
Maybe its time to change software?

Re: T410s, XP, how can I disable hibernation for good?

Posted: Sun Jun 13, 2010 8:32 am
by FragrantHead
Just because it's open source? I believe Truecrypt is quite well respected. I was trying to remember where I had my information from and it's the Truecrypt website itself:
Disclaimer: As Microsoft does not provide any API for handling hibernation, non-Microsoft developers of disk encryption software are forced to modify undocumented components of Windows in order to allow users to encrypt hibernation files. Therefore, no disk encryption software (except for Microsoft's BitLocker) can currently guarantee that hibernation files will always be encrypted. At anytime, Microsoft can arbitrarily modify components of Windows (using the Auto Update feature of Windows) that are not publicly documented or accessible via a public API. Any such change, or the use of an untypical or custom storage device driver, may cause any non-Microsoft disk encryption software to fail to encrypt the hibernation file. Note: We plan to file a complaint with Microsoft (and if rejected, with the European Commission) about this issue, also due to the fact that Microsoft's disk encryption software, BitLocker, is not disadvantaged by this.

(Update 2008-04-02: Although we have not filed any complaint with Microsoft yet, we were contacted (on March 27) by Scott Field, a lead Architect in the Windows Client Operating System Division at Microsoft, who stated that he would like to investigate our requirements and look at possible solutions. We responded on March 31 providing details of the issues and suggested solutions.)

(Update 2009-05-10: Since April 2008, we have been working with Microsoft to explore possible ways to solve this issue. We have private access to a draft version of a document specifying the future API, which should allow us to solve the issue on Windows Vista and later versions of Windows. Note: We have been asked not to disclose the content of the document to any third parties, so please do not ask us to send you a copy of the document.)
I'm a Windows programmer myself and I appreciate what they're up against. To be fair to them, they are disclosing quite a number of obscure technical issues that might affect only a few of their users. I appreciate that. Where can you even get this sort of information from a commercial company? It'd be swept under the rug or handled by their support department. The sales and marketing people wouldn't understand the issues and, quite rightly, conclude that they'd only scare customers, which will be true for the vast majority for whom the software will work fine. Doesn't mean they don't exist.

I eventually tried hibernation with Truecrypt and it works fine, by the way (with a possible question mark over whether the hibernation file is encrypted). Perhaps I am being overly cautious. Years of memories of hibernation not working reliably in older Microsoft OSs are hard to erase.

Re: T410s, XP, how can I disable hibernation for good?

Posted: Sun Jun 13, 2010 9:08 am
by FragrantHead
As for undocumented APIs, I avoid them like the plague myself. Unfortunately there are times when Microsoft have not provided an official API for what I wanted. What's interesting about the few cases where I've used undocumented features is that they've continued to work throughout the last decade. You can use such features, if you're conservative and sensible or if they are nice-to-haves that your program will also work without. For example I have a method to detect whether a program is running as a service, so you can run the same executable as a normal program or install it as a service. This was worked out under NT, but has continued to work unchanged under all Microsoft OSs right through to Windows 7, 64-bit. Another example is the use of .INI files. Microsoft have been advising for years that programmers should be using the registry instead and that the .INI API will be deprecated. In reality .INI files are still terribly useful and not everything needs to go into the registry. Consequently the API is still available to this day. Microsoft are not unreasonable. In fact, historically, they've often bent over backwards to not break 3rd party software, even when they've been anti-competitive with their major rivals at the time. It's a balancing act for them. If too many things don't work after a Windows upgrade, customers will blame Microsoft rather than the third party software that's using undocumented APIs.