When an upgrade to Windows 11 25H2 stalls with a dialog saying an NVMe SSD is “not compatible” and the update is postponed, it’s not random noise — this is a deliberate compatibility safeguard tied to a recurring Host Memory Buffer (HMB) interaction that first surfaced during the 24H2 rollout and is now showing up again in upgrade telemetry and user reports.
This behavior mirrors the compatibility blocks and blue‑screen reports tied to Windows 11 24H2: Microsoft used targeted “safeguard holds” that prevented feature updates from being offered to systems with NVMe drives running firmware that had known failure fingerprints. Vendor firmware patches for affected models were published and Microsoft withheld the update from impacted devices until telemetry showed the population risk subsided.
SanDisk/Western Digital documented the specific affected SKUs and published firmware release notes that explicitly reference an HMB‑related fix, and their dashboard utilities were updated to offer the firmware to impacted drives. The vendor guidance also explicitly warns that Microsoft may prevent systems with affected models from upgrading until firmware is updated.
Recommended posture for most users:
Conclusion
The NVMe warning on Windows 11 25H2 is a reminder that modern storage is a tightly coupled co‑design of OS, driver, controller and firmware. Microsoft’s safeguard holds and vendor firmware updates are the correct defensive tools for preventing catastrophic outcomes, but they demand discipline: backup, verify model and firmware, suspend BitLocker where appropriate, and update the SSD firmware using official vendor tools. For most users the path forward is straightforward — update the drive firmware and let Windows Update resume the 25H2 offer. For environments with many mixed SKUs, take the time to validate and stage the work; that investment is small compared with the cost of corrupted data or failed upgrades.
Source: BornCity Windows 11 25H2: Is the NVMe problem back? | Born's Tech and Windows World
Background
What users are seeing right now
Several Windows users attempting to move from Windows 11 24H2 to the 25H2 enablement package report a warning dialog that signals one of the system’s NVMe SSDs — most commonly 2TB variants from Western Digital and SanDisk — is considered incompatible, and that the upgrade is being postponed until the hardware is addressed. In many cases the immediate fix is a vendor firmware update applied through the vendor dashboard tools.This behavior mirrors the compatibility blocks and blue‑screen reports tied to Windows 11 24H2: Microsoft used targeted “safeguard holds” that prevented feature updates from being offered to systems with NVMe drives running firmware that had known failure fingerprints. Vendor firmware patches for affected models were published and Microsoft withheld the update from impacted devices until telemetry showed the population risk subsided.
A short history of the 24H2 NVMe incident
In late 2024 and into 2025, community labs and user reports found a reproducible pattern: sustained, large sequential writes (often in the tens of gigabytes) to some DRAM‑less NVMe SSDs could cause the drive to hang, disappear from the OS topology, or trigger kernel crashes (BSODs). Independent testing repeatedly pointed to drives that rely on the NVMe Host Memory Buffer (HMB) feature — a design used by DRAM‑less controllers to borrow a portion of system RAM for mapping tables and caching. Microsoft and vendors investigated, vendors published firmware updates aimed at HMB behavior, and Microsoft applied safeguard holds to block the rollout to matching devices.SanDisk/Western Digital documented the specific affected SKUs and published firmware release notes that explicitly reference an HMB‑related fix, and their dashboard utilities were updated to offer the firmware to impacted drives. The vendor guidance also explicitly warns that Microsoft may prevent systems with affected models from upgrading until firmware is updated.
Overview: Is the NVMe problem “back” in 25H2?
Short answer
Not exactly new, but visible again: current reports indicate the 25H2 enablement package is encountering the same class of compatibility signals — HMB‑related firmware interactions on certain NVMe models that previously required vendor firmware fixes. Microsoft’s rollout logic will withhold the enablement package from devices that match known risk signatures; the install UI may show a dialog warning that a specific NVMe SSD is not compatible and delaying the upgrade. That’s a continuation of an existing safeguard mechanism rather than a completely new category of failure.How Microsoft’s safeguard system works (brief)
Microsoft gathers telemetry and vendor advisories and can place targeted compatibility holds on feature update offers to prevent known problematic hardware-driver combinations from seeing the update. When a vendor releases validated firmware that mitigates the issue, Microsoft monitors telemetry until the failure rate drops and then lifts the hold for affected signatures. This is what happened during the 24H2 incident and what’s being observed now with selective 25H2 upgrade blocks.Technical analysis: HMB, DRAM‑less SSDs, and why this keeps resurfacing
What is Host Memory Buffer (HMB) and why it matters
The NVMe Host Memory Buffer (HMB) enables DRAM‑less SSDs to allocate a small region of the host’s system RAM for caching and mapping structures. HMB reduces cost and improves performance for drives that don’t include onboard DRAM, but it creates a dependency on the OS and driver behavior for allocating, sizing, and releasing host memory. Small differences in how the host requests or manages the HMB can expose controller firmware timing bugs or race conditions that manifest as hangs, data corruption, or crashes.Why Windows updates can trigger the problem
When a servicing update changes kernel timing, drivers, or how the storage stack allocates host memory (for example changing minimum HMB size or allocation semantics), controllers with fragile or narrow assumptions can enter a failure state. The symptom profile observed by community testers — drives disappearing mid‑write, unreadable SMART data, truncated files after sustained large writes — matches a controller freeze or state corruption exposed by altered host behavior. Those changes can be subtle and only reproducible under specific workloads (e.g., >50 GB continuous writes while the drive is partially full) and firmware revisions. citeturn0news25Not all drives, and not all firmware: the role of SKUs and controller variants
A key complication is that model number alone is not a perfect predictor: identical model labels may ship with different controller firmware, NAND batches, or assembly variants — each of which can impact behavior. Community lists of “affected models” are useful triage leads, but vendor-validated SKU/firmware guidance is the authoritative checklist. Phison, a major controller vendor implicated in some community tests, performed extensive validation testing and reported no systemic failures in its labs — an important nuance that tempers broad claims about universal bricking. The end result is a messy, real‑world interplay of host code, controller firmware, and specific drive configuration.Who and which models were flagged previously — and now
Commonly cited impacted drives (observed during 24H2 and repeated in 25H2 advisories)
Vendor advisories and community collations repeatedly called out the following 2TB SKUs as implicated in the earlier 24H2 problems and as matching the compatibility signatures that 25H2 is now checking for:- WD_BLACK SN770 NVMe SSD — 2TB variants
- WD_BLACK SN770M NVMe SSD — 2TB variants
- WD Blue SN580 NVMe SSD — 2TB variants
- WD Blue SN5000 NVMe SSD — 2TB variants
- SanDisk Extreme M.2 NVMe SSD — 2TB variants
Caveat: lists are investigative — check firmware strings
Because firmware revision, controller vendor and platform UEFI can materially change behavior, the correct action is to check the exact firmware ID for your serial/part number using the vendor tool, and to follow the vendor guidance for that SKU. Community lists are a starting point not a definitive registry of broken drives.Vendor responses and remediation options
Firmware updates are the primary fix
Both Western Digital and SanDisk published firmware updates targeted at HMB edge cases. The vendor support articles and dashboards instruct users to update firmware using the vendor’s dashboard utility (Western Digital Dashboard / SanDisk Dashboard) and to reboot/power‑cycle where the firmware update requires a shutdown to apply. Vendor documentation explicitly warns that Microsoft may block the feature update until firmware is updated.Tools and practical friction points
- SanDisk Dashboard (the unified WD/SanDisk tool) is the recommended utility to view firmware versions and apply updates; the dashboard shows “Firmware Update Available” when a newer build exists. Documentation walks through the update flow and emphasizes a backup before flashing.
- Community reports show the dashboard can be glitchy on some systems (invisible GUI, drives showing as “Other Devices”), and some users needed offline install flows or manual .fluf flashing. That means vendor dashboards work, but expect occasional support friction.
BitLocker and firmware updates
Microsoft guidance and OEM advisories recommend suspending BitLocker before applying firmware updates that touch boot, TPM, or platform firmware — and many vendors suggest suspending BitLocker as a precaution for drive firmware flashes too. Suspending BitLocker avoids the chance the platform will prompt for a recovery key on restart after firmware changes. Use Suspend‑BitLocker (PowerShell) or the BitLocker control panel to suspend protection temporarily, then Resume‑BitLocker after the firmware operation completes. This is a practical step users reported needing to perform before they could successfully update SSD firmware.Practical, step‑by‑step safe upgrade checklist
Follow these steps if you see a 25H2 warning about an NVMe SSD or if your machine contains an NVMe SSD from the previously flagged SKUs.- Back up first.
- Copy all critical files to an external drive or cloud service. Firmware updates and upgrades carry non‑zero risk of data loss. This is non‑negotiable.
- Identify the NVMe model and firmware.
- Open Device Manager → Disk drives and note the NVMe model string. Use the vendor dashboard to read the firmware version or check SMART/controller info. Vendor tools will often flag a recommended firmware update.
- Suspend BitLocker (if applicable).
- If you use BitLocker, temporarily suspend protection: run Suspend‑BitLocker -MountPoint "C:" -RebootCount 0 from an elevated PowerShell prompt (or use the Control Panel BitLocker UI). Resume protection after the firmware update. This avoids a recovery prompt that can block access.
- Update SSD firmware using the vendor tool.
- Install and run the SanDisk/Western Digital Dashboard. Apply the firmware update per the dashboard instructions; many updates require a shutdown to finish flashing and a power‑on to take effect. If the dashboard fails, consult the vendor support article for manual firmware installation steps.
- Reboot and verify.
- After the firmware update, reboot and use the dashboard or Device Manager to verify the listed firmware version. Check drive health and SMART attributes. Give the system time (up to 48 hours in some reported cases) for Microsoft’s compatibility hold to clear and for Windows Update to offer 25H2.
- If upgrade still withheld, do not force it.
- Avoid bypassing Microsoft’s safeguards by forcing the enablement package with third‑party tools or Media Creation Tool unless you fully accept the risk. Forcing an upgrade defeats the safeguard that exists to reduce the chance of a catastrophic failure mid‑upgrade.
- If you experience drive disappearance or corruption, stop writing to the drive and collect diagnostics.
- Power down fully, reboot, and check the vendor utility. Contact vendor support with the Windows build, KB numbers, SSD model, and firmware version. If data is critical, consult professional recovery channels before repeated writes.
Strengths and wins — what worked well this time
- Microsoft’s safeguard system prevented many users from receiving a feature update that had a known failure profile on certain hardware, reducing the blast radius of the regression. That mechanism — targeted blocks rather than blanket rollbacks — is the right tradeoff for large ecosystems.
- Vendors published firmware updates and support articles that specifically reference the HMB issue and provide concrete flashing steps. The presence of vendor remediation enables users to fix their hardware and proceed safely when validated firmware is applied.
- Community testing highlighted realistic reproduction steps, which helped focus vendor forensic work and produced usable mitigation guidance (for example, temporarily avoiding very large sustained writes). These public test cases accelerated diagnosis.
Weaknesses, ongoing risks, and unresolved questions
- Tooling fragility: vendor dashboard utilities work in most cases but are not flawless. Some users reported UI problems or detection issues that complicated firmware application. That friction matters when users need to apply a potentially risk‑mitigating firmware update.
- Partial visibility on root cause: while HMB allocation semantic changes are the leading theory, a single, fully vendor‑verified forensic root‑cause that ties a precise Windows change to a specific firmware defect for all affected SKUs has not been publicly released. That leaves room for ambiguous finger‑pointing, inconsistent fix rollouts across SKUs, and ongoing uncertainty for mixed fleets. Treat some broad claims with caution until vendors or Microsoft publish conclusive forensic artifacts.
- Risk to data: when a storage device disappears mid‑write, the consequences can be severe (truncated files, filesystem metadata corruption, or drives requiring vendor reflashes/RMA). Users who skip backups or force upgrades risk permanent data loss. The practical risk remains real for specific workloads.
- Communication and inventory complexity: because identical model numbers can ship with different firmware or controller variants, large enterprises and enthusiasts with heterogeneous inventories face complicated validation tasks. Firmware rollout fragility — different part numbers, BOMs and firmware branches — complicate a “one‑click” remediation story.
What IT pros and enthusiasts should do now
- Prioritize backups and postpone non‑critical broad deployments of 25H2 in environments where affected NVMe drives may exist. Use test rings and pilot deployments to validate real workloads (including large sustained writes).
- Build a short validation checklist for inventory: (a) detect NVMe models and firmware, (b) check vendor support pages for firmware advisories, (c) schedule firmware rolls to removable maintenance windows, (d) suspend BitLocker when firmware changes might affect boot or platform state.
- If you operate imaging and deployment pipelines that create images for multiple models, validate dashboard tools in a lab image and confirm that scripted firmware flashing approaches are supported by vendor tooling without triggering BitLocker recovery.
Final assessment and recommended posture
The NVMe warning dialog users see during the Windows 11 25H2 enablement attempt is a defensive, targeted compatibility hold reflecting the same class of HMB/firmware interactions that produced problems during 24H2. It’s not an unexplained new failure mode so much as Microsoft and OEMs doing the conservative work expected in a complex ecosystem: blocking risky upgrades until vendor fixes are applied and telemetry stabilizes. That conservative posture reduces the probability of widespread data loss but raises a practical cost for users who must apply firmware, sometimes after suspending BitLocker and wrestling with vendor dashboard quirks.Recommended posture for most users:
- Back up critical data now.
- If the upgrade offer is blocked and you have an affected WD/SanDisk 2TB NVMe, follow the vendor firmware update instructions using the SanDisk/WD Dashboard and suspend BitLocker during the process.
- Do not force the 25H2 enablement package if Microsoft’s safeguards have withheld it; waiting until the vendor firmware is applied or the hold is lifted is the safer route.
Conclusion
The NVMe warning on Windows 11 25H2 is a reminder that modern storage is a tightly coupled co‑design of OS, driver, controller and firmware. Microsoft’s safeguard holds and vendor firmware updates are the correct defensive tools for preventing catastrophic outcomes, but they demand discipline: backup, verify model and firmware, suspend BitLocker where appropriate, and update the SSD firmware using official vendor tools. For most users the path forward is straightforward — update the drive firmware and let Windows Update resume the 25H2 offer. For environments with many mixed SKUs, take the time to validate and stage the work; that investment is small compared with the cost of corrupted data or failed upgrades.
Source: BornCity Windows 11 25H2: Is the NVMe problem back? | Born's Tech and Windows World
