Windows 10: Build 9879 trashing hard drives!

An additional note:
Tried this from WightWalker, Windows 10 Forums-Installation & Setup-I lost 2 Hard Disks from Build 9860 to 9879.
-Control Panel-Power Options-Choose what the power buttons do-Change settings that are currently unavalable
-Un-check "Turn on fast startup (recommended)"
-Rebooted.
-Re-added one of my ST1000DM003 HDDs to test.
Shut down & booted several times and after about the 3rd time, the drive failed AGAIN!
My previous post shows that this is apparently being caused by the PUIS (Power-Up In Standby) activation being done by build 9879, and does not appear to have anything to do with the "Turn on fast startup" for Win 10 (and 8.1) because I just checked my 8.1 settings and it is set to Enable that "Turn on fast startup" and I have one of the suspected drives installed for a long time with no problems.

 

I certainly agree with the comment about 9879 being a big problem, and not even for the same reasons mentioned.

I have no familiarity with the situation you are demonstrating, so I will have to do some research. I do have an ASUS Z68 motherboard and a 500 GB Seagate drive, so I will set that up to see what happens. If the problem seems to present on relatively older boards, maybe my board will present also. I will also try a newer drive since your post mentions it is presenting on advanced tech HDDs.

Just a question, in the Power options, what do you show as to when the drive is put to sleep? I think the default is 20 minutes. Also, what do you show for your Sleep settings, such as Hybrid sleep or hibernate? This may not be involved, but it does seem the system returning from sleep is involved.

Also, what does the powercfg /a command show as available sleep states?

Edit: This is the first website I checked and seems to have some pertinent info. Are there tools or jumper settings on the drives to disable the PUIS or PM2 option? Have you tried using the RAID controller instead of the AHCI controller?

Power-up in standby - Wikipedia, the free encyclopedia

HDD Power-Up In Standby (PUIS) feature to block non-system disks spinup at PC wakeup - Tutorials - reboot.pro

 

The system is set up with a primary WD drive and secondary Seagate 500 GB. I will let it do its thing to see if one of the drives develops the problem.

I noticed my WD drives all have a message on the front saying to enable PUIS you would need to jumper pins 3 and 4. The Seagate drives have no configuration pins, so if it were to be a factor, probably some software utility would be needed to set that option, if they even had such an option.

I notice another soul on the Microsoft site has lost their secondary drive and it sounds like what you guys are seeing.

 

The "Turn on fast startup" feature in Win 10 (and Win 8.1) apparently have nothing to do with the drive failures.
The one piece of concrete information is that after the HDD fails, inserting it into a linux machine and inspection with the hdparm command does show that the "Power-Up In Standby" feature for the failed drive shows ENABLED and reseting this feature to DISABLED, again with the hdparm utility "fixes" the issue. Then inserting the drive into a Windows machine shows that it is fine, no issues, all data intact.
I have downloaded the Build 9879 iso file and I'm going to test one more time in my smaller machine (i7-930) with a WDC SATA2 HDD for C: and one of the ST1000DM003 as the D: drive. I'll post results as soon as I have any.
BTW, I have my machines to "Never" Put the computer to sleep, just Turn off the display after 10 minutes.

 

OK, keep the info coming when you get anything new. I was wondering if the system just putting the Hard Drives to sleep was all that might be necessary for the problem to develop.

Also, since they made some changes to One Drive in the latest build, do you use and sync with One Drive?

 

I'll keep info coming as it develops.
Actually, I prefer to NOT use One Drive. Everything was fine in the first 2 builds where you used the gpedit.msc to change to not save to OneDrive, but in 9879, you have to do an extra step, go into Task Manager-Startup and Disable OneDrive startup, otherwise, it always shows as running and it still insists on showing in Windows Explorer. I have my own NAS devices here locally (Buffalo 2 slot units) that I keep for data & other stuff.

 

I need you to confirm you are not using UEFI for your install. If you are, opening Disk Management and checking if there were a EFI system partition would verify you are using UEFI. If you show a System partition, which is Active, you are using an MBR configuration.

I have not seen any problems so far with the clean install of 9879 and the drives connected. I will run it through tomorrow to make sure, and after that, I might change the install to MBR to see if that might allow the problem.

Again, if you find any specifics about what the condition causing the problem, please advise. I do seem to see folks loosing there drives after an update and starting the system the next day.... But that was happening before 9879 came along.

 

