Windows 10: I lost 2 Hard Disks after updated from Build 9860 to 9879

Windows 10T, like it's predecessor Windows 8, is designed to close & reopen faster by booting - Hybrid Boot.

It has left your system in a hibernated state, with the drives mounted, open and ready to take off as soon as Windows 8/10 restarts. When a drive is mounted, a little piece of data is written to a standard place on the disk to show it is in use - it is called the "dirty bit" which is what Windows checks for during start-up & then initiates the CHKDSK sequence.

Settings to disable Hybrid Boot:

1. Control Panel -> Power Plan
2. Select "Choose what the power button does" on left hand side.
3. Click on "Change settings that are currently unavailable".
4. Uncheck "Turn on fast startup" under shutdown settings.

 

Here is my latest understanding of this issue:
Issue: The apparent multiple failures of HDD and SSD drives in Build 9879
It appears that the issue with Win 10 and HDD and SSD apparent failures
is that attempts by Win 10 to use the Power-Up In Standby (PUIS) feature
on a HDD (or SSD) that is capable of the feature without verifying that
the MB BIOS is compliant.
Conditions:
- Build 9879 updated or installed with from the Build 9879 iso.
- ANY HDD (or SSD) that is capable of PUIS functionality
-- In my case, Seagate ST1000DM003 Hard drive (Which is PUIS capable)
- ANY MotherBoard that is NOT capable of PUIS functionality.
-- In my case, Gigabyte GA-Z68MA-D2H-B3, Rev 1.3
-- and Gigabyte GA-X58A-UD3R, Rev 1.0
###########################################################
NOTE: Here is an extract and WARNING from MAN page for linux hdparm command:
--------------------------------------------------------------------------
-s
Enable/disable the power-on in standby feature, if supported by
the drive. VERY DANGEROUS. Do not use unless you are abso-
lutely certain that both the system BIOS (or firmware) and the
operating system kernel (Linux >= 2.6.22) support probing for
drives that use this feature. When enabled, the drive is pow-
ered-up in the standby mode to allow the controller to sequence
the spin-up of devices, reducing the instantaneous current draw
burden when many drives share a power supply. Primarily for use
in large RAID setups. This feature is usually disabled and the
drive is powered-up in the active mode (see -C above). Note
that a drive may also allow enabling this feature by a jumper.
Some SATA drives support the control of this feature by pin 11
of the SATA power connector. In these cases, this command may be
unsupported or may have no effect.
##########################################################
Windows 10, build 9879 is OBVIOUSLY attemting to activate/use this feature
on the HDD that has the capability without first verifying whether or not
the MB is capable or compliant with this feature - In this case, the MB
is NOT PUIS compliant and the hard drive powers up but does NOT spin-up
and appears to have FAILED.
The HDD appears FAILED in Windows 7, Windows 8.1, Windows 10.
A Linux system on the SAME MB is capable of seeing the drive and with the
hdparm command, to change the feature from Enabled to Disabled, thus,
restoring the drive to full functionallity without any data loss.
NOW, will the Windows 10 programmers ever see this or take any action on it or not.
There is apparently no way to attach anything into the Windows Feedback section.
*Banghead

 

Thanks for the above information.

I am right to understand that if the HDs haven't been jumpered to enable PUIS (default settings) with MBs that don't support PUIS, then this problem should not affect those users.

I assume that problem isn't relevant to SSDs as they have no platters to spin up, but believe that some users have experienced failure problems.

 

I'm not sure about other drive manufacturers, however, with Seagate, I have no jumpers installed (and no info about how to jumper them) and the Win 10 build is still "enabling" the Power-up In Standby feature which "enables" the feature on the HDD, which powers up the drive, but does not allow it to spin up with my MB which DOES NOT support it.
Microsoft needs to fix this so that other users are not affected no matter what HDD/SSD-Motherboard combination they have.
Again to emphasize, it is the MS Operating system that is at fault here.
Finally to emphasize again what my previous post says, "In order for this feature to work, 3 things are necessary: 1) Motherboard which supports it, 2) HDD/SSD that supports it and 3) Operating System that supports it" ALL 3 are needed!
If I understand your post correctly, if you have a drive that must be jumpered to ALLOW the drive to use the feature, then, it might not matter what the OS tries to do, BUT, That could be wrong also!

 

