Help with Windows 10 data integrity issues - ReFS, Storage Spaces, Copying files

UPDATE Solved - it was RAM - read the post further down this page for more info.

Short version
I'm having an issue with my home PC. My mirrored storage space using ReFS on Windows 10 technical preview doesn't appear to be working reliably, in that Macrium Reflect images often fail to verify.

Long version
Background: I take Macrium Reflect Free images of my operating system drive in order to recover quickly if something goes wrong. I run Reflect from a WinPE USB boot memory stick and image onto a standard Seagate NTFS drive. The images almost always verify as "ok" both in WinPE and when I boot into Windows. I assume the Reflect "verify" (which is slow) uses a CRC or MD5 type checksum.

I have Windows 10 technical preview, with HGST 4TB x 2 set up with ReFS and a mirrored storage space. I have this setup as I value data integrity, I like the idea of automatic checksums and error correction. I copy these OS images (20GB or so) to my ReFS SS disk using Teracopy, with the "verify" turned on. Verify uses a CRC to check if the destination file is the same as the source file

The problem: Around 1/3 to 1/2 of the time the Teracopy verify reports "CRC failure". Strangely though even if a CRC failure is reported Macrium Reflect images sometimes verify successfully. Sometimes if there's no CRC failure in Teracopy and the Reflect images fail to verify.

I will have to do some systematic testing between each of my many disks to help pin down whether it's just the ReFS disk or it applies to other disks too. I can say that I have plenty of Reflect images fail to verify on my standard Seagate NTFS disk, both old and new images. The couple of Teracopy copies and Reflect verify tests I did to the Samsung 840 pro SSD last night passed CRC and Macrium verify.

I occasionally get messages like this in my Windows event logs, though it doesn't tend to show when I get CRC or Reflect verify errors.

Text: The file system detected a checksum error and was able to correct it.
Source: ReFSv1
EventID: 132

I've run both memtest x86 and the Windows 10 RAM test with no errors at all. I've run Prime95 for a day with no errors. The Intel CPU testing system comes back perfect. I've run another couple of testing problems.

The question: I guess I'm asking for any thoughts, opinions, experience, ideas on how to test the machine, or anything else really. Are there hardware testing programs I can use? Is there software that will write files to a disk then read it back to check it's written/read properly? Should I be using a different version of software or hardware RAID? I know a ZFS NAS is another option but I don't want to have to build another machine for this.


Computer specification:
- Gigabyte GA-P67A-UD3R-B3 Motherboard, Socket 1155, Intel P67 motherboard
- Intel Core i7-2600K 3.4 GHz, Socket 1155 (running at stock speed)
- Gigabyte GV-N520OC-1GI, GeForce GT 520 Video Card, 1024MB
- Corsair Vengeance CML16GX3M4A1600C9, 4x4GB, DDR3-1600
- Antec High Current Gamer HCG-520
- Nocuna CPU cooler - I forget the model but it has two 120 or 140mm fans
- Seagate 1TB x 2, NTFS
- HGST 4TB x 2, ReFS with mirror storage space
- Samsung 840 pro 120GB running Windows 10 technical preview
- OWC SSD 120GB

Considering Win10 is still in beta, I'm not surprised you're having some issues. Beta software, especially operating systems, should never be used on a production environment.

Do you have a copy of Win7/8 you can install on a separate hard drive? If everything else works fine under Win7/8 then the only remaining sources of problems would be something physically wrong with the hard drive with Win10 or a bug with Win10 itself.

It's in technical preview, not beta, and it has 20 years of evolution behind it - it's not a 1.0 product. But yes I take your point, I will reinstall W7 and run some tests, see if it suffers the same problem. Unfortunately I can't access the ReFS SS drives using W7, I'd have to be on 8.1, and I'd rather not have to pay for that given W10 will be a free upgrade.

I'll also use the tool "badblocks" to see if the drives are faulty.

Honestly something put out by Microsoft is in "Technical Preview" until SP1 for a OS. I would say that ReFS is still an infant product with bugs. Bugs go both ways, ReFS might be fine for everyday use (and it is) but how certain programs access those block data might not play nice with it. I dont see it explicitly stated on the Macrium Reflect website that it officially supports ReFS or Storage spaces. Im not sure how Macrium Reflect works but it might be a problem between how windows 10 accesses at the block level through the VHD in storage spaces.

tim wrote in post #17451099
It's in technical preview, not beta, and it has 20 years of evolution behind it - it's not a 1.0 product. But yes I take your point, I will reinstall W7 and run some tests, see if it suffers the same problem. Unfortunately I can't access the ReFS SS drives using W7, I'd have to be on 8.1, and I'd rather not have to pay for that given W10 will be a free upgrade.

I'll also use the tool "badblocks" to see if the drives are faulty.

Would be interested to see the results with W7. If you can let me know your build number for W10 and give me some data then i can socialise it with some of the W10 team and see if anyone bites. Can't promise anything and ReFS is probably considered an edge case, but happy to try on your behalf..!

I'm going to reinstall W7 next week and test. It's not ReFS, the same problem occurs between two NTFS disks. I'm starting to suspect hardware.

I think the problem is a P67 chipset bug - details here.

Try to use some Linux Live CD to access data stored on ReFS partition. Linux supports much more file systems than Windows, so it may help.

tim wrote in post #17451099
and it has 20 years of evolution

The only thing it has in common with evolution is the colour blue

A motherboard replacement seems to have fixed the problem. It probably was the chipset bug I posted a link to above. Solved!

Update - it was faulty RAM.

Corsair replaced the RAM, which is a bit over two years old, with new RAM that has the same model number. Great service from them I have to say. A couple of hours of testing that easily reproduces the problem with the old RAM has found zero errors. So my conclusion is it's the RAM.

I find it very strange that the old RAM works in pairs but not two pairs, and that memtest x86 doesn't find any problems testing either individually, in pairs, or in fours. HCI Memtest did find errors, but only at 300% - ie after testing the memory three times. The way I found the errors is to use H2TestW and Teracopy in verify mode.

So the moral of the story is if you get data corruption, replace the ram, even if it tests fine.