Neither of the MBs that I am using for testing are even capable of UEFI. all are MBR.
My main MB is a Gigabyte GA-Z87-D3HP which is capable, but I have Win 7 Pro installed (which is NOT).
I did download an iso of build 9879 and installed on the one system:
-C: is WDC SATA2 WD2500KS 250 GB and then added 2 of the ST1000DM003s that I have been having trouble with for D: and E:
I also added 2 of the drives to my other installation (which has been upgraded from the original).
Couple of them were in the state where they would not spin up, docking into the linux system and reseting that PUIS feature to off, inserting into the Windows 7 machine and allowing Scan & fix when requested got them working.
Not had any issues so far today, it's almost like something got 'fixed' in the build without anybody saying anything!
I am ABSOLUTELY convinced that Build 9879 has been the culprit because I have been using these drives for months in a Win 8.1 Pro system (1 drive), a Win 7 Pro system (2 drives) and one in my main Win 7 Pro system that has been in-service without a hiccup since I bought the parts (1 Feb 14), assembled and brought the system up. In fact I have NEVER had any issues with any previous Seagate drive of the same family (ST500DM002 & ST1000DM003, 500 & 1000 GB) & I have multiples of each of these drives. The main reason that I have the 1000GB drives is that you can't find the 500's any more.
I did verify with one of the problem drives yesterday that with that PUIS feature enabled, the drive does not even spin up. It needs to be inserted in a Linux system and have that feature turned off. NOTE that the Linux system has NO problems bringing up and communicating with the drive that has that feature turned on - In the SAME system, simply shut down, swap main drive to a Linux distro and booting up.
It's starting to make me wonder what the Linux community knows about this feature that the MS Windows programmers don't!
*Banghead

 

OK, I will go reload my system for MBR and use the 500 GB Seagate drive. Maybe that will show something. It is nice a workaround has been found, but the basic cause needs to be eliminated. The 9879 build does change some things, none of the other builds did. Maybe they are working on the Native 4K drive technology, I am not sure.

I have also ordered two of your same type drives for testing. Since some folks seems to state is actually happens just after an update from 9860 to 9879, I will start with 9860 this time.

Hopefully your drives continue to work normally from now on.

 

I also find it hard to accept these problems.
The two systems I am using for testing are:
1. Gigabyte GA-X58A-UD3R MB, i7-930 CPU, 12 GB Memory
2. Gigabyte GA-Z68MA-D2H-B3 MB, i7-2600 CPU, 16 GB Memory
Both systems use KingWin KF-1000-BK 3.5" Internal Tray-less Hot Swap Racks, 1. has 3, 2. has 4
OSs used include:
- Win 8.1 Pro
- Win 7.0 Pro
- Linux Distros
-- CentOS 6.6 & 7.0 (Red Hat Enterprise Linux clone)
-- Scientific Linux 7.0 (Red Hat Enterprise Linux clone)
-- Fedora 20 & 21 Beta (RHEL bleeding edge development)
To change the OS, simply shut down the existing system, remove the HD, insert other HD and boot up - New system!
While I have lost a hard drive "occasionally" (probably 1 every 3-4 years!) I have been simply astounded by number of issues that Windows 10 Tech Preview have unleashed on the community!
As far as I'm concerned, this is entirely due to the attempt to use the "Power-Up In Standby" (PUIS) feature that apparently requires the MB support, Drive Support as well as OS support.
A Drive with that feature "enabled" and plugged into an external docking port simply "DOES NOT SPIN UP". It takes inserting that drive into a linux machine and disabling as shown in previous posts, then, it either works fine or "requests Scan & fix" and is OK after!
Another thing that can't be stressed strongly enough to anybody contemplating testing this system - DO NOT USE ON CRITICAL DATA". In other words, if you can't afford to lose it, DON'T DO IT!
I'm going to post this here (I lost 2 Hard Disks after updating from Build 9860 to 9879) and (Build 9879 trashing hard drives!) to get the most exposure.

 

OK, I think that I've had about enough for this year. The installation on my i7-930 machine is doing just fine, shut down, restart, & everything, however, in the i7-2600 machine, I am to the point that I can't even shut the machine down, reboot and the Seagate drives have failed again. (PUIS enabled, drive(s) NOT spinning up).
With the news that no new builds are due until at least after the end of the year, I'm gonna wait until the "Consumer Preview" is released & try again, besides, I have plenty to keep me busy with Fedora 21 Final being released in early December!!
BTW, I have re-enabled all of the problem drives with Linux commands, not lost anything.

 