How much faster startup does this Fast Startup offer on the average HD? My SSD starts in 10 seconds, Resumes instantly.

How does it relate to Fast Boot setting in BIOS setup, or is that only to bypass verbose boot?

If Fast Startup is similar or same as Hibernate how does it affect Hibernate to turn it off?

Thanks.

 

MS appears to have listened and fixed this issue!
The "Windows Technical Preview December Update for x64-based systems (KB3021937)" patch appears to address exactly this issue: Windows 10 Technical Preview or Windows Server Technical Preview cannot resume from sleep or cannot start
After applying the patch, I re-installed one of the affected drives (ST1000DM003) in each of my 2 test machines.
After verifying that both drives were recognized and that a text file on each drive could be opened, I did the following process 10 times each:
--------
Shut the machine down (power off)
Power up, boot up the systems
verify the drive is still there
open the text file on the drives.
--------
On one of my systems, this issue had presented itself every time it was shut down.

 

I have more the less the same problem as reported by the OP. I believe it is the Win 10 trying to update after being shut down. The worst part is that I cannot disallow updating (choice greyed out). I have deleted Win 10 and I am to wait to get back in. Win 10 should allow choice of not updating indeed. That causes considerable problem by opening halfway the other harddrives.

Daniel , Toronto

 

I am going to wait. I installed windows 10 (forgot build), then update to build 9879. Every thing was fine. Suddenly after the computer slept, there was an error message on my screen saying that recovery was needed. However, my windows 8.1 install was on one disk (SSD) and my other two disks contained Windows 10 and some backup data (2 separate SATA disks). The attempt at recovery with my USB drive allowed me to go back to windows 8.1 and what I then discovered was two dead hard drives -- neither of which could be re-formatted, initialized or anything! So, I am going to wait to see what happens next. I have a separate install on a laptop computer with dual boot of windows 7 and Windows 10. The upgrade to windows 10 build 9879 was successful and has not crashed the computer. This time, the drive is a partitioned SSD drive being shared by Windows 7 and Windows 10. I will see what happens with this.

 

You have the same problem I reported. I reinstalled Win 10 and that revived the lost hd. Then I have deleted it entirely hoping later build will cure the "lost hard drive" issue

Daniel

 

You have the same problem I reported. I reinstalled Win 10 and that revived the lost hd. Then I have deleted it entirely hoping later build will cure the "lost hard drive" issue

Daniel My hard drives will not be recognized by my system bios now! They are seen by bios and reported as I/o error's, then Windows 8 will not initialize or format or anything else.

 

How does one apply the patch if the hard drive cannot start without booting a Linux disk first, and then it only stays booting until it is shut down. The actual Windows Update page for it (in thread below) says you get the patch as a Windows Update with no external download. Meanwhile I've reimaged the drive with Win7 which won't allow the update.

The hdparm tool run from another OS will neither confirm the drive has PUIS or succeed in turning it off. build 9879 bricking drives - Microsoft Community

But if the drives really don't have PUIS why are they symptomatic of the PUIS problem, e.g. booting a Linux disk allows them to boot and function normally until they are shut down. *Sad

Thus I have two Hitachi drives that are useless until I can figure out how to apply this patch.

 

Do not apply the patch. Install Wind 10 afresh and cure the 2 harddrives first.
I only have Windows10 via vitualplayer under ubuntu now. Foolproof

Daniel

 

Thanks Daniel. I can do this but wonder if the install will survive through the reboots. I guess I can keep booting the PW (Linux) disk to revive it until Win10 gets installed.

Will the latest build immediately cure this or do I need to do something else?

When will I know it's safe to remove 10 to add the other 7 image for roommates' Dual Boot?

 

Update - After installing Windows 10 latest build to a partition on the hard drive and fully updating it, the drive is still bricked needing after every Shutdown to boot a Linux disk to get it to start.

I'm confused whether the issue is even PUIS since when I run the command to see if it's enable it gives an error, as does the command to turn it back on.

 

Since I'm using a VM, I (obviously) don't have any HDD issues, have you:

• Checked if there are any weird options in your BIOS/EFI?
• Tried changing "Power Plan" are you using in W10?