Windows 8.1 has  a catastrophic bug regarding hard disks that really needs to be addressed and corrected.  

There are 1000s if not 10s of 1000s of internet threads with people experiencing the same problem.  Its amazing this problem has been around for years.  Several versions of windows has this problem.

 
I upgraded my BIOS and the BIOS upgrade software didn't save the cmos settings. My SATA disk controller was previously programmed with a RAID 10 configuration in hardware.  What happened was the Controller defaulted to non-RAID.  Windows in its attempt to be smart ended up being really incredibly stupid.  Windows assumed the hardware configuration was correct and the RAID disk configuration was wrong so Windows decided to corrupt and wipe out my Master Boot Records without my permission.  It made 2 disks of the 4 disk RAID into non-RAID disks and zeroed out the MBR of the RAID partition.
 
Windows should never assume the hardware is correct and the disks are wrongly configured.  In my case it was just the opposite my disks were correctly configured and the hardware was incorrect.  This is a catastrophic bug with Windows.  Windows should never automatically change the MBR without user permission.  Windows could put up an interactive screen to let users know there maybe something incorrect with the hardware settings to give user a chance to correct issue before  destroying perfectly good disks.  Microsoft should correct this error with a patch and future versions.

The software should allow users the option to save the MBR information to USB flash prioer to overwriting with the ability for the user to revert back by reloading the saved MBR information.  This kind of software should not be difficult for the Windows developers to do.  Please forward to the Windows software engineers to see if they can close this bug. 

The question is how can I get my 4 RAID disks MBRs repaired so the RAID 10 will work again?

I have 4 new virgin disks of same size, brand and can re-install those and redo the RAID 10.  IF I save the MBR info for the RAID10  physical disk can I write the MBR info to the old disks and zero out the MBR of the 2 non-RAID disks?  Will that allow me to salvage my RAID 10?  

I can manually hand edit the values via a disk editor.

For a RAID10       DISK0      DISK1     DISK2    DISK3 
I know the first DISK0 there is a MBR and some start end cylinder info.

 DISK0    MBR       Does DISK  1 , DISK 2 and DIKS 3 have anything  in their MBR for a RAID or are these values zero?

What storage controller was used to create the RAID 10? Different storage controllers configure RAID in different ways. Is the data still accessible? The surest way to get your system configuration back is to create an image based backup of your current configuration and to restore that to a RAID 10 configured with the new disks.

You may need to contact the storage controller manufacturer for specific information regarding the configuration of RAID on their controllers. It may be possible to re-write the RAID configuration and have the disks detected as RAID 10 once again, but only the controller manufacturer will be able to provide that information.

Brandon
Windows Outreach Team- IT Pro
Windows for IT Pros on TechNet

Intel SATA RAID controller on Gigabyte motherboard.  

The issue is not about recovering or restoring the data.

The issue is WHY does this even happen at all on 100% healthy disks? Windows sat and spun with message about correcting error.  It should not. After words RAID disk was shown as uninitialized.   After a very complicated and painful exercise I was able to delete the raid configuration and recover all my data proving there was nothing wrong with the disks in first place.  This happens 10s of thousands of times to people all the time with perfectly good 100% healthy disks.  Please work with the BIOS vendors and Intel Sata Raid controller engineers and fix this once and for all instead of sweeping it under the rug. and give some speech about how to recover the data.

I believe the hardware has a combinational logic that has a a charge or race condition that causes a glitch.  The signals should be latched to get rid of the glitch.  I remember 20 years ago doing silicon debug where this thing happened and was solved by latching the signal.