none
Windows 10 1607 - Hardware BitLocker (eDrive) Wake from Sleep Issue RRS feed

  • General discussion

  • I'm having an issue with the Windows 10 Aniversary Update (1607) build 14393.10. I'm running Windows 10 Pro x64 with BitLocker enabled on the OS drive. I am using the hardware encryption with BitLocker (also called eDrive). The issue is that when resuming from sleep the system will lock up for several minutes on a black screen with cursor and then blue screen. So far I've seen the "Critical_Process_Died" error on the BSOD. I am seeing the issue on two different systems. The first is a custom PC that was upgraded from 1511 and has a Samsung 850 EVO SSD. The second is a Lenovo ThinkPad X230T that was clean installed with 1607 and has a Samsung 840 EVO SSD. Both systems have the latest UEFI (BIOS) version and hardware BitLocker worked properly with 1511. If I disable BitLocker the system will wake from sleep without issue.

    ***UPDATE: This issue has been fixed in 14393.187 released 13 September 2016

    • Edited by NateSomers Saturday, October 1, 2016 11:49 PM
    Thursday, August 4, 2016 11:03 PM

All replies

  • I can confirm the issue on two separate machines. 840 EVO, eDrive enabled, started happening upon upgrading to 1607. Had to disable BitLocker to stabilize machines.
    Friday, August 5, 2016 11:11 AM
  • Make that three (Samsung 850 EVO).

    eDrive is Microsoft's baby. Why this?

    Monday, August 8, 2016 11:29 AM
  • Hi,

    I can confirm this as well with a Dell E7470, Samsung 850 EVO SSD and Win 10 1607. It has been a clean install on this new notebook, so I'm not sure if the same hardware would work without the Anniversary Update. Though similar setup worked on my previous notebook with Win 1511.

    I'm using the Microsoft SATA driver since the intel RSAT still doesn't support bitlocker hardware encryption. This is really sad,

    BR
    Johannes

    Monday, August 8, 2016 8:07 PM
  • I have this exact same issue. 850 EVO. Used to work fine with edrive on Dell E6540 then one day sleep stopped working just as you describe. I think I "disabled" bitlocker to see if it would fix the solution. It did not. Now I can't enable "edrive" again. When I enable bitlocker again it want's to do software encryption. 

    Another big problem is When trying to install the 1607 upgrade it asks me for the bitlocker recovery key like it's still enabled.. I input the key.. it boots to recovery.. I reboot.. and it says the install failed. 

    What the heck MS.. why is this edrive stuff so cryptic. You don't even document it well on your site or tech docs.

    Again.. this USED to work. Then after some upgrade or patch to Win10 it killed sleep. Now I'm stuck in this screwed up config. edrive is still somehow working as I have to input recovery key to enter recovery.. but enabling bitlocker wants software... and my sleep is wrecked!

    Monday, August 8, 2016 10:48 PM
  • I can confirm the issue on my Lenovo X230 with two Crucial MX200 SSDs, both eDrive-encrypted.

    After I've disabled bitlocker, sleep started working again, but I can also confirm junk430s problem, that it's not possible to reenable eDrive after that. Bitlocker wants to use software encryption then.



    • Edited by Drakenson Tuesday, August 9, 2016 7:16 AM
    Tuesday, August 9, 2016 7:14 AM
  • Same here - no waking from sleep for our Dell 7348 - which has uses a Samsung 850EVO SSD with hardware bitlocker enabled.

    On wake the laptop appears to be powered up, keyboard lights up, but the display stays black and only a hard power-off/power-on cycle will bring it back.

    We have not tried disabling bitlocker nor can we for compliance reasons.

    Tuesday, August 9, 2016 2:59 PM
  • Reinstalled OS today and after a clean Win 10 1607 Enterprise install,

    -registered, joined domain,

    -enabled bitlocker, ran test, reboot.

    -Boom bitlocker is enabled. Shows hardware enabled

    -Sleep then wake.. hung at all blue screen. mouse moves. I'm sure it will BSOD in a bit. can't do anything other than move mouse.

    Microsoft help please.

    Tuesday, August 9, 2016 7:40 PM
  • Can confirm similar symptoms on the following configuration:

    • Dell E7450
    • Samsung 850 PRO
    • Microsoft AHCI drivers
    • Bitlocker in eDrive mode


    Tuesday, August 9, 2016 11:08 PM
  • Confirmed here also with a clean install of 1607 Pro on a freshly PFID reset and secure erased Samsung 850 EVO. All system BIOS and firmware updated to the latest versions, system and driver updates installed, the system can not wake from sleep. Lock screen appears, mouse moves, but no interaction is possible and the system will eventually BSOD with one of the following errors (some of these are from 1511):

    KERNEL_DATA_INPAGE_ERROR (ntfs.sys)
    IRQL_NOT_LESS_THAN_OR_EQUAL (storahci.sys)
    CRITICAL_PROCESS_DIED

    • Lenovo W540 (UEFI BIOS 2.27, Secure Boot)
    • Samsung 850 EVO (firmware EMT02B6Q)
    • Microsoft AHCI drivers
    • Bitlocker eDrive hardware encryption (1.3.111.2.1619.0.1.2)

    Related threads:

    http://answers.microsoft.com/en-us/windows/forum/windows_10-performance/bitlocker-with-edrive-results-in-system-not-waking/458a3167-3b5d-4f8c-9b90-3c56e7345a51

    https://forums.lenovo.com/t5/ThinkPad-P-and-W-Series-Mobile/W540-consistent-blue-screen-when-waking-from-sleep-AHCI-problem/m-p/3359179

    https://communities.intel.com/thread/77885

    Wednesday, August 10, 2016 3:37 AM
  • Could this be due to the TPM 2.0 requirement that was mentioned in the 1607 release? I understood this was more of a certification requirement for systems shipping with 1607.

    My Lenovo W540 only has TPM 1.2, manufacturer STM (apparently integrated on Intel QM87 chipset), version 13.12.

    Wednesday, August 10, 2016 3:42 AM

  • I did a PSID revert last night, wipes all data and reinstalled everything AGAIN! To my horror Bitlocker enabled without asking how much of the disk to encrypt so I knew it went into hardware encryption again!! @#($(%*$% yep.. sleep is again broken. 


    I 100% agree there is some issue with the disk not re-connecting. I can see the drive light flickering like mad as it tries to read the drive. 


    If I was a betting man.. I'd say the drive is not re-connecting or authenticating after sleep. Anyone from MS want to contact me about this? It's 100% repeatable.. and it USED to work so you guys broke it.


    The joy of Win10 and the never ending upgrade.. you never know when your computer will BRICK because they hosed encryption. 


    MS if you want to run this fast and loose development model you need to support us when you kill things like this!. The clock is ticking...

    Wednesday, August 10, 2016 7:36 PM
  • One more post with the same problem:

    http://de.community.dell.com/support_forums/laptops/f/103/p/15590/25817#25817

    Friday, August 12, 2016 8:17 PM
  • One more post with the same problem:

    http://de.community.dell.com/support_forums/laptops/f/103/p/15590/25817#25817

    Same Problem here with a Cruical MX300 and eDrive enabled, after I updated to Anniversary Update.
    Saturday, August 13, 2016 11:32 AM
  • For now, try setting your system to hibernate instead of sleep. To see if this will work on your system, hold the windows key, press r, and type "shutdown -h" (no quotes) and click "OK" to hibernate your system. If it wakes without crashing, the following instructions will make that the default behavior for the various ways your system will transition to sleep.

    Right click on your start button, choose "power options" then "change plan settings" for your active power plan. Make sure that "put computer to sleep" is set to "never" for both battery and AC power. Then, click "change advanced power settings" and change all of the options under "Power buttons and lid" to "hibernate". Similarly, you may want to change "Sleep > Hibernate after > on battery" to a shorter time (15-45 minutes).

    I'm talking with the bitlocker team to get an official response, but I did find that hibernate has been an effective workaround on my systems.


    Saturday, August 13, 2016 9:35 PM
  • Hi,

    similiar problems here.

    I´m using an HP zBook 14 G2 with two SSDs and Windows 10 Enterprise.

    The OS resides on the first SSD (Crucial MX200 M.2), which is bitlocker software-only encrypted (AES128). 
    The second SSD, which is being used for data storage only, is a Samsung EVO 850 Pro with bitlocker enabled hardware encryption.

    This configuration worked fine for one year now until I did the upgrade to Windows 10 1607 EE.

    After the upgrade (which went fine without any problems) I discovered an issue with the Samsung EVO 850 Pro.

    When the laptop returns from sleep mode, the data on that disk is not accessible anymore, and the system event log is beeing spammed with the message:

    "The IO operation at logical block address 0xadbef8 for Disk 0 (PDO name: \Device\00000034) was retried." (Event-ID 153)

    and

    "The system failed to flush data to the transaction log. Corruption may occur in VolumeId: D:, DeviceName: \Device\HarddiskVolume5.
    (The I/O device reported an I/O error.)" (Event-ID 140)

    After a reboot everything is working fine until the laptop goes to sleep again.

    The Crucial MX200 (software-only encryption) is not affected.


    I replaced the Samsung EVO 850 Pro with a brand-new one (same model) and initialized/configured it for bitlocker hardware encryption (edrive), which resulted in exactly the same problems.

    After that I initialized the disk again, but this time for software-only encryption, and everything works fine when the system returns from sleep mode.

    I did these tests several times and my conclusion is that "only" hardware-encrypted bitlocker configurations are affected; this is 100% reproducable.

    Hopefully MS is coming up with a solution ASAP; I don´t want to rely on software-only - encryption.

    Thanks


    Sunday, August 14, 2016 7:31 AM
  • Same here. Samsung 850 Pro and Bitlocker on a Lenovo T430
    Sunday, August 14, 2016 3:44 PM
  • For now, try setting your system to hibernate instead of sleep. To see if this will work on your system, hold the windows key, press r, and type "shutdown -h" (no quotes) and click "OK" to hibernate your system. If it wakes without crashing, the following instructions will make that the default behavior for the various ways your system will transition to sleep.

    Right click on your start button, choose "power options" then "change plan settings" for your active power plan. Make sure that "put computer to sleep" is set to "never" for both battery and AC power. Then, click "change advanced power settings" and change all of the options under "Power buttons and lid" to "hibernate". Similarly, you may want to change "Sleep > Hibernate after > on battery" to a shorter time (15-45 minutes).

    I'm talking with the bitlocker team to get an official response, but I did find that hibernate has been an effective workaround on my systems.


    I am suffering from the same issues as the rest of the commenters (Samsung 850 EVO, MSI Z87-G43 motherboard). I can confirm that the system will hibernate properly. In fact, if hybrid sleep is enabled, the system won't wake out of sleep, but will wake from the hybrid sleep's backup hibernate image if the reset button is hit.

    I recall on Windows 10 version 1511, even after a normal sleep the system would still power on to the UEFI splash screen, as though it were coming out of hibernate. Perhaps sleep used to be disabled due to the edrive?

    I also have a Dell Precision 5510 that was having TPM problems when waking from sleep on 1607. The TPM would fail to be detected by the OS. The system would wake, hang, reboot, and then prompt for the recovery key. On a subsequent reboot, the TPM would be detected again. Using a Dell-provided firmware update to TPM spec 2.0 seems to have resolved that problem.

    I'm left wondering if a similar TPM re-initialization problem is the issue here.

    Monday, August 15, 2016 1:43 AM
  • Glad to hear that hibernate's working for you. You're on the right track, Prometa. Unfortunately, I am not sure how much I can comment on the internal workings of things like this.

    I'm hoping the team will chime in, because the internal discussion has been quite fascinatingd, and I think it's something that would be good for a more official channel (the team itself) than "some guy at Microsoft"* who suggests something. Many think that the MS tag means we're here on official business, but the truth is we hit problems, too, and sometimes have to try fixing or working around them :).

    -Timnn

    *I haven't been on Windows for over 4 years now and have little contact with the team/development of the product; my installed toolset is drastically different than when I was on a kernel level team there, so I truly am just a random MS guy.

    Monday, August 15, 2016 2:20 AM
  • One more here. Lenovo T530 plus Crusial MX200. I had and have only "Microsoft" drivers related to Storage subsystem (shipped with OS or installed via System Update so certified by MS).

    All the same story with the same issues described by all other community members:

    1. I was having BSOD when Bitlocker with eDrive was enabled.

    2. I cannot re-enable hardware Bitlocked encryption on Win10 1607.

    Monday, August 15, 2016 10:18 PM
  • I'm having same issue as well.   Worked perfect on 1511.  My Setup:

    Dell e6440

    • Win 10 1607 (14393.51) Fresh Install
    • TPM 1.2 (ATML 41.1)
    • BitLocker w/ Startup Pin
    • Samsung EVO 850 1TB using eDrive

    If I turn off BitLocker sleep works perfect.   I also had one other weird issue (related?) where if you looked in BitLocker Drive Encryption under control panel and If you ran Get-BitlockerVolume in PowerShell it showed FullyDecrypted and Protection off.  But what was weird is I was still getting the prompt to type my startup pin in on bootup.  This was before I realized BitLocker was causing the problem and I had never turned it off.  A system restore back a few days got everything back up in sync.

    If this helps here is some information from PowerShell of my current state:

    PS C:\Windows\system32> Get-BitLockerVolume | fl
    
    ComputerName         : BRANDON01
    MountPoint           : C:
    EncryptionMethod     : Hardware
    AutoUnlockEnabled    :
    AutoUnlockKeyStored  : False
    MetadataVersion      : 2
    VolumeStatus         : FullyEncrypted
    ProtectionStatus     : On
    LockStatus           : Unlocked
    EncryptionPercentage : 100
    WipePercentage       : 0
    VolumeType           : OperatingSystem
    CapacityGB           : 930.96
    KeyProtector         : {TpmPin, RecoveryPassword}
    
    
    
    PS C:\Windows\system32> Get-Tpm
    
    TpmPresent          : True
    TpmReady            : True
    ManufacturerId      : 1096043852
    ManufacturerVersion : 41.1
    ManagedAuthLevel    : Delegated
    OwnerAuth           :
    OwnerClearDisabled  : True
    AutoProvisioning    : Enabled
    LockedOut           : False
    LockoutCount        : Not Supported for TPM 1.2
    LockoutMax          : Not Supported for TPM 1.2
    SelfTest            : {0, 0}



    • Edited by Microbolt Monday, August 15, 2016 11:00 PM Added detail
    Monday, August 15, 2016 10:57 PM
  • I'm having same issue as well.   Worked perfect on 1511.  My Setup:

    Dell e6440

    • Win 10 1607 (14393.51) Fresh Install
    • TPM 1.2 (ATML 41.1)
    • BitLocker w/ Startup Pin
    • Samsung EVO 850 1TB using eDrive

    If I turn off BitLocker sleep works perfect.   I also had one other weird issue (related?) where if you looked in BitLocker Drive Encryption under control panel and If you ran Get-BitlockerVolume in PowerShell it showed FullyDecrypted and Protection off.  But what was weird is I was still getting the prompt to type my startup pin in on bootup.  This was before I realized BitLocker was causing the problem and I had never turned it off.  A system restore back a few days got everything back up in sync.


    Did you happen to install the Intel RST driver (Intel SATA/AHCI driver)? When I suspected a disk issue, I tried installing it. It didn't fix the problem, but it did cause Windows to think my drive wasn't encrypted, even though Samsung Magician said it still was. Uninstalling the driver did not fix the problem, and, worse still, trying to run the bitlocker status applet did nothing--the app didn't crash and dump an error, but it didn't run either. Like you, I had to system restore to a date prior to installation of the Intel driver to restore the status.

    I also have a software-encrypted secondary drive. After installing the Intel driver, it prompted for a recovery key every time I accessed the drive. That problem also went away with the system restore.


    • Edited by Prometa Monday, August 15, 2016 11:54 PM
    Monday, August 15, 2016 11:53 PM
  • Did you happen to install the Intel RST driver (Intel SATA/AHCI driver)? When I suspected a disk issue, I tried installing it. It didn't fix the problem, but it did cause Windows to think my drive wasn't encrypted, even though Samsung Magician said it still was. Uninstalling the driver did not fix the problem, and, worse still, trying to run the bitlocker status applet did nothing--the app didn't crash and dump an error, but it didn't run either. Like you, I had to system restore to a date prior to installation of the Intel driver to restore the status.

    I also have a software-encrypted secondary drive. After installing the Intel driver, it prompted for a recovery key every time I accessed the drive. That problem also went away with the system restore.



    Yep, I sure did.  I installed the Latest Intel RST driver as a troubleshooting step.  It was after that that I noticed Windows thought BitLocker wasn't on any longer.  Maybe we can get two bugs squashed in this thread! :)
    Tuesday, August 16, 2016 1:19 AM
  • Hi Microbolt and Prometa,

    the issue with the Intel RST driver is being discussed here: https://communities.intel.com/thread/77885

    I think this is an entirely separate issue because it predates the sleep problems.

    To reproduce the RST issue, you have to have a hardware encrypted eDrive from a clean Windows 10 install, then install Intel RST. Bitlocker will no longer recognise that the drive is encrypted, even though it is as shown by password or recovery requests on system changes. Intel doesn't seem to have it's sharpest engineers working on the problem, they are still trying to reproduce it but their guy can't manage to hardware encrypt his drive. Probably needs a PFID reset. If people from Bitlocker team are on this thread maybe they can head over there and help figure it out.

    The only way to resolve the issue is to do a system restore to before Intel RST installation. Uninstalling it will not work.

    Meanwhile, can anyone from Microsoft comment on the sleep issue?

    Tuesday, August 16, 2016 2:30 AM
  • Nobody from Microsoft wants to comment on this issue. Nobody wants to take the blame for this horrible screw-up.

    eDrive was broken when 1511 was initially released.

    With 1607, eDrive is broken two times in a row.

    Wednesday, August 17, 2016 4:48 PM
  • Has anyone tried to update the TPM to 2.0 as suggested above?
    Thursday, August 18, 2016 12:49 AM
  • Instead of trying to blame someone, please remember that we're people just like you. We make mistakes. I didn't make this one, but I've made plenty of others. An attitude of blame & shame does nothing but discourage any of us, even those who don't work on the team, from trying to help or engage with you outside of PR channels.

    Yes, eDrive was negatively impacted by the update (in fact, I have had to fix four systems that were impacted, in three different ways). Emailing the team, I know what happened and have encouraged them to comment here. Something worth remembering (especially with encryption) is that that a fix released too hastily can be worse than no fix at all! While I'm trying to encourage those I've spoken with to make a post here, comments like "take the blame" and "horrible screw-up" are unlikely to help convince anyone to comment on this :).

    Thursday, August 18, 2016 12:53 AM
  • You have established:

    1. Problem is reproduced. And the team knows about it.

    2. Nobody has commented.

    So now what? Cry me a river? You're people too, how about us who are on the receiving end of this unaccountable breakage? Do you even know what it feels like?

    The breakage on 1511 was just fixed by a patch. No comments there either.



    • Edited by E. Jokacs Thursday, August 18, 2016 1:57 AM
    Thursday, August 18, 2016 1:40 AM
  • I can actually almost understand them not commenting. This is probably a pretty high level bug, and revealing what has gone wrong and what they are doing to fix it could unintentionally reveal an attack vector against Bitlocker. Such is the nature of closed-source software. Then we would all be left with vulnerable data until Bitlocker 2.0 or whatever is released.

    Stay calm and let's wait for a patch or comment, in the meantime keep posting 'me too' posts I guess.

    Thursday, August 18, 2016 2:38 AM
  • Instead of trying to blame someone, please remember that we're people just like you. We make mistakes. I didn't make this one, but I've made plenty of others. An attitude of blame & shame does nothing but discourage any of us, even those who don't work on the team, from trying to help or engage with you outside of PR channels.

    Yes, eDrive was negatively impacted by the update (in fact, I have had to fix four systems that were impacted, in three different ways). Emailing the team, I know what happened and have encouraged them to comment here. Something worth remembering (especially with encryption) is that that a fix released too hastily can be worse than no fix at all! While I'm trying to encourage those I've spoken with to make a post here, comments like "take the blame" and "horrible screw-up" are unlikely to help convince anyone to comment on this :).

    Your hibernation workaround, though not ideal, has got me back up and going.  For anyone else that it is not good enough, Microsoft included the roll back functionality in Windows 10 to ease any problems that may occur from an upgrade.   Me knowing that the BitLocker team knows is good enough for me.  I for one am appreciative that you commented :)

    Probably wasn't found in the preview program because I bet most people that run BitLocker are using them in production environment and wouldn't want the headache of potentially unstable builds.


    • Edited by Microbolt Thursday, August 18, 2016 8:38 PM
    Thursday, August 18, 2016 8:29 PM
  • Fanboyism much?

    eDrive is a Microsoft component, a lauded feature of Windows 10. It needs to work in some compliance situations.

    Are we now suggesting that Microsoft has no responsibility of ensuring that it works in new builds? It's now up to users and clients to find the bugs?

    No, no, no, no, no!

    Thursday, August 18, 2016 11:53 PM
  • To be honest, I'm sure eDrive is an extremely small percentage of BitLocker users.  You have to jump though some pretty big hoops to get it working.  As strophy pointed out even an engineer over at Intel was having difficulties getting it enabled.  Yes, it's an inconvenience and yes it'd be nice if it was caught in the insider program or in QA testing.  But its far from the end of the world.  All we have to do is just hibernate instead of sleeping until they push out a fix.

    Lets try to keep the thread on topic and try to not turn this into a flame war :)

    root:~# :(){ :|:& }:


    • Edited by Microbolt Friday, August 19, 2016 7:42 PM Quoted wrong name
    Friday, August 19, 2016 2:28 AM
  • There's no flame war going. I just want us to be rational adults, not adulating fans. Do we have choose one extreme position or the other?

    Microsoft has the primary responsibility of ensuring their products work.

    eDrive is a niche functionality. But bugs in eDrive can lead to critical failure. We're not talking graphical glitches.

    Nobody expects bug-free software. But fundamental eDrive bugs surfaced in both 1511 and 1607, in ways suggesting that nobody was testing the builds for eDrive before they got out the gate.

    Comments like "we acknowledge the bug, working on it" would be nice. But it's complete silence from the team responsible. Meanwhile Microsoft first-line support staff continue to advise "it's your drivers, BIOS ...."

    Friday, August 19, 2016 2:49 AM
  • The same goes for Lenovo T430 with Crucial MX100 SSD.

    This is a horrible BUG. It does show my desktop when waking from sleep without any password prompt.

    Though I am unable to click anything, my desktop gets revealed for ~15 seconds. It's a SECURITY bug.

    Do something about that Microsoft!

    Friday, August 19, 2016 3:24 PM
  • I can actually almost understand them not commenting. This is probably a pretty high level bug, and revealing what has gone wrong and what they are doing to fix it could unintentionally reveal an attack vector against Bitlocker. Such is the nature of closed-source software. Then we would all be left with vulnerable data until Bitlocker 2.0 or whatever is released.

    Stay calm and let's wait for a patch or comment, in the meantime keep posting 'me too' posts I guess.

    There is a pretty serious physical attack vector on self-encrypting drives (which also affects eDrive): if you put your system in sleep mode (S3), the drive will in most cases remain unlocked, and will not lock even if the data cable is unplugged. Thus, an attacker with physical access can unplug the data cable (but not the power cable!) and connect the drive to another computer, gaining full access to everything on the drive.

    The simplest way to avoid this potential hazard is to never use sleep mode, but always power off or hibernate instead, since the drive is always locked when power is cut.

    I guess the bug reported in this thread could actually be related to a Microsoft attemtp to prevent this attack vector, since what seems to happen is that the drive is indeed locked when entering sleep mode, which is a good security measure. The bug could then be that Windows just fails to unlock the drive when waking up from sleep again. But I'm just guessing.


    • Edited by Dassborste Sunday, August 21, 2016 9:30 PM
    Sunday, August 21, 2016 9:29 PM
  • Interesting theory, Dassborste! But I know that spinning hard drives spin down when in sleep mode, are they just sent an S3 signal and power continues to be supplied to the drive? If power isn't cut, and the eDrive therefore isn't power off during sleep, then why would it need password re-entry when waking up from sleep?

    I am still thinking this is something to do with how handling the TPM changed in 1607, it's like something is happening in the wrong order in getting the key from the TPM and sending it to the drive after waking from sleep. I wonder if somebody has encountered or can reproduce this problem in a system a hardware encrypted eDrive with the TPM disabled, using a USB dongle instead. I'd love to do it but I only have my production system to test on...

    Monday, August 22, 2016 2:09 AM
  • The simplest way to avoid this potential hazard is to never use sleep mode, but always power off or hibernate instead, since the drive is always locked when power is cut.

    I like this idea!  I haven't really seen any side affects from me disabling sleep and using hibernate instead.  And from a security standpoint its much safer since from what I understand when you use sleep instead of hibernate the BitLocker key is stored in memory.  I really like know that they have to try and brute force my Startup Pin before being able to attempt to get any access to my data.  And with TPM's anti hammering delays that can take quite a bit of time.

    But I know that spinning hard drives spin down when in sleep mode, are they just sent an S3 signal and power continues to be supplied to the drive? If power isn't cut, and the eDrive therefore isn't power off during sleep, then why would it need password re-entry when waking up from sleep?

    I thought unless eDrive is handled differently that the power is actually cut to the drive in both situations.  The drives are not "unlocked" per say as much as the computer remembers in memory how to unlock them.  If you pulled the drive out while its sleeping it will still be locked and encrypted if you put into another system.  So in standby its essentially only keeping power to the memory.

    • Edited by Microbolt Monday, August 22, 2016 3:55 PM
    Monday, August 22, 2016 3:48 PM
  • @strophy @Microbolt

    As far as I know, a sleeping drive is not without power - its controller board is still powered, and will remain in an unlocked state unless explicitly told to lock (and it is this explicit locking I'm guessing that Microsoft started doing with the 1607 build - but on the other hand, if they did then they should have discovered the bug as well, so maybe it is really a TPM related issue as strophy says).

    A lot more information (and other similar attack vectors) can be found in this extremely interesting paper (pdf file):

    https://www.blackhat.com/docs/eu-15/materials/eu-15-Boteanu-Bypassing-Self-Encrypting-Drives-SED-In-Enterprise-Environments-wp.pdf

    The authors recommend not using sleep mode for now, until operating systems, OEM computer manufacturers or drive manufacturers implement protections against it (e.g. by using explicit locking, data cable unplugging detection etc). Some already have protections in place, it seems, but apparently most don't.

    The paper is from 2nd November 2015 though, so perhaps things have improved since then.

    • Edited by Dassborste Monday, August 22, 2016 4:47 PM
    Monday, August 22, 2016 4:26 PM
  • @strophy @Microbolt

    As far as I know, a sleeping drive is not without power - its controller board is still powered, and will remain in an unlocked state unless explicitly told to lock (and it is this explicit locking I'm guessing that Microsoft started doing with the 1607 build - but on the other hand, if they did then they should have discovered the bug as well, so maybe it is really a TPM related issue as strophy says).

    A lot more information (and other similar attack vectors) can be found in this extremely interesting paper (pdf file):

    https://www.blackhat.com/docs/eu-15/materials/eu-15-Boteanu-Bypassing-Self-Encrypting-Drives-SED-In-Enterprise-Environments-wp.pdf

    The authors recommend not using sleep mode for now, until operating systems, OEM computer manufacturers or drive manufacturers implement protections against it (e.g. by using explicit locking, data cable unplugging detection etc). Some already have protections in place, it seems, but apparently most don't.

    The paper is from 2nd November 2015 though, so perhaps things have improved since then.

    Yeah, that does make it sound like they are trying to mitigate it.  Or they forgot to put the drive in a low power state instead of powering it off.   I'm only going to use hibernate for now on.   Had no idea that this was even possible.  (And so trivial)


    • Edited by Microbolt Monday, August 22, 2016 5:01 PM
    Monday, August 22, 2016 5:01 PM
  • I guess the bug reported in this thread could actually be related to a Microsoft attemtp to prevent this attack vector, since what seems to happen is that the drive is indeed locked when entering sleep mode, which is a good security measure. The bug could then be that Windows just fails to unlock the drive when waking up from sleep again. But I'm just guessing.


    I can't confirm that.

    My main drive is a Samsung 950 Pro with (lack of Support, shame on you Samsung) Software Bitlocker. I have a second HD (Cruical MX300) which is eDrive enabled.

    After waking from standby, the drive is still partly accessible, thus veeerry sloooow. After waking from standby I tried to open up a 4kb Text document which i never opened before, it took about 1 Minute but then opened.

    Without flaming, I too think that the lack of Information and the severity of the bug is a complete show-stopper for Microsoft in our Company.

    Monday, August 22, 2016 9:32 PM
  • Hi grafc, can you check your system log to see if there are any errors piling up immediately after waking from sleep when your access is "slow"? 
    Tuesday, August 23, 2016 2:34 AM
  • Also, I just read Dassborste's linked PDF and noticed that the researchers specifically highlight and praise some limited efforts by Lenovo to specifically detect when a drive is removed during sleep, and that some Lenovo laptops will not automatically unlock drives when waking from sleep. There are lots of caveats and specific scenarios, but how many of us here are actually using newer Lenovo laptops with this feature? I'm on a W540 with latest UEFI (2.27), very similar to the W541 (2.21) used in the research paper. Maybe this is actually something Lenovo could fix with an update.

    I think the key point here is that eDrive is vulnerable to attack in certain specific circumstances, usually related to sleep mode, and both Microsoft and Lenovo are trying to solve it without thorough testing, resulting in this bug.

    Bitlocker team, can you please post a few thoughts here about what is causing this and any progress towards a patch?

    Tuesday, August 23, 2016 2:58 AM
  • I can confirm the issue still exists after the Tuesday 8/23 updates to Windows version 1607. 
    Tuesday, August 23, 2016 11:19 PM
  • Same here. Installing KB3176934 bumped the OS Build number up to 14393.82 but did not resolve the wake from sleep issue.
    Wednesday, August 24, 2016 3:37 AM
  • For now, try setting your system to hibernate instead of sleep. To see if this will work on your system, hold the windows key, press r, and type "shutdown -h" (no quotes) and click "OK" to hibernate your system. If it wakes without crashing, the following instructions will make that the default behavior for the various ways your system will transition to sleep.

    Right click on your start button, choose "power options" then "change plan settings" for your active power plan. Make sure that "put computer to sleep" is set to "never" for both battery and AC power. Then, click "change advanced power settings" and change all of the options under "Power buttons and lid" to "hibernate". Similarly, you may want to change "Sleep > Hibernate after > on battery" to a shorter time (15-45 minutes).

    I'm talking with the bitlocker team to get an official response, but I did find that hibernate has been an effective workaround on my systems.


    Hibernate helps, and if I only have my OS drive (C:) eDrive encrypted, this workaround would be satisfactory. However, when I have a second data drive (D:) also eDrive encrypted, upon wake from hibernation, that drive no longer works properly. I can access the root of D: for a while, but not the subdirectories. When attempting to do so, it eventually errors out with a message along the lines of "D:\ is not accessible. The request could not be performed because of an I/O device error." Eventually, the same happens when I try to access the root of D:.

    Turning off Bitlocker on D: resolves the hibernate issue.

    Both drives are SSDs with hardware encryption. C: is a Samsung 850 EVO, D: is a Crucial M500.


    • Edited by CliffLee Saturday, August 27, 2016 1:42 AM Fix drive letter typo
    Friday, August 26, 2016 4:32 PM
  • Hey guys!

    Exactly the same problem here. This issue was driving me totally nuts since build 14903 I think - I disabled all all internal devices via BIOS, upgraded all drivers and did numerous clean install.

    Today, after the updates from 23rd appeared for 1607 I gave it one more try and still the same issue - curiously I never thought of Bitlocker being the issues, BUT THATS IT!!!


    Device:
    HP 1040 G3So what now Microsoft?
    Friday, August 26, 2016 4:32 PM
  • Same issue here, too :(

    After upgrading to Win10 1607 sleep mode doesn't work anymore.

    Win 10 1607
    TPM 1.2
    BitLocker w/ Startup Pin
    Samsung EVO 850 1TB usinng eDrive

    When waking up the device from sleep the lockscreen show up and the mouse can be moved, but nothing else works. No reaction to clicks, nothing. So I need to hard power off to get my PC working again.

    Saturday, August 27, 2016 1:32 PM
  • This bug appeared from me on a Lenovo T440P with a Crucial MX100 in mid-July on 2nd last insider build before release (I think). I even posted the issue in the feedback hub :)  I have since changed to a Lenovo T460P with a Samsung 850Pro but still have the same issue.


    • Edited by M Friedy Saturday, August 27, 2016 3:40 PM
    Saturday, August 27, 2016 3:40 PM
  • Hi grafc, can you check your system log to see if there are any errors piling up immediately after waking from sleep when your access is "slow"? 

    Sorry for late Reply.

    After waking up, I have dozens of Errors 153 and some Errors 140. (translated from german as follows):

    Error 153: (disk)

    EventData

    The E/A-Event at Logical block adress "0x5b7590" (changes every message) for device "0" (PDO-Name: \Device\00000037) was repeated.

    Details:

    \Device\Harddisk0\DR0
    0x6011a8
    0
    \Device\00000037
    0F01180004004000000000009900048000000000000000000000000000000000000000000000000000020228F0000B000000000B00000000000000000000762D

    Error 140 (Ntfs (Microsoft-Windows-Ntfs)):

    The data could not ne moved into the Transaction protocol. The data might be corrupted: Volume-ID: "D:", Device Name: "\Device\HarddiskVolume1".
    (The E/A-Device sent an E/A-Error).

    Saturday, August 27, 2016 10:51 PM
  • Me too ...Samsung 850 pro 1 tb with edrive and bitlocker in hardware encryption...tried everything...drivers, clean installation ect! nothing works for the moment

    I shut down the computer and that's all

    Waiting Microsoft for an updated driver!

    Wednesday, August 31, 2016 5:46 PM
  • Latest update KB3176938 brings Windows 10 1607 to Build 14393.105.

    Still the same issue.

    Color management is totally broken. Random freezes occur in Windows Explorer.

    I wonder if the whole Microsoft QA has gone on vacation.

    Wednesday, August 31, 2016 7:12 PM
  • Latest update KB3176938 brings Windows 10 1607 to Build 14393.105.

    Still the same issue.

    Color management is totally broken. Random freezes occur in Windows Explorer.

    I wonder if the whole Microsoft QA has gone on vacation.

    Likewise, no fix here.

    I thought the QA department was replaced by "Windows as a Service"...

    Seriously...how does something like this go unnoticed...

    Thursday, September 1, 2016 1:49 AM
  • I'm having the same general problem. After Anniversary update (1607) was installed the lock screen becomes unresponsive after waking from sleep. The computer itself wakes, which I can see from activity of the power and hard drive lights, but I am unable log back in. The sign-in box never appears. The only thing to do is reboot. Login after a reboot works fine, and Login after a sign-out works fine as well.

    My system configuration is:
    Asus Q87M-e motherboard
    Crucial M500 SSD (eDrive)
    Microsoft AHCI drivers

    I tried installing the latest Intel AHCI drivers to see if that would fix it but all it did was render my computer inoperable. After reboot Windows went into automatic repair mode and kept looping with no way out.

    At the time of the lock screen freeze I find entries in the event log from the Enhanced Storage subsystem saying that A TCG Command has returned an error (events 10, 12, 13, and 100).

    The problem does not occur when Bitlocker is turned off. I have not tried the Hibernate workaround. The latest (8-31) updates to 1607 do not fix the problem either.

    I spent over 6 hours on the phone with Microsoft tech support over the last three days talking with 4 different technician. Two at level 1, one at level 2, and then one at level 3. The last one said he would research this issue, consult the Bitlocker team, and get back to me by Wednesday.

    Unfortunately, with all my experimenting I have rendered Bitlocker unable to reactive hardware encryption on my eDrive, it always wants to run software encryption now. I have found that you can force hardware encryption on the operating system drive through gpedit by enabling the following setting:

    Computer Configuration\Administrative Templates\Windows Components\BitLocker Drive Encryption
    Configure use of hardware-based encryption for operating system drives

    More info here

    With this enabled Bitlocker will not proceed with software encryption. It will simply inform you that hardware encryption is not available for your drive. This will save you the steps of saving the keys and then cancelling when you see it's going to do software encryption.

    Another useful command I've found is "Manage-bde -status" run from an administrative command prompt. It will report what type of encryption, if any, is being used on your drives.

    Monday, September 5, 2016 1:32 AM
  • Hey DexterG, awesome you managed to get phone support! Please update us here on Wednesday...

    It sounds like during your experiments you got your drive into eDrive mode and then tried to reinstall Windows or reactivate it with a new key. This isn't possible without first doing a PSID reset on the drive to put it back into eDrive-ready mode. I think Crucial Storage Executive will let you do this, but it might need to be a secondary drive in another computer, or boot from USB. And of course you will lose all data on the drive after the reset.

    Meanwhile, it's over a month since this thread started and Microsoft hasn't even acknowledged this bug. Pretty different to Apple's recent 10-day turnaround from disclosure to public patch.
    Monday, September 5, 2016 2:42 AM
  • I have the exact same problem. I have:

    Lenovo T540p
    Samsung 850 Evo 1TB (BitLocker on, hardware encryption)
    Windows 10 Education 1607

    I was trying to troubleshoot this problem with an Answer Tech before just reverting to the previous build. In the process, the Answer Tech (while remoting into my system) deleted all my temporary files or something else that prevents me from going back to the previous build. Guess I'm stuck here until something changes. Thanks for the tip to use hibernate instead of sleep... it worked for me.

    Thursday, September 8, 2016 12:20 AM
  • I too am seeing some supreme weirdness on my Bitlocker setup. I originally had three volumes, all encrypted. A SSD w/ eDrive and two plain HDD's. After the latest update, I noticed that the Bitlocker Drive Encryption menu was missing from Control Panel.  I couldn't launch the GUI at all. If I searched "Manage Bitlocker" from the start menu it would appear, but nothing happened when I clicked it. 

    Also, automatic unlocking of drives stopped working as well.

    I could still work with volumes using manage-bde from command line. However, for whatever reason, manage-bde -status would NOT report my C: drive as being encrypted. In fact, it wouldn't report a status on that drive at all. I could only see the HDD's.

    Strangely enough, If I rebooted into Bitlocker recovery, I could see ALL volumes with manage-bde. As such, this was my only opportunity to disable Bitlocker on my C: drive so I did so. 

    After getting Bitlocker turned off I rebooted and...voila...the Bitlocker Drive Encryption menu makes a triumphant return to the Control Panel.

    I did some further testing by clearing the TPM and starting completely over, but it makes no difference... the Bitlocker Drive Encryption menu completely disappears as soon as I enable Bitlocker on my SSD. 

    As such, I'm just leaving all of my volumes decrypted for the time being. 


    Thursday, September 8, 2016 4:16 PM
  • Unfortunately, with all my experimenting I have rendered Bitlocker unable to reactive hardware encryption on my eDrive, it always wants to run software encryption now.

    Try either doing a system restore to before you installed the AHCI driver or roll them back to the Microsoft provided one.  I ran into this problem too using the Intel drivers.  Whats weird is even though Windows reports BitLocker is off it is actually still on.  You can verify this by putting your drive into another system.  There is a discussion about this bug over on Intel forums located here:

    https://communities.intel.com/thread/77885

    (credit to strophy for linking to that thread)

    And w123dal, the symptoms you describe could be this same issue as well.


    • Edited by Microbolt Friday, September 9, 2016 1:53 PM
    Friday, September 9, 2016 1:49 PM

  • And w123dal, the symptoms you describe could be this same issue as well.


    Unfortunately for me, I can't system restore back to that point. It fails for whatever reason. However, I can confirm that RST is NOT installed at the moment. I am using the standard AHCI driver. 
    Saturday, September 10, 2016 1:50 AM
  • Yeah, I had that issue too. Even if you uninstall RST and go back to standard AHCI, Bitlocker will not recognise the encrypted drive again. You need to system restore, and if that isn't possible, then PSID reset, go to eDrive ready mode and reinstall Windows 10.
    Saturday, September 10, 2016 3:38 AM
  • Any updates?
    Saturday, September 10, 2016 8:24 PM
  • [A]wesome you managed to get phone support! Please update us here on Wednesday...

    It sounds like during your experiments you got your drive into eDrive mode and then tried to reinstall Windows or reactivate it with a new key. This isn't possible without first doing a PSID reset on the drive to put it back into eDrive-ready mode. I think Crucial Storage Executive will let you do this, but it might need to be a secondary drive in another computer, or boot from USB. And of course you will lose all data on the drive after the reset.

    The Microsoft "Support Escalation Engineer" called me back on Wednesday as promised, but he didn't have any new developments for me. We did confirm, however, that hibernate works normally and that if Bitlocker is turned off the system no longer freezes at the lock screen. He is apparently communicating all of this to the Bitlocker team. And I sent him a link to this discussion thread. I apologize for not responding sooner but I had other issues to deal with.

    As far as doing a fresh install of Windows to an eDrive, my experience using a Crucial M500 SSD is that all you need to do is a DiskPart Clean for the edrive to be recognized and hardware encryption to be enabled. To confirm this I recently did a fresh install of the 1607 (Anniversary Edition) ISO to my Crucial SSD and everything worked normally with hardware encryption enabled. The only problem was that waking from sleep would freeze the machine.

    The interesting thing I learned from doing this test is that when restoring the C: drive (the Crucial M500 SSD mentioned above) from a system image backup (made using the "Backup and Restore (Windows 7)" Control Panel tool) the eDrive functionality would no longer be enableable, Bitlocker would only do software encryption. I wonder if this phenomenon is related to the "wake from sleep" bug?

    I tried clearing my TPM and then let Bitlocker reassert ownership of it, which all worked successfully, but even then it still would not allow hardware encryption. My system image backups made before the Anniversary Update will likewise no longer enable hardware encryption once they are restored. Do you think this is by design, so that system images can no longer be deployed to new hardware (a replacement eDrive) but require a fresh install of Windows?

    Monday, September 12, 2016 10:18 PM
  • Looks like update KB3189866 has fixed this - well waking from sleep is working, still testing.
    Tuesday, September 13, 2016 10:54 PM
  • Looks like update KB3189866 has fixed this - well waking from sleep is working, still testing.
    Resuming from sleep also looks to be working for me! Thanks all for the help.
    Wednesday, September 14, 2016 12:07 AM
  • Same here, the update seems to have fixed it. There is a noticeable delay after wakeup, comparable to the BitLocker screen on boot, presumably as the drive is being decrypted. But at least it works. I don't see anything in the update details that could relate to this, there is a kernel fix and a lock screen fix. Wonder what the problem was?
    Wednesday, September 14, 2016 8:45 AM
  • It was unrelated to RST. The recent update (KB3189866) fixed my issue. I am re-encrypting my drives as I type this. 
    Thursday, September 15, 2016 11:31 PM
  • Are you using eDrive? It should not re-encrypt drive. It should use already encrypted data, and just exchange keys with SSD.
    Friday, September 16, 2016 10:11 AM
  • eDrive on my SSD, other two drives encrypted w/ software encryption. 
    Friday, September 16, 2016 10:36 PM
  • Glad it worked :)

    I've enabled hw encryption on mine too but had to reinstall windows with diskpart clean before install.

    Saturday, September 17, 2016 7:03 AM
  • The KB3189866 update fixed my sleep/login issues as well.

    However, the system image restore problem which I mentioned above still remains. Bitlocker will not re-enable hardware encryption after successfully restoring a system image to an SSD eDrive. So even though Windows 10 Anniversary Edition hardware encryption/sleep/login is now working again, I have no way of restoring my previously backed up system to a hardware encrypted state! 

    I have written up my testing experiences and procedure for reproducing this problem as a new thread here: Hardware encryption is not enableable after a system image backup is restored

    Saturday, September 17, 2016 4:15 PM
  • Evan after applying for KB3189866, my Windows 10 continues to reboot from the sleep and hibernate modes.  Please help.
    Saturday, September 24, 2016 4:33 PM