KB5063878 Windows 11 24H2 Storage Regression: NVMe Drives Vanish Under Heavy Writes

Microsoft’s August cumulative for Windows 11 24H2 (KB5063878) has been linked by independent testers and enthusiast communities to a reproducible storage regression in which certain NVMe SSDs can suddenly stop responding during sustained large writes, sometimes vanishing from Device Manager and Disk Management and — in a minority of cases — returning corrupted or unreadable data after a reboot. (support.microsoft.com)

Background / Overview​

The problem reported in mid‑August centers on a specific workload profile: sustained sequential writes on the order of ~50 GB or more, with device utilization climbing above roughly 60%. Under that load some SSDs reportedly lock up at the controller level, making the device invisible to the OS and often rendering SMART/controller telemetry unreadable. Reboots sometimes restore temporary visibility but do not guarantee the integrity of files written during the failure window. (igorslab.de, notebookcheck.net)
This incident echoes an earlier, related episode that began during the Windows 11 24H2 feature rollout (late 2024) when changes in Host Memory Buffer (HMB) allocation behavior exposed firmware weaknesses in certain DRAM‑less SSDs and produced persistent BSOD loops on a subset of Western Digital / SanDisk models. That earlier problem was mitigated by vendor firmware updates, registry workarounds and Microsoft rollout controls — establishing a pattern: subtle host‑side changes to storage behavior can trigger latent controller/firmware faults. (tomshardware.com, laptopmag.com)

---

What users and testers are seeing​

Symptom profile (consistent community fingerprint)​

• Large copy, game update, or backup operation proceeds normally and then abruptly fails or stalls near the ~50 GB mark. (tomshardware.com)
• The target drive disappears from File Explorer, Device Manager and Disk Management; vendor tools stop reading SMART/controller attributes. (notebookcheck.net)
• Reboot sometimes restores drive visibility; in some cases the volume/partition is gone or files written during the incident are corrupted. (igorslab.de)
• The fault appears reproducible in community lab tests under the specific heavy‑write workload, but not universal across every system or SSD of a given model.

Early‑reported trigger and reproducibility​

Multiple independent reproductions place the reliable trigger window at sustained sequential writes of roughly 50 GB or more. That profile is common for game updates (Steam), bulk media transfers, disk clones, and large installer packages — which is why gamers and content creators surfaced many of the early reports. (notebookcheck.net, pcgamesn.com)

---

Which SSDs appear in community lists​

Community collations (user tests and regional tech sites) have produced overlapping but not identical lists of affected and unaffected models — a sign the failure is hardware‑ and firmware‑sensitive rather than a universal Windows fault. The following lists are culled from independent testers and community reports and should be treated as investigative leads rather than definitive recall lists.

• Devices reported as affected in early aggregations (some recover after reboot; some became inaccessible):
• Corsair Force MP600 (Phison family)
• Phison PS5012‑E12 / related Phison family SKUs
• Kioxia Exceria Plus G4 (Phison‑based SKUs)
• Fikwot FN955 and various third‑party Phison‑based boards
• SanDisk Extreme Pro M.2 NVMe (in some reports)
• Other DRAM‑less or HMB‑reliant SKUs reported in Japanese community testing. (guru3d.com, igorslab.de)
• Devices commonly reported as not affected in the sampled lists:
• Samsung 990 PRO / 980 PRO series (no widespread reports)
• Certain Solidigm / Seagate enterprise NVMe models in community lists
• Some WD/Crucial high‑end models — but note: model variations and firmware levels matter. (notebookcheck.net, tomshardware.com)

Important caveat: any per‑model statement is conditional on the drive’s SKU, controller revision and firmware level; not every unit of a named model will necessarily reproduce the fault. Community lists are a starting point for triage, not a formal vendor recall.

---

Technical analysis — how this can happen​

Why heavy sequential writes expose edge cases​

Sustained sequential writes stress multiple layers simultaneously: application buffers, the Windows page cache, kernel I/O scheduling, the NVMe command stream and the SSD controller’s internal metadata management. A subtle host‑side change — timing, buffer sizing, DMA handling or HMB negotiation — can place a controller into an edge condition where firmware mishandles a sequence and effectively locks up. When the controller stops responding to admin commands the OS may treat the device as removed from the PCIe/NVMe topology. The symptom set — unreadable SMART, disappearance from Device Manager, corruption of in‑flight writes — is consistent with such a controller hang. (igorslab.de, support.microsoft.com)

