Build 9879 trashing hard drives!

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!

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.

Saltgrass said:

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.

I am back and the drive initialized fine and I put a partition on it using another install.

When I first put it back in the original Seagate install, it again was not seen by Windows.

I rebooted and all of the updates were installed, which includes one for December, and now the drive is recognized with the correct partition information.

I will let this system run for a few days to see if anything goes wrong, but I cannot really come up with an accurate description of exactly what happened. Maybe the update fixed the problem so it will not longer occur.

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.