Windows 10: Build 9879 trashing hard drives!

I'm starting this thread because of the large number of HDDs I have lost since updating to Build 9879.
The drives I have lost are all Seagate ST1000DM003 1 TB drives, 2 were VERY new (less than 2 Weeks old) and one was only about 2 Months old. The new ones got exchanged at the store and Seagate replaced the older one.
I have also seen posted (see the "I lost 2 Hard Disks after updating from Build 9860 to 9879" thread).
Would everyone please use this thread to post HDD losses.
o0k00l had a suggestion about downloading hiren CD, booting mini XP and using its Disk manager to try and fix the drive, well, it WORKED! Nothing else had worked to include Win 7 Pro Disk Manager, Win 8.1 Pro Disk Manager, Seatools for Windows, Seatools for DOS V2.23. My score currently is 4! 3 Seagate drives trashed/replaced and 1 trashed but restored.
It appears that something in the ST1000DM003 family of Seagate drives is being changed that makes it appear to be trashed.
I have reduced my participation from 2 machines (2 drives each) down to 1 machine, 2 drives (both WDC)
*Mad

:)

 

My hard drive became a brick after installation of Win 10

Try removing power—or worse yet, Windows Update suddenly deciding to force reboot your machine—during a firmware update. That will do it every time. And then there was the
Windows 10 PUIS disaster.

 

How to use Windows 10's built in Hyper-V for creating Virtual Machines

A new build has been available since November, called build 9879:

http://windows.microsoft.com/en-us/windows/preview-iso-update?os=win10

 

Tried Win 10 on 3 different machines and had no trouble with harddrives

 

Try using a VM instead. *Smile

I'm running a W10 TP VM using the latest VMware Player (on Linux Mint 17).

 

See this

Build 9879 hard drive disaster (read this) - Microsoft Community

 

As with most folks on this forum, it is hard to accept an OS would trash (render unusable) a hard drive. So I will take you at your word and assume something has gone wrong with the specific drives.

But I need specific information in order to even speculate as to what might be happening. For instance, exactly how was the drive being used and what was its history? Were you installing Windows 10 on that drive or was it a secondary drive? Were you updating from a prior build of Windows 10 and the system ran fine before the latest attempted update? Did the update succeed and the drive failed after some period of time?

Was the drive using the MBR or GPT configuration?

What exactly was happening to make you think the drive was trashed? Did it refuse to boot, or started loosing data which led to chkdsk running to repair?

If you no longer have one of the problem drives, if one does fail again, please post the bad drive specific information then.

Also, how was the drive connected to your system? An internal SATA port, and I am assuming you are using a Desktop.

I will also be needing pictures of the Disk Management window with the drive attached, and a DiskPart readout detailing the drive.

 