HMB and DRAM‑less controllers​

The Host Memory Buffer (HMB) allows DRAM‑less NVMe SSDs to borrow a slice of host RAM for mapping structures and caches. Changes in how Windows assigns HMB — either size or policy — were the proximate cause for the earlier 24H2 BSOD wave on specific WD/SanDisk models. While current reports don’t uniformly pin HMB as the single root cause for the August 2025 regression, HMB remains a plausible cofactor, especially for DRAM‑less designs that depend on host memory stability and timing. (tomshardware.com, notebookcheck.net)

Could Intel CPU/chipset PCIe be responsible?​

Some users and writers have observed that moving an affected drive to a different platform (for example, an AM5 motherboard/CPU) eliminated the increase in data‑integrity errors and the disconnect events. That anecdotal evidence raises a plausible alternative hypothesis: a host PCIe controller or chipset regression — either in CPU‑integrated PCIe logic or the chipset — that produces an I/O profile the SSD firmware mishandles. Community threads document assorted PCIe lane/compatibility quirks on Z790 and other Intel platforms, and Intel’s Raptor Lake family previously experienced a known “Vmin / voltage‑related” instability class that required mitigations, firmware and microcode patches — demonstrating that CPU/platform anomalies can and do produce subtle I/O impacts. However, this remains conjecture at present: data tying KB5063878 specifically to Intel silicon faults is limited and unconfirmed by vendors. Treat the CPU/chipset theory as plausible but unverified until vendors or Microsoft publish confirmatory telemetry. (theverge.com, tomshardware.com)

---

What vendors and Microsoft have (and haven’t) said​

• Microsoft published KB5063878 on August 12, 2025; the official KB article lists the update and improvements and initially did not list a storage‑device failure as a known issue. The update page is the authoritative release record for the package. (support.microsoft.com)
• Independent enthusiast outlets and storage testers (Igor’s Lab, Guru3D, Tom’s Hardware, NotebookCheck and others) reproduced the event profile and aggregated affected model lists; vendor responses varied by manufacturer and by the earlier HMB episode — in many cases firmware updates and vendor dashboards were already the primary remediation path for the October 2024–era HMB failures. (igorslab.de, guru3d.com, tomshardware.com)
• Formal vendor statements linking KB5063878 to specific controller firmware revisions were limited at the time the community reporting emerged. That absence of a single vendor/Microsoft admission is a normal stage in a complex compatibility incident: community telemetry leads to vendor forensics, which may then produce firmware updates or a Microsoft Known Issue Rollback (KIR) if host‑side changes are at fault.

---

Practical guidance: triage and mitigation​

The situation is workload‑sensitive and time‑sensitive. The following checklist synthesizes community recommendations, vendor practices and Microsoft servicing mechanics.

• Immediate emergency steps (if you suspect an affected drive):
• Stop all heavy writes immediately. If a drive disappears mid‑transfer, further writes risk worsening corruption. (tomshardware.com)
• Back up critical data now to a separate physical device or cloud storage. Don’t rely on the suspect drive for backups.
• If the drive has become inaccessible but the data is critical, do not initialize/format the device. Power it down and, if possible, create a sector‑level forensic image to a safe target before further action. Imaging preserves recoverable data and supports vendor diagnostics.
• Firmware and tools:
• Launch your SSD vendor utility (WD Dashboard, Samsung Magician, Crucial Storage Executive, Corsair Toolbox) and verify firmware. If a vendor‑provided update fixes a known issue, apply it only after backing up. For older WD/SanDisk HMB problems, vendor firmware was the long‑term fix previously recommended. (tomshardware.com)
• If you’ve installed KB5063878 and want to avoid risk:
• Consider staging large writes on a different machine or temporarily withholding the cumulative in managed fleets until vendors confirm compatibility. Administrators should use WSUS/SCCM controls to test on representative hardware.
• Uninstalling a cumulative update is possible but has operational and security trade‑offs; the KB article documents removal mechanics for the combined SSU+LCU package and notes limitations. Balance the risk of data corruption against security exposure before rolling back. (support.microsoft.com)
• Registry and temporary mitigations (short‑term, not ideal):
• During the earlier 24H2 HMB episode some communities used the registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\StorPort\HmbAllocationPolicy to limit or disable HMB allocation as a stopgap. That approach reduces performance and carries the usual registry‑editing risks; it is a temporary mitigation, not a substitute for firmware or official fixes. Only use such workarounds if you understand the trade‑offs and have current backups.
• If a drive appears to be failing repeatedly:
• Capture SMART and Kernel/Event logs prior to replacement; record the exact firmware, motherboard BIOS/UEFI version, Windows build and the KB(s) installed. This telemetry greatly speeds vendor diagnostics and RMA processing.

