Just to share my 3-day battle with Windows 7 32bit Pro after it was installed on the Kingston V+100E Self-encrypting SSD 64GB.
To be fair, the problem has little to do with the Kingston SSD actually. There may be incompatibility with Truecrypt 7.1 & Self-encrypting SSD, or it could be old registry entries left-over from my old encrypted HDD but I didn’t investigate further since I’ve solved my hibernation problem.
Update at the end of this article!
*******************************
System:
OS: Win7 32bit Pro (New install, not upgrade)
Laptop: Fujitsu T4215 with CPU upgraded to Intel T7200
HDD: WD Scorpio Black 320GB (Truecrypt 7.1 System FDE) -> Kingston V+100E 64GB (Self-encryption)
Drivers: (All updated to latest from manufacturer)
********************************
Everything seems to work well until I run Easy Transfer to transfer my account from my old HDD to the new SSD. My old WD Scorpio Black was encrypted using Truecrypt 7.1 so there were active Truecrypt registry entries which I’m not aware of & few people seem to know about. Google it & you would’t find many entries if any.
Hibernation will always fail with black screen. When KB/Mouse is touched, the login screen is shown. Event Viewer will show Event ID 45 Error caused by volmgr on \device\harddiskvolume2 (which is my C:\). What’s cryptic is the error is a crash dump driver error. What has crash-dumping in volmgr.sys got to do with hibernation?
A lot in fact, after kernel-mode drivers had crashed or unloaded, the only way the NT Kernel could do stuff is through special filters apparently. So to activate Hibernation, the Kernel has to unload everything & dump everything in RAM to HDD. What if you’re running Bitlocker or Truecrypt, which are software-based encryption?
The Kernel has to filter the RAM data thru these small programs so the Hibernation or Crash dumps are encrypted as well, else there’ll be a security risk. dumpfve.sys for Bitlocker & truecrypt.sys for Truecrypt 7. Unfortuntately I don’t see this documented anywhere. (I did not search SourceForge though.) I found out when I was hunting in the registry.
This registry key is where I found the offending entry.
HKLM\SYSTEM\CurrentControlSet\Control\CrashControl -> DumpFilters
In it, I found “dumpfve.sys” & “truecrypt.sys”. Now I did not install Truecrypt in the new system so the only way is thru’ Easy Transfer.
OK, fine, so I install Truecrypt 7.1 to make sure the proper files are installed. But after rebooting, Windows BSOD & I couldn’t see any crash dump! It may be that active Truecrypt registry is still there thinking the SSD was encrypted. Well I can’t have that! So I did a System Restore & booted up. I then remove the truecrypt.sys entry in all Registry keys, adjust my pagefile size, enabled crash dump 128KB & enabled hibernation with “-size 100”.
Hit the Hibernation button & it WORKS!!!
After that, whatever changes I did to pagefile.sys & crash dump size did not affect Hibernation.
So for those of you who have hibernation problems with Event ID 45 from volmgr. Check your crashdump filter.
Now I still need Truecrypt to access the old encrypted WD Scorpio Black, so what I did was to install Truecrypt in “Portable” mode & run the .exe files instead of an installation. Done!
Update (19/3/2012):
Recently I cleaned the registry of all entries with Truecrypt & install the latest 7.1a version & Windows did not BSOD so I’m a happy camper again. Seems like Truecrypt doesn’t leave many entries in Windows itself, which is a GOOD thing!
My Thinking Out Loud! 
You are a genius!!!!
Thank you so much for this post.
It saved me hours/days of furstration.
LikeLike
You’re welcome.
LikeLike
Thank you, this solved my problems with Hibernation too. I had attempted to install Truecrypt on a new laptop, which ran fine on my previous laptop, but just got a BSOD during boot and had to remove it via system restore. I ended up using PGP WDE instead, but it is very good to have hibernation working again.
You did not detail what change you made to the Registry. I edited HKLM\SYSTEM\CurrentControlSet\Control\CrashControl -> DumpFilters and removed the reference to truecrypt.sys, leaving the reference to dumpfve.sys (after creating a restore point). This is all it took. No reboot required.
LikeLike
Worked great for win7 sleep mode issue too.
Sleep mode didn’t work after making new harddisk volume.
This did the trick, Thanks!
LikeLike
Hi! I’ve got the same problem with hibernation and volmgr 45.
HKLM\SYSTEM\CurrentControlSet\Control\CrashControl -> DumpFilters value is
“dumpfve.sys”.
How to solve that?
LikeLike
Just remove that registry entry.
LikeLike
Removed, but it didn’t solve the problem.
LikeLike
Goto this page. You have a different problem.
http://support.microsoft.com/kb/920730
LikeLike
Oh Eric!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
I can’t express my gratitude how much your article helped me. After Windows 10 1709 creator’s update hibernation was broken, again with the lock screen. I nearly smashed my whole system whole trying to fix that as MS hat recommended to install new display drivers. After TWO long weeks of fixing I was finally back where I had started: With a running system, but broken login screen and hibernation not working. I finally fixed the broken screen, but hibernaiton would not work. I worked myself through several google search result pages and tried all hints on so many sites I can’t even count any more. Nothing helped.
Until I found your article! While my (encrypted) system was broken (windows didn’t even start any more) I decided to decrypt it with the VeraCrypt Rescue disk in DOS mode to make sure the data would at least be accessible. I wanted to backup important data before testing any further. Well, decrypting in DOS-mode obviously lead to this collateral damage.
I found VeraCrpyt.sys in the registry key you mentioned, removed it along with all other VeraCrypt* and even older TrueCrypt* entreis I could find (I deinstalled VC completely before that). Another reboot – and, ladies and gentlemen, hibernate is FINALLY working again!
It’s still weired though as hibernation was broken already before I decrypted in DOS mode. It must have been related to the 1709-update as everything was running flawlessly before. But it’s the same for me: After spending so many hours, days, weeks now, trying to fix all that I’m too tired to go into any further investigation. It’s working!!
Eric, once again, thank you so much for sharing this! Words can’t describe the relief I’m feeling right now! Considering the fact your article is more than 6 years old, it’s a shame that users can still run into this trouble. Microsoft? VeraCrypt? Anybody?
LikeLike
Hi John, glad my article helped! As long as you’re using software-based Full-disk encryption, there’s ALWAYS the chance this can happen due to a mis-timed restart or a driver signature issue, etc.
My own Surface Pro had issues this week with what I believe it a driver signature or TPM or Drive ID issue, which messed up the internal NVMe, causing Windows not to recognize the drive that it’s installed on. Since the SSD is hardware encrypted and tied to the UEFI firmware, I can only guess that somehow the latest 1709 patch for Spectre/Meltdown is responsible for all this mess.
My issue was Windows 10 suddenly couldn’t Boot up due to Boot_Device_Inaccessible. I first notice my encrypted microSD card couldn’t be recognized by Windows 10 so I tried to reboot and BAM! BSOD! I had to go to my Microsoft Account Key Recovery page to in order to get my key to Unlock the encrypted SSD in the Surface Pro, then I tried all sorts of ways to repair the boot sector/Windows installation, etc. However, since I need to get this working ASAP, I didn’t try to do a forensic of the registry or look through the LOG files, etc.
After I recovered my data, I reinstall Windows 10 and Lo and Behold, a new UEFI firmware was installed. Maybe if Microsoft released this firmware earlier, I wouldn’t have to reinstall my Windows on my Surface Pro (5th gen).
I really busy these days to blog, so I’d put this here in case people needs to recover from this new issue that I encounter.
LikeLike
Well, 1709 seems to be rather dangerous considering this matter, especially for notebooks and tablets. Google will list tons of pages where people complain about the forced 1709-update. Many have trouble with Sleep, hibernate and even usual shutdown. Some had to switch off their computers with a hard shutdown (some even had to cut off electricity EVERY time). They felt like guinea pigs for Microsoft – and they were right. These hard shutdowns can harm (not only) your HDD!
LikeLike
Are these issues happening on Intel or AMD machines? I know AMD has provided incomplete information to Microsoft, hence the many issues on AMD machines. I also know that this issue cannot be fully resolved with software and even hardware (microcode & BIOS/UEFI) patches. Only a redesigned CPU can fully resolve this design flaw. I have upgraded all my (many) machines, including desktop/laptops/tablets and so far none have shutdown/suspend issues. I only use Intel or Microsoft or AMD certified drivers instead of manufacturers’ drivers so maybe that’s why I don’t have issues.
The security issue targeted by Meltdown and Spectre are fundamental CPU design issues that we computer engineers have known about for more than 20 years. Hence, every CPU/GPU/DSP that does speculative (branch) execution may have this design flaw. However, in the past, it was thought that it’s impossible to exploit this hole due to the complexity of the hack and the much slower CPU speed from 15 years ago. It is important to note that nothing is completely fool-proof in engineering so it’s a matter of time that this will happen. We just mitigate and move on. This also means I will not be upgrading my 4th-gen Core i7 to the 7th-gen Core CPU this year. Most likely I will monitor how Intel & AMD solve this problem and choose my CPU based on the performance after Microsoft/Intel/AMD has finished patching and optimising.
As for HDD, I have not had a HDD head crash from a WD or Seagate HDD (on my own personal machines) in 5 years so power-cycling should be safe for modern HDD with Auto-park and current protection features. That said, I have moved to mostly SSD except for my NAS and workstation where I need huge HDD space. I also only buy high-end HDD like WD Black/Red and Seagate Enterprise HDD.
LikeLike
I didn’t check this actually, but I remember some users solved the matter by updating their ‘Intel Management Engine Interface’ driver. So I can’t tell anything about AMD, but Intel is definitely involved in some cases.
My personal trouble, as I know today, was triggered by the DOS mode decrpytion. But hardly anybody in the “My computer doesn’t sleep / hibernate / shutdown”-posts wrote anything about encryption so I guess their problems were caused by something else.
When my computer refused to shut down, one hard reboot solved the matter. Only hibernate still didn’t work after that.
I remember that many threads started 10/2017 and 11/2017 when the 1709-upgrade was rather new. Maybe I was lucky the upgrade wasn’t rolled out for me until end of December which gave MS and manufacturers more time to fix known issues.
You can’t repeat it too often: Never change a running system! And if something is not broken, don’t fix it! Despite Microsoft not being responsible directly for my trouble, it all started with their force 1709-update…
I also avoid low budget hardware but there’s no guarantee high end stuff will perform better in all cases. According to Murphy’s law, even auto-park and other protection features of HDDs can fail. Anyway, all HDDs prefer to be powered off the normal way for sure. 🙂
LikeLike