Microsoft sez:

Sept 12:

>This happens mainly on systems with certain SSD controllers under heavy write loads.

Sept 25:

>The first suspect is the Motherboard's M.2 Slot.

Don't make me laugh.

These messages are from Microsoft "External Staff". I wouldn't blame them, they appear to be quite consistent.

I wonder who came up with the underlying CYA component.

Has the slot had any significant changes compared to the OS since it was first issued?

This looks like the same excuse as a week or more ago. I've noticed some changes in performance earlier than that. Could be a moving target when disk I/O should be one of the most unchanged things of all time.

I think until further data comes in, it should be treated as if it only works on certain proven systems under particular workloads. Maybe not even that. That's what I'm doing. No ZFS or anything fancy, just regular ordinary FAT32 and NTFS.

Corrupt data or not. That is the question.

Isn't logic still a thing?

Somebody's going to have to make sure if it works as good as it was before, every time there is any possible change, the tip of the iceberg looks so innocuous.

This is data loss that never would have been tolerated by Bill Gates if he was there. Nothing close.

Isn't Gates still a shareholder? How would you feel if you were the deficient engineer, if Gates got a wild hair over garbage business performance, and came knocking on your door about now? Just to say hi. I would expect more drama than if it was Nadella at this late date.

Meanwhile there are still good people getting kicked out, and some of the sharp ones remaining are tasked with things like superfluous ads, badly misguided when what's been always needed is an unbroken chain of increased commitment to core reliability, so nobody can ever point the finger at real business-critical failures.

HDDs are also behaving less ideal than a year ago and that seems especially true of pre-"AdvancedFormat" HDDs which only have 512 bytes per sector and are supposed to remain the complete foundation of all disk I/O. Or you're doing it wrong, Microsoft, Apple, or Linux. There's just so very much of that baked in, you'd be a fool to try and cut it out.

Most likely dropping the ball just so there can be a series of short-cuts that don't affect all AF drives or something. But who would know the difference in "advance" without testing comparable to what Gates would have mandated. Like every single piece of hardware on the market ever, there's a legend of never settling for less, especially when it was a mission-critical business situation that people remember as completely solved decades ago.

With the resources that Microsoft has, people have always been drawn to it because they can utilize their vast resources to accomplish things that no one else could do. Why stop now? Why not continue?

AF HDDs and everything else having 4096 bytes per sector can often have "moving target" ill-tested updates. They're not fully mature yet, it's hardly been any time at all. Every OS needs to be a reference implementation more so than ever, even more so if all drives don't naturally have adequate consistency.

Somebody probably forgot that the purpose of any SSD, flash, or drive emulation is to act as closely to a real "generic" spinning 512 b/sec HDD before you go any further. Hardware, firmware, and software. You can't expect just anybody to be capable of this, probably almost nobody really. After the bar has been met with old code and proven under stress like forever, don't even think about making any changes unless you have the commitment to raise the bar by putting in even more effort now than when the company was younger.

There is probably a key engineer without enough decades of experience to keep from screwing this up, who made breaking changes and can't tell the difference because it was not tested against all the proprietary hard-coded ways different drive vendors have carefully crafted their wares to accommodate what Microsoft was throwing at them as it matured all that time. In secret of course because drives have always been so competitive, so documentation never would help and you had to do the testing.

Turns out extensive testing is needed now more than ever, and the false sense that meticulous adherence to documentation alone will even be adequate, could be part of the problem.

Maybe it is just in some of the SSD firmware out there, and it turns out not to be a Windows defect.

But why are HDDs that are perfectly good since Windows 7, and still just fine there, behaving any differently these days when there have been no firmware changes in between? For the longest time. You'd be a durn fool if you couldn't admit that a 2010 WD HDD is an ideal "reference instrument" compared to any SSD ever made. So more than ever, any applicable modified code needs to also be tested against old non-WD Seagates, Hitachis, even genuine Maxtors. All are reference instruments compared to modern AF HDDs and if it can't do that any more there's no way to trust it with SSDs. If the data is important. I'm testing using unimportant data, and have only had losses on SSD and flash so far, but some HDDS are acting different than they ever did. On some decent size laptop HDDs which have been in plush external USB enclosures for portable storage, they are now consistently unrecognizable on some PC's where that was not the case a year ago. Still good on most anything, but a few PCs have dropped out of contention like that. You can plug them in to a good motherboard SATA port and access everything just fine so it hasn't been a show-stopper but definitely noticeable.

Weren't lots of the same drives working just fine without complaints until suddenly one day? Who's in the best position to figure out exactly where the defect(s) lies?

And are they willing to step up to the plate? There's been some pretty impressive hitters already but somebody needs to knock it out of the park before trust can be justified once more.

Nobody knows how much hardware has firmware blobs that nobody understands any more, maybe even with lingering reliance on CHS structures which can only define the first 8GB, then transitioning to "modern" LBA seamlessly. Maybe up until now. There are so many other possibilities though, and the only way to reveal them all is to obviously do more thorough testing than anybody involved up to now could ever imagine.

Many students have been taught that CHS doesn't matter at all for decades, but this has never been well-confirmed. Because it was fairly false when it was declared fait accompli and that gave people an excuse to halt all effort (including more gradual correction) and never recover the technical debt.

There have also been dramatic deviations between Intel and AMD in this regard, more so than others at different times. Plus quite a few "interesting" dissimilarities within a single vendor.

There is some indication that in some situations drive "geometry" differences between HDDs and SSDs is on the increase and not being as well kept up with as when there were fewer deviations from the fundamental HDD LBA paradigms. Which were not well-documented at all, hence all the testing that was always needed to compensate when unreliability is not an option.

When I let (rely on?) W11 set up a fully zeroed drive, partitioning then formatting before installing, it's kind of clunky performance-wise and the blank filesystem layout's key sectors are written into far more unprecedented locations than it used to be.

If instead on a zeroed drive you manually partition then format using a thing like Diskpart where you can align the clusters as if it was for RAID, it performs noticeably better, and even more noticeable on a HDD. Not enough for FAT32 though, its raw disk structure is a poor imitation of what you get from DOS. Not even a backup boot sector on FAT32 any more, which was taken away with the arrival of XP in 2001 apparently when they were trying to kill FAT32 permanently.

But FAT32 never went away even if under attempts to compromise reliability in hopes that it might go away sooner. Just happened the clearest heads did prevail by requiring FAT32 on a boot partition when drafting UEFI specs, where it remains to this day. Sitting on everybody's UEFI Windows PC carrying forward since 2001 as an imitation of its former self. With further occasional mystery changes since then. Who knows why, if they're still not going to format FAT32 with a backup boot sector, and leave FAT as a shadow of its former 20th century self.

I've got to be able to install scientific software that's like 15GB and it's no game. Orders of magnitude more costly.

The official support is for W11 24H2 which worked when it was first released but 23H2 still performed better.

But you are expected to connect to the internet so you can get all current updates before installing.

Nope. Proven bad idea at this point.

And that's just the tip of the iceberg.