140
New report blames Phison's pre-release firmware for SSD failures — not Microsoft’s August patch for Windows
(www.tomshardware.com)
this post was submitted on 08 Sep 2025
140 points (95.5% liked)
Technology
74994 readers
2543 users here now
This is a most excellent place for technology news and articles.
Our Rules
- Follow the lemmy.world rules.
- Only tech related news or articles.
- Be excellent to each other!
- Mod approved content bots can post up to 10 articles per day.
- Threads asking for personal tech support may be deleted.
- Politics threads may be removed.
- No memes allowed as posts, OK to post as comments.
- Only approved bots from the list below, this includes using AI responses and summaries. To ask if your bot can be added please contact a mod.
- Check for duplicates before posting, duplicates may be removed
- Accounts 7 days and younger will have their posts automatically removed.
Approved Bots
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
The takeaway: Microsoft forced pre-release firmware onto millions of computers.
They're lucky only a small percentage were damaged tbf.
Edit: on re-readinf I may have parsed this incorrectly
It may be more like "for some reason some drives have pre-release software and the update.. interacts badly with it?"
How you read that article and came to that conclusion is beyond me. No, that's not the takeaway lol. Microsoft didn't force the pre-release firmware onto people SSD's.
We don’t actually know that’s the case though.
What's the other path for this firmware being related to the update?
Maybe I'm missing something
There are a few ways I can think of, such as coming from the factory with en engineering firmware, or a third party (manufacturer) tool pushing the update.
There’s also the question of how M$ would have even got the engineering firmware to begin with. If it did indeed get released through windows update, was it the manufacturer that provided it? M$ can’t really be expected to vet every driver they are provided.
If MS cant be expected to vet every driver they push with their autoupdater they shouldnt push drivers with the same tool that autoupdates their OS. Make one or the other. I see a use for autoupdate only MS products and a triggered updater for drivers that only gets used by the error wizard with a user prompt(whtever they call it) if they want to be able to claim no responsibility
So you’d like to go back to the old days where users install their devices with a third party installer every time they get a new hardware item, require providing drivers during install, and never update those drivers?
Why wouldn’t it be up to the driver provider to vet the drivers being provided?
So the end user is responsible to hunt down the driver publisher? In what way is that better than MS being responsible and they keep the publishers in line before the publishers get access to autoupdater?
About the third party installer, why not use my suggested solution rather than putting words in my mouth? Keep the drivers in a separate MS installer from autoupdates
Error wizard only updates leads us right into issues of insecure drivers being left in place because they aren’t causing errors. Or what if the drivers originally installed were engineering drivers, and an update was to correct them? Never going to hit because it never errored.
The reality is, the current solution works. Is it infallible? No, of course not. But this is like getting mad at FexEx because they didn’t confirm the package Amazon sent you was the actual item you ordered.
Except you didnt order it, FedEx decided you needed the package. More, the package contained termites that got out and infested your house