Saltgrass, please read the link provided by pbcopter above, It appears be be what is happening.
As far as my system(s) go, first time it happened, everything was going fine, installed on the first build (don't remember the exact number) and everything was fine - got everything configures on 2 machines, both with ST1000DM003 drives as C:\. Went through the upgrades to xx60 and still everything fine. Finally, both were upgraded to 9879 and worked OK for a day or so. Evening came and I shut both machines down (via desktop menu to power off). Morning came and I powered both machines up and NOTHING. Both C: Drives are dead, failing to pass any testing (on Win 7 Pro, Win 8.1 Pro, Seatools for Windows, Seatools for DOS) Seatools for DOS did see the drives, however, ALL tests/operations failed, presenting failure codes. One drive was Brand New, the other 2 months old - Store replaced the new one and Seagate provided replacement for the other.
Second time around - Re-installed from scratch from the original DVD, this time using the ST1000DM003s as secondary drive (D:\). Again, installation from the original DVD, upgraded to xx60 and finally to 9879. One failed with the same symptoms, again, almost brand new and store replaced it. Second one failed not too long after, simply stopped responding. All tests similar to previous ones. This time, I followed advice from o0k00l about downloading hiren CD, booting mini XP and using its Disk manager to try and fix the drive. This worked and the drive is OK now.
That gives a total of 4 Seagate ST1000DM003 1 TB drives that failed! NOTE that these drives are the newer ones, slim, only about 3/4" thick. All of my systems run 64 bit. I have one of these drives used in Win 8.1 Pro (E:\) in use for months with NOT issues. I have two of these drives used in Win 7 Pro (D:\, E:\), again in use for long periods of time with no issues.
My current status is to only use older WDC drives for the Win 10 testing.
I have also been using 2 of these Seagate SD1000DM003 drives for testing Fedora 21 Alpha and Beta, again with NO issues.
I'm going to read into that link from pbcopter above and see if that is what is causing the issues with the Seagates.
Last point, everything was fine until just after the upgrade to 9879 and the Seagates never lasted more than around 2 days before failure.
All drives are being used as internal on Kingwin SATA carrierless hot-swap trays.
2 drives used as C:\ failed at the same time
2 drives used as D:\ failed one day apart (the second one I had kept 9879 from installing for a time)
All drives (to the best of my knowledge) are being configured as MBR.
Again, ALL testing/repair attempts on these drives failed until the Hiren's CD was downloaded Hiren's BootCD 15.2 - All in one Bootable CD » www.hiren.info, booting its "mini XP" and using its Disk Manager to "delete the partition, then re-initialize the partition" NOTE again that all attempts to do this with Win 7 Pro/Win 8.1 Pro (both failed with disk I/O errors) and Seagate Tools FAILED.

 

Do you have a model number for the Kingwin device. I can go out and get a Seagate drive that matches yours, but I cannot duplicate that type of install.

Once I have the model number of the hot-swap trays, I may be able to determine if Windows 10 is having a problem with those devices which might be causing the problem with the actual drives. What drivers are you using for the onboard SATA controller and the Kingwin device? Maybe testing without using the Kingwin device would be helpful.

Hot-swap drives are handled a different way than permanent drives, so you might check the properties for the drives to see what policies are used. I have your same drive in a Dell AIO, which is not running Windows 10, and it shows the box for Enable write caching is checked and the Turn off Windows Write-cache buffer is not checked. You might also check the Events tab to see if anything strange is showing.

 

The Kingwin device is KF-1000-BK and sells for around $15-$16 at Fry's or $25 at Micro Center.
The drives are ST1000DM003 and Micro Center sells them currently for $56.98 (Not available at Fry's)
The Kingsin hot-swap device is simply a straight through connector that allows you to dock in a SATA drive without any special carrier or anything and functionally is is the same as if the drive was directly mounted inside the case.
I use them so that I can have multi-OS capability without the hassle, simply shut the machine down, remove the drive(s), insert the new Drive(s) and boot up. I use (all 64 bit) Win 7 Pro, Win 8.1 Pro, CentOS 6.6 & 7.0, Fedora 20 & 21.

 

"As with most folks on this forum, it is hard to accept an OS would trash (render unusable) a hard drive. So I will take you at your word and assume something has gone wrong with the specific drives."

There's no doubt in my mind that 9879 is trashing drives, to the extent that the drive doesn't even show up in the Bios and numerous BSODs. I ended up getting my drive back, but a lot of people would have given up. The drive was a brand new Kingston HyperX SSD.
It is now purring like a kitten with Windows 8.1. This had nothing to do with drivers or anything else, just 9879 pure and simple.

 

I see the drive listed at MicroCenter. I seem to remember being there some time ago and there were two Seagate 1 TB drives types available and one was smaller. The salesman mentioned it only had one platter as opposed to more. The specs. seem to confirm this. So if you were only having problems with this one type of drive, I might think it was that specific drive.

BillyBob seems to indicate all drives are having a problem with 9879, but my Z87 system is running fine and not had any drive problems. Maybe having some specific information about the condition of the drives after they crash would help clear things up. But 9879 is having other problems such as BSODs due to Video drivers, so it could very well be having drive problems. Maybe he would attach his small dump file.

 

seems to indicate all drives are having a problem with 9879, but my Z87 system is running fine and not had any drive problems. Maybe having some specific information about the condition of the drives after they crash would help clear things up. But 9879 is having other problems such as BSODs due to Video drivers, so it could very well be having drive problems. Maybe he would attach his small dump file. I sent details to Microsoft, plus they should have the info from numerous BSODS from error logs. I'm not saying that ALL drives are having these problems, I've been around long enough to know that it could be a variety of conditions including different motherboards and video cards etc.

The ONE common denominator here is build 9879, I'd say Microsoft has done a major shift with this build, hence all the problems, they have even admitted to the problems. When I talk about trashing drives I don't particularly mean damaged beyond repair in all cases, but certainly severely damaged to the extent that a lot of people would throw out their drives.

I was going to take mine back and claim it under warranty, but having repaired hundreds if not thousands of computers and HDDS in the past, I pretty well knew I'd be able to breathe life into it again, which I did.

I was going to check out the error logs, but in the end couldn't be bothered and ended up removing the partitions and letting Windows 8.1 do its own partitioning and formatting.

Im not blaming Microsoft, they made us aware of the problems with this beta software. I'm just pointing out that this is not some failure of HDDs its 9879.

 

Saltgrass, It is not only the Seagate drives that I use (ST1000DM003) but others as well.
Browse through the thread "I lost 2 Hard Disks after updated from Build 9860 to 9879" in this same "Installation & Setup" category and you will see references to multiple HDDs as well as SSDs. I started this thread because of those and the fact that I lost 4 Seagates Very quickly after upgrading to build 9879. Other people are having this issue also and does appear to be related to newer technology drives and possibly the PUIS (Power-Up In Standby) feature, very possibly because Build 9879 is sending the drive an instruction to go to sleep (or something) but never sending the proper "wake up" command. All other OSs and test software are not properly "waking up" the drives except, possible, a Linux "live" distro as mentioned in the link already provided. I would think that someone in MS should be able to decipher this issue if they really put some thought to it.

 

Latest on these HDD failures:
The following HDD had failed while set as:
Windows 10 Technical Preview, Build 9879
Drive selected:
Model Number: ST1000DM003-1ER162
Serial Number: Z4Y0FGDW
Firmware Revision: CC43
Transport: Serial, SATA 1.0a, SATA II Extensions, SATA Rev 2.5, SATA Rev 2.6, SATA Rev 3.0
Drive inserted as E:\ and tested
Machine rebooted several times, drive OK
Machine shutdown and restarted several times
after approx 3-4 shutdowns, Drive NO LONGER recognized.
Disk Management suggested initializing the drive which failed with:
"The request could not be performed because of an I/O device error"
Shut the machine down, removed the Windows 10 HDD C: & D:
Booted up the machine with a CentOS 7.0 disk and ran the following command
# hdparm -I /dev/sdb
(The drive that had failed under Windows 10)
Note that the results show that:
Power-Up In Standby feature set shows "Enabled"
Ran the following command to turn that bit off:
# hdparm -s0 /dev/sdb
The system response was:
"spin-up: setting power-up in standby to 0 (off)"
Again issued # hdparm -I /dev/sdb
This time the Power-Up In Standby feature set show "NOT Enabled"
ANOTHER NOTE: This Linux (CentOS 7.0) had absolutely NO problems accessing this drive and I have NO doubt that ANY windows machine would NOT recognize the HDD with this PUIS bit set.
NOTE 2: the entire results of the these tests are available if desired.
Removed the drive from the Linux machine & inserted it into Windows 7 machine:
Drive was IMMEDIATLY recognized for the drive as it was before the failure:
NOTE: This has to PROVE that Build 9879 is setting this Power-Up In Standby feature
even though the Motherboard does NOT support it, thereby keeping the HDD from
spinning up and giving all indications of a HDD failure.
MB is Gigabyte GA-Z68MA-D2H-B3, Rev 1.3, CPU - i7-2600
Also happening on MB Gigabyte GA-X58A-UD3R, Rev 1.0, CPU - i7-930
Link to relevant information:
Post by pbcopter in the above thread which shows the same issue and linux commands to recover the HDD.
Build 9879 hard drive disaster (read this) - Microsoft Community

Feedback provided to Win 10
Build 9879 is killing newer technology HDDs & SSDs....9879 is setting the PUIS (Power-Up In Standby) feature even though the MB DOES NOT SUPPORT IT causing the drives to spin down and nothing in Windows 10/8.1/7 will recover it. I have complete test results for the HDD failures if I could figure out a way to attach a text file.