It’s too early for the villagers to haul out their rusty pitchforks and oft-hoisted torches, but it looks like another Windows version upgrade has another data-eating bug. The bug infects Storage Spaces, Microsoft’s way of implementing RAID-like data redundancy by using standard hard drives.
Yesterday, Microsoft posted Knowledge Base article 4568129, which says in part:
Devices using Storage Spaces might have issues using or accessing their Storage Spaces after updating to Windows 10, version 2004 (the May 2020 Update) and Windows Server, version 2004. When using some configurations, partition for Storage Spaces might show as RAW in Disk Manager.
Within a few hours, Microsoft clamped down on distribution of the Win10 version 2004 upgrade to some affected PCs, showing the message:
This PC can’t upgrade to Windows 10. Your PC isn’t supported yet on this version of Windows 10. No action is needed. Windows Update will offer this version of Windows 10 automatically once the issue has been resolved.
Presumably the block appears on Win10 1809, 1903 and 1909 machines running Storage Spaces.
Attribute it to the “artificial” part of Microsoft’s vaunted rollout AI.
The scary part comes later in the announcement, which says:
We do not recommend running the chkdsk command on any device affected by this issue.
Of course, any experienced Windows user who encounters a suddenly faltering disk will crank up chkdsk.exe. Checkdisk has been around since the Days of DOS. And now we’re being told not to use it. There’s no explanation why, it’s just not recommended.
To understand what little has appeared online, you need to realize that Storage Spaces, a feature introduced in Win7, supports four levels of protection. When you set up a Storage Space, you tell Windows what level of backup protection (“resiliency”) you want. A Parity Storage Space setup, which protects you from complete destruction of a single drive, requires at least three hard drives. With a Parity setup, one of your drives can grind to dust, and you’ll still have full, uninterrupted access to all of your data.
I have had a Storage Spaces Parity storage space consisting of 4 WD Red 6TB NAS hard disk drives, formatted as NTFS, on a Windows 10 Pro workstation, for several years. After upgrading to Windows 10 Version 2004, within a day or two, I noticed the contents of some files were corrupt. A CHKDSK resulted in finding thousands of problems, such as “Attribute list entry with type code 80 in file 5E711 is corrupt” and “File record segment 67C08 is an orphan”. When CHKDSK completed, the file system was again consistent, but hundreds of files had incorrect content, despite their other attributes being correct (file size and change dates).
I restored the corrupt files manually from backup, and continued on for another week. Then, a Cumulative Update for Version 2004 was installed and the workstation was rebooted. Almost immediately after the reboot, I noticed corrupt files again. This time, CHKDSK (run in read-only mode) detected hundreds of issues. I haven’t tried to repair it with CHKDSK, as I’m afraid I’ll corrupt it further.
Based on the few posts I’ve seen, the bug only shows up on machines running the Parity variant of Storage Spaces.
In my experience, Storage Spaces isn’t common – and Parity Storage Spaces aren’t common at all. But that’s not much solace to someone who’s trusting Microsoft to support its own feature.
Microsoft has had all sorts of problems with hard drive and SSD management in Win10 version 2004 – Mayank Parmar on Windows Latest lists problems with creating Storage Spaces. He also shows that the Drive Optimizer defrag tool doesn’t keep track of dates and thus prompts you to run it too frequently. Günter Born, quoting Karl Wester-Ebbinghaus, reports that old problems with freeing data still haunt Storage Spaces; and that Microsoft has known about these bugs for a long time.
I haven’t yet seen any reports of Win10 2004 upgraders permanently losing data. But given the published warning about using chkdsk, it looks like we have another data-eating upgrade bug on our hands.
The last time a new version of Win10 inexplicably started chewing up data, with version 1809, Microsoft pushed the upgrade for four days before yanking it. Version 1809 went into the shop for four months, with the “oops, final final” version shipping in March 2019.
Given the likely severity of the problem, Microsoft should yank version 2004 now, and hope that more people don’t lose their data. It isn’t enough to hide behind an upgrade block.
Microsoft shouldn’t have shipped Win10 version 2004. Delaying the ship date is the first item in my list of Five steps Microsoft should take RIGHT NOW to help us through the pandemic, published two months ago. There are no feature upgrades worthy of the term – version 2004 primarily re-arranges the chairs on the deck. In the “tick-tock” new Win10 scheme of version upgrades every six months, this one doesn’t tick. It thuds.
After fives months of testing the final version of Win10 version 2004, we get this.
Have a beef with 2004? Join us on AskWoody.com.