Wen the new drives come in, I will continue testing for a while. I will not use RAID as a SATA controller since yours does not seem to be in that configuration.

I will post back if I notice anything. I am already waiting for the next build since I cannot use my Nvidia video cards in 9879.

 

I got those drives today, the Seagate ones. I installed one and put 9879 on it. Things seemed to go normally and the system restarted and rebooted without any obvious problems.

I then attached the other new drive as a secondary drive, but even though it showed up in the Boot Device Menu, it would not show up in Disk Management or Diskpart.

I took the new drive out and put it in a caddy on another system. It showed up as uninitialized, which I would have expected. I did not try to initialize it.

I then replaced the original Seagate drive with 9879 with a WD drive with 9879 and the drive showed up.

I suppose because the drives are exactly alike, Windows is not seeing the second one, but that is only a wild guess. I will do more testing tomorrow to see if I can initialize the drive and get it recognized.

 

In reference to your post, any new HDD will need to be "initialized" and and then set up as
a drive for Windows to recognize it.
Detailed instructions to fix PUIS issue with linux.
I am using Fedora 20 here because that is the linux flavor that I am familiar with.

First, get a copy of Fedora 20 from:
Fedora Project Homepage
From this web page, select "Download Now".
This should start a download of "Fedora-Live-Desktop-x86_64-20-1.iso"
Save it to a location you will be able to find later.
While I use Nero to burn an image to DVD, Windows 7 should be able to burn it directly.

In order to recover a "non-responsive" HDD, use the Fedora Live DVD to boot the system.
Best thing to do will be to remove all HDDs except the one that is suspect when you boot up.
Boot the DVD, select "Start Fedora Live"
Once the system comes up, click on the "Try Fedora" box
It will present a window informing you that you can "install to Hard Drive" later, click Close

Click on "Activities" in the upper left hand corner and click on "Show Applications" at the bottom of the list.
Click on "Utilities" box and select "Terminal"
In the terminal, enter "su -" (without quotes, password is not required here)
You will be presented with root prompt [root@localhost ~]#
enter "yum install hdparm" (the hdparm utility is not present initially and must be installed)
System will prompt for verification, enter y <Enter>
hdparm utility will be installed.

If you only have one drive (the problem drive) then enter
hdparm -I /dev/sda
This will present you with all of the information for the first HDD in the system.
If you have multiple drives installed in addition to the problem one, then:
hdparm -I /dev/sdX (where X is the letter of the drive, a for first, b for second, etc
You can tell you have the correct drive by inspection of the Model Number/Serial Number, etc.
Scroll down to see the "Commands/features:" and find "Power-Up In Standby feature set"
Another way to see that directly is:
hdparm -I /dev/sda | grep Power-Up
If you see an Asterisk in front of this entry, then the feature has been "Enabled"
and while the drive powers up in a windows system, it will NOT spin up.
This is where the problem lies, the MotherBoard is NOT compliant with this feature
and the HDD will appear to have Failed!

The fix (to make this drive available to any windows system) is to enter the following:
hdparm -s0 /dev/sda (again, make sure you are specifying the correct drive)
This will "reset" this feature for this drive (at least until Win 10 sets it again!)
you can then verify by: hdparm -I /dev/sda | grep Power-Up
Warning here, linux is case sensitive so Power-Up is NOT the same as power-up

Here is a copy/paste from the HDD in my other system that has been "set"
note that I am working on the second drive, /dev/sdb
=========================================================
[root@localhost ~]# hdparm -I /dev/sdb | grep Power-Up
* Power-Up In Standby feature set
[root@localhost ~]# hdparm -s0 /dev/sdb

/dev/sdb:
spin-up: setting power-up in standby to 0 (off)
[root@localhost ~]# hdparm -I /dev/sdb | grep Power-Up
Power-Up In Standby feature set
[root@localhost ~]#
=========================================================

NOTE: If you identify a drive that has this issue and is being "enabled" by Win 10, the only "fix" that I am aware of is to NOT use that drive in a Windows 10 Tech Preview installation until such time as MS fixes it properly!
Final note: I did check out a Seagate 500 GB drive, ST500DM002 and that drive does NOT have that feature included so that drive should be safe to use without fear of losing it.

 

I do understand how a new drive will look when placed on an install. The fact this drive does not show up at all on this install is the situation which seems to agree with your results.

I am going to initialize the drive on another system to see if it will show up then on this one. If I understand an earlier post, I will not be able to accomplish the initialization and will need Linux to repair the other drive. I will let you know in a few minutes if I was able to initialize the drive.