---

Longer‑term remediation and what to expect​

• Vendor firmware updates remain the most likely definitive fix when controller firmware is the root cause. Historically, the coordination model is: community reproduces → vendor investigates → firmware patch → Microsoft may apply rollout blocks for vulnerable hardware until firmware is applied.
• Microsoft can also deploy Known Issue Rollbacks (KIR) or targeted servicing controls if host‑side NVMe or StorPort behavior is implicated. Expect official communications on the Microsoft Release Health dashboard if Microsoft or major vendors confirm the regression. (support.microsoft.com)
• If the CPU/chipset hypothesis gains traction (platform PCIe controller problems), remedies could include BIOS updates, CPU microcode/firmware patches or RMA for defective silicon in the worst cases. Past Intel Raptor Lake voltage/instability workstreams show that CPU/platform issues have required a mix of microcode, BIOS and replacement strategies when physical degradation or early‑life failures were suspected. That said, vendor confirmation is required before concluding the platform is the primary culprit. (theverge.com)

---

Critical appraisal — strengths, risks and what remains unverified​

Notable strengths of the current response​

• The community’s quick reproduction and sharing of workload‑profile data (e.g., the ~50 GB trigger) gives engineers a precise test case for forensic work. That reproducibility is a powerful accelerant for vendor mitigation. (igorslab.de)
• Vendors (Western Digital, SanDisk and others) have historically released firmware updates in response to the 24H2/HMB incidents; that track record suggests firmware remediation is possible and effective. (tomshardware.com)

Real risks and user impact​

• The primary risk is data loss. Drives that disappear mid‑write and return corrupted metadata after reboot can produce unrecoverable loss for users who did not maintain independent backups. (tomshardware.com)
• Administrators face a tough trade‑off: delaying a security patch (to avoid storage risk) increases exposure to vulnerabilities; applying the patch risks a small but severe storage regression on certain hardware combinations. This is a classic update‑management dilemma. (support.microsoft.com)

Claims that should be treated cautiously​

• The notion that Intel 13th/14th gen CPUs or Z790 chipsets are the primary cause for all observed drive failures is not yet established. Anecdotal moves to AM5 systems that halted error accumulation are suggestive but not conclusive. Confirming a CPU/chipset root cause requires vendor telemetry from the SSD controller makers, motherboard vendors and Microsoft. Until those parties publish a coordinated forensic finding, the CPU/chipset hypothesis remains plausible but unverified. (theverge.com)
• Model‑level lists are helpful but not decisive; firmware revision, SKU and motherboard/BIOS interplay materially change whether a given drive will reproduce the fault. Treat community model lists as investigation leads, not definitive blacklists. (notebookcheck.net)

---

For Windows power users and IT administrators — recommended steps (concise)​

• Back up all critical data from systems that received KB5063878 immediately.
• Avoid running sustained large sequential writes (>~50 GB) on suspect systems until firmware/vendor guidance is confirmed. (guru3d.com)
• Check vendor utilities for firmware updates and apply them after backing up. (tomshardware.com)
• For fleets: stage KB5063878 in a test ring that includes representative storage hardware and test large‑write workloads before broad deployment.
• If a drive becomes inaccessible after the symptom, image it before reformatting and capture logs for vendor support/RMA.

---

Conclusion​

The August 2025 cumulative update for Windows 11 24H2 (KB5063878) has surfaced as a serious compatibility risk for a small but consequential set of storage configurations: sustained heavy writes can trigger controller‑level failures that make NVMe devices disappear and, in some cases, cause file corruption or permanent inaccessibility. Community testing has provided a clear repro profile and model leads, and vendor/Microsoft remediation paths (firmware updates, rollout controls, registry stopgaps) are the established tools for resolution. (support.microsoft.com, igorslab.de)
At the same time, the deeper question of whether host platform (CPU/chipset/PCIe controller) faults contribute materially to the phenomenon remains unresolved and must be treated as a testable hypothesis rather than settled fact. Users and admins should prioritize backups, avoid heavy sequential writes on suspicious systems, keep firmware and BIOS up to date, and await coordinated advisories from SSD vendors and Microsoft before rolling the patch broadly in production environments.
The broader lesson is unchanged: modern storage depends on a fragile choreography between OS stacks, drivers and SSD firmware. When that choreography slips, the consequences are immediate and often irreversible for affected users — which makes conservative update management, robust backups and rapid vendor‑grade diagnostics more important than ever.

---

Source: Hardware Times NVMe SSD Randomly Disconnecting: Win 11 24H2 Update, Intel CPU/Chipset Responsible? | Hardware Times

 

[ChatGPT]

Microsoft’s August cumulative for Windows 11 — identified as KB5063878 (OS Build 26100.4946) — has been linked by independent testers and community reporting to a reproducible storage regression: under sustained, large sequential writes some NVMe SSDs can stop responding, vanish from the operating system, and in a subset of cases return corrupted or unreadable data. tly after Microsoft pushed KB5063878 on August 12, 2025 as the monthly cumulative security and quality rollup for Windows 11 24H2, multiple community test reports and specialist outlets began documenting a consistent failure mode: when copying or writing roughly 50 GB or more in a single sustained operation, certain NVMe SSDs would become unresponsive and disappear from Device Manager and Disk Management. Reboots sometimes restored visibility, but not always data integrity.
Two related but diollel after the update release. The first affected enterprise deployment channels (WSUS/SCCM), producing installation errors that Microsoft mitigated with targeted servicing controls. The second — the storage regression — was discovered via community testing and coverage in enthusiast and specialist outlets. Microsoft’s official KB did not initially list a storage-device failure as a known issue, which helped the reports spread through forums and social posts before an authoritative reconciliation could be published.

What users are reporting​

The failure has a clear, repeats posts and test threads:

• Sudden disappearance of an NVMe SSD from File Explorer, Device Manager, and Disk Management while a large file transfer is in progress.
• Vendor diagnostic utilities and SMART telemetry becoming unreadable or returning errors while the devIn many cases a reboot temporarily restores drive visibility; in others the device remains inaccessible until vendor intervel remediation.
• A common reproduction profile centers on sustained sequential writes in the tens of gigabytes range — community tests repeatedly cite roughly 50 threshold.

These symptoms differ from ordinary OS crashes. They point to a storage-controller or firmware-level lockup where the host sees the NVMe device as effectively removed f rather than a simple driver fault that triggers a blue-screen event.

---

Which SSDs are implicated (and how reliable are the lists)?​

Community collations and early technical write-ups repeatedly highlight clusters of affected devices, not a single ubiquiatterns emerge:

• Drives using certain Phison controller families and many DRAM‑less NVMe designs are disproportionately represented in repro posts.
• Past interactions with Windows 11 24H2 that affected DRAM‑less designs (via Host Memory Buffer behavior) provide precedent for controller‑sensitive regressions, which increases plausibility for a controller/f- Forum threads and aggregated reports list brand examples and individual user incidents, but model lists vary by thread and tester. Some outlets and threads name drives such as Western Digital SN770 and SN580 in prior related inci for the KB5063878 failures include assorted Phison-equipped consumer NVMe models across brands — but there is no authoritative, exhaustive public list validated by Microsoft or all major SSD vendors at the time of these reports.

Important caveat: community-sourced model lists are investigative leads, not definitive recall lists. They are useful for risk triage but should be treated cautiously until vendor telemetry or a Microsoft known‑issue entry confirms specific hardware IDsn anatomy: why heavy writes expose controller-edge behavior
Modern NVMe SSD operation is the result of close cooperation between host software, OS drivers, and SSD controller firmware. Under ordinary desktop workloads this cooperation is mostly invisible. But sustained, large seqe different internal pathways in SSD controllers:

• Cache and mapping pressure — large writes push internal mapping tables and garbage‑collection threads into prolonged activity windows, stressing metadata updates.
• Thermal and power states — extended writes elevate temperature and sustained power draw; firmware recovery code paths behave differently under those conditions.
• Host interactions — mechanisms like NVMe’s Host Memory Buffer (HMB) create tighter coupling with the OS; changes in allocation policy or commaatent firmware race conditions. Previous 24H2-era incidents that implicated HMB provide a direct precedent.

When one of these subsystems encounters an unhandled edge caommand timing, unexpected buffer sizes, or prolonged mapping churn — an SSD controller firmware can freeze, crash, or otherwise stop responding. To the host, the device simply vanishes. Diagnostics that read SMART registers or controller telemetry may show unreadable or inconsisteroller is non‑responsive.

---

How robust is the evidence?​

There are three tiers to evaluate:

• Reproducible community tests showing near‑identical trigger profiles (sustained ~50 GB writes) on multiple systems and controllers. These are technically credible and repeated across independent testers.
• Specialist outlet coverage that aggregates test logs, Event Viewer traces, and vendor utility outp plausible controller/firmware lockup mechanism exposed by host behavior.
• Authoritative vendor or Microsoft telemetry confirming root cause and enumerating affected hardware/firmware. As of the initial wave of reporting, such consolidated official confirmation was not widely sally list this storage symptom as a known issue, and vendor statements were limited or incremental. That absence leaves room for uncertainty about prevalence and permanent data-loss rates.

Conclusiattern is technically consistent and reproducible in community labs, but the scale and precise root cause attribution require vendor and Microsoft telemetry to move from high‑confidence hypothesis to proven fault lineage. Treat the reports as an urgent early‑warning rather than a global hardware recall list.

---

Vendor and Microsoft response — what to expect and what has happened so far​

Historically, when OS updates expose fires come through coordinated paths:

• Microsoft can publish a Known Issue entry for the KB with mitigations or a temporary block for specific hardware IDs. If necessary, Microsoft can issue a Known Issue Rollback (KIR) for managed environments. Microsoft used servicing controls to address an unrelated WSUS/SCCM installation regression tied tdemonstrating the mechanism is available.
• SSD vendors commonly issue firmware updates that adjust command handling, timeouts, or internal recovery sequences to tolerate altered host behavior. These fixes are effective when the root cause is a firmware edge case.
• In some incidents, coordinated host-driver patches are required — i.e., Microsoft may release a follow-up update that adjusts Host Memory Buffer allocation, command timing, or NVMe driver behavior.

At the moment of early reporting, vendor advisories and firmware packages were emerglated 24H2 incidents, but a consolidated, cross-vendor fix specifically tied to KB5063878’s storage regression had not been universally published. Administrators and users were advised to monitor vendor support portals and Mic for updates.

---

Practical risk assessment​

• Severity: High for affected systems. A vanished NVMe device mid-write can produce partial or complete data corruption for the files being written, andred partitions or the entire drive inaccessible until vendor intervention.
• Likelihood: Low-to-moderate across the entire Windows install base. The observable footprint so far is clustered: specific controller families and firmware states are over-represented. That means most systems will not see this, but the impact when it hits is substantial.
• Who’s at rirs, content creators, and IT processes that perform sustained large sequential writes (game installs, bulk backups, cloning, archive extraction) on NVMe devices — particularly DRAM‑less or older controller variants.

Given the asymmetric harm (low probability but high impact), a conserranted until vendors or Microsoft publish firm guidance.

---

Immediate checklist: actions for consumers and administrators​

Follow this prioritized checklist now:

• Back up critical data to a separate physical device or cloud storage immediately. If you rely on an NVMege, make an image backup before performing large transfers.
• If you have already installed KB5063878 and use NVMe SSDs for critical data, avoid large sustained writes (bulk game updates, disk cloning, mass file moves) until you confirm your driveimplicated.
• Check your SSD vendor’s support and firmware pages for advisories and firmware updates. Apply vendor-recommended firmware only after creating a full backup or image.
• For admins: stage KB5063878 in representative test fleets that include the same storage hardware and workload patterns (sustained write tests), and withhold the update for impacted endpoints using management tooling until a fix is validated.
• If a drive bter a heavy write: power down the system and contact the SSD vendor. Imaging the drive prior to additional writes increases the chance of forensic recovery and helps vendors diagnose the failure.

Numbered recovery steps if anrite:

• Stop using the system to avoid further writes that could overwrite salvageable metadata.
• Power off and disconnect the drive if the system configuration alloerve the drive for vendor diagnostics.
• If possible and you have the skills, create a block-level image of the device with read-only tools to preserve evidence before attempting repairs. This is a specialist step and may require professional f4. Contact the SSD vendor support with logs, event viewer dumps, and the steps that reproduced the issue. Vendors often require specific traces to produce a firmware fix.

---

Mitigations observed in the wild and their trade-offs​

igations have included temporary behavioral workarounds such as avoiding HMB-sensitive workloads or delaying the update. Some technical users have expe edits or driver tweaks that limit HMB allocation or change storahci parameters; however, registry-level hacks are emergency-only measown risk profile. They should be avoided for general consumers and replaced by vendor-recommended firmware or Microsoft-supplied mitigations.
Administrators can use update management controls (WSUS, SCCM, Intune) to defer thedpoints, allowing time for targeted validation and staged deployment. This is the standard enterprise risk-mitigation pattern when a package introduces environment-specific r Critical analysis: cause, responsibility, and testing gap
Why this matters as a systems-design story: modern SSDs increasingly depend on host cooperation to achieve competitive performance and power efficiency. Features like HMB, aggressive firmware caching, and smaller DRAM footprints make manufacturer firmware assumptions essential to interoperability.

• Strength: The community’s rapid test-and-report cycle and reproducible triggers are a clear strength; hobbyist and specialist testers provided early, actionable reproducibility that helped focus- Weakness: The rollout and initial KB communication lacked a rapid, explicit guidance entry for the storage symptom, leading to inconsistent messaging and anxiety. The absence of immediate cross-vendor telemetry meant much of the early reporting was necessarily fragmented.
• Responsibili SSD vendors (firmware), Microsoft (driver/host behavior), or both. The most durable outcome requires cooperation: vendors shipping tolerant firmware while Microsoft stabilizes any altered host timing or buffer allocation that triggered the edge conditions.

The testing gap highlighted here is systemic: staged rollout practices and test matrices must include heavy-write stress tests on a broader range of real-world consumer SSD configurations, including DRAM‑less and older controller families. The market’s diversity of SSD controllers and firmware versions creates a combinator that OS vendors and hardware partners must manage more transparently.

---

How long before a definitive fix?​

Timeline depends on root-cause classification:

• If the root cause is purely firmware-level (controller bug), vendors can issue firmware updates within days-to-wefailures and validating fixes.
• If the problem requires host-side mitigation, Microsoft may need to publish a targeted update or an updated driver package; release cycles and staged rollouts make this a days-to-weeks cadence depending on severity and verification.
• When both host and firired, coordinated releases increase complexity and can delay a global remediation until both sides validate interoperability.

Given past precedent — where similar HMB/24H2 incidents produced vendor firmware updates and Microsoft-side mitigations within a few weeks — a coordinated fix is plausible within that general window, but time-to-fix is contingent on vendor reproduction and test scope. Until then, cautious operations and backups are the dependable defense.

---

Final verdict and recommended posture​

The KB5063878 storage reports represent a serious, actionable early-warning: the issue is technically plausible, reproducible in community labs, and concentratedre families that are known to be sensitive to host behavior changes. The evidence is compelling enough to change operational behavior for at‑risk users and fleets.
Recommended posture (summary):

• Prioritize backups and image critical dng any large sustained writes.
• Delay non‑urgent large data transfers and staging of KB5063878 on endpoints that run these workloads until vendor guidance is available.
• For administrators: stage the update on representative hardware and withhold it via management tooling where workloads include bulk sequential writes.

Finally, treat community lists of affected models as investigative inputs, not certainties. They are invaluable for early triage, but only consolidated vendor telemetry and Microsoft’s rwill provide a complete, authoritative mapping of affected hardware and firmware revisions. Until that mapping exists, a conservative, backup-first approach minimizes the risk of data loss while manufacturers and Microsoft close the diagnostic loop.

---

The storage ecosystem’s complexity — the interdependence of OS, driver, and SSD firmware — is the root lesson here. That complexity demands better pre-release stress testing for diverse hardware mixes and clearer, faster communication when early failure patterns acautious users and careful administrators will reduce exposure by backing up, avoiding sustained writes on recently patched systems, and follos as they arrive.

---

Source: NoypiGeeks Windows 11 update reportedly linked to SSD failures