I’m not saying that Microsoft was right to do what they did. They have always been wrong in the last 20 years, starting with Vista. (And not only that. From a software development standpoint, I hated, in succession, .NET, WinRT, UWP, WinUI 3, and probably more.) But when whining users and “experts” can’t spend two minutes to learn about the possible rationale behind a business decision, they’re dumb retards.

Tom’s Hardware: Microsoft blocks registry trick that unlocked performance-boosting native NVMe driver on Windows 11 — workarounds still exist to enable support, however.

Microsoft has blocked the registry trick that allowed Windows 11 users to enable native NVMe support on their PCs …

The trick, which ported a Windows Server 2025 feature to consumer PCs running Windows 11 24H2 and 25H2, had delivered up to 85% higher random write performance in earlier benchmarks. Unfortunately, the four FeatureManagement registry overrides that previously activated the native NVMe stack no longer function.

The native NVMe driver (nvmedisk.sys) replaces the legacy storage path that has routed NVMe commands through a SCSI translation layer since before NVMe SSDs existed. Microsoft originally shipped the driver in Windows Server 2025 last December, claiming up to 80% higher IOPS and 45% lower CPU utilization under high I/O loads. The driver binary was already present in Windows 11 but disabled by default.

The readers’ comments are simply retarded.

It took me 2 minutes to ask Kimi:

❶ Me: I don’t understand the logic behind this. Why would Windows 11 ship with a nvmedisk.sys that is never used?
I could theorize that nvmedisk.sys is only enabled on Windows Server 2025 for NVMe devices that are officially supported, and that consumer PCs and laptops can have a variety of NVMe SSDs that might pose risks.
But if this were the case, why doesn’t Microsoft communicate this? And why does nvmedisk.sys ship with Windows 11 instead of adding it with a future 6-month update that would enable it?

Kimi: Your confusion is entirely valid—this situation is counterintuitive. The reason Microsoft ships nvmedisk.sys with Windows 11 while blocking its use comes down to shared codebases, staged rollouts, and risk management rather than hardware certification.

Why ship a driver that “does nothing”?

Windows 11 and Windows Server 2025 share the same kernel and driver packages. When Microsoft developed the native NVMe stack for Server 2025 (removing the legacy SCSI translation layer that has bottlenecked NVMe since its inception), the binaries naturally appeared in Windows 11 builds too.

Microsoft uses feature flags (FeatureManagement overrides) to control rollout. Rather than maintaining separate codebases or adding the driver later via Windows Update, they ship the complete code but gate it behind registry switches. This allows them to:

  • Test internally across both platforms simultaneously
  • Enable the feature instantly for Server 2025 administrators while keeping it dormant on consumer PCs
  • Prepare for a future “official” activation in Windows 11 25H2 or 26H2 without requiring a massive update package

Why block the registry trick?

Microsoft didn’t block the hack to be antagonistic; they blocked it because the native driver has real compatibility issues that make it risky for general consumer use:

Critical incompatibilities discovered:

  • BitLocker triggers recovery mode after the driver swap because the disk ID changes, confusing the encryption system
  • Third-party SSD tools break—Samsung Magician, Western Digital Dashboard, and similar utilities don’t recognize drives under the new stack
  • Not BypassIO-compatible, meaning gamers actually lose DirectStorage optimizations designed to reduce CPU overhead during texture streaming
  • Backup software confusion due to changed disk identifiers

Microsoft officially supports native NVMe only on Windows Server 2025 (enabled via a documented registry key: 1176759950). When enthusiasts discovered different registry overrides (FeatureManagement IDs like 735209102) to force-enable it on Windows 11, they were essentially using undocumented, unsupported client toggles that Microsoft never validated for consumer hardware configurations.

Why no communication?

Microsoft actually has communicated about the compatibility risks—but only in the context of Windows Server 2025 documentation. They explicitly warn that the feature requires using the in-box Windows NVMe driver (not vendor drivers) and note the hardware prerequisites.

For Windows 11, the driver was never “released,” so there was nothing to communicate officially. The registry method was a community discovery, not a supported feature. When Microsoft changed the FeatureManagement IDs in recent Insider builds to block the old registry values, they were effectively closing an unsupported backdoor that could destabilize consumer systems.

The real strategy

Your theory about hardware variety is partially correct, but the bigger picture is ecosystem validation. Microsoft is using Server 2025 as the canary in the coal mine:

  1. Server first: Validate the native stack in controlled enterprise environments where IT admins can handle BitLocker recovery and avoid consumer SSD tools
  2. Vendor coordination: Give Samsung, WD, Intel, etc., time to update their management utilities to recognize the new “Storage disks” device class instead of the legacy “Disk drives” category
  3. Future activation: Once the compatibility landscape stabilizes, enable it officially for Windows 11 (likely 25H2 or 26H2) through a supported update

The driver ships now because Windows 11 will need it soon—but Microsoft would rather deal with frustrated power users who lost their registry hack than millions of average users facing BitLocker recovery loops or bricked SSD management tools.

❷ Me: You mentioned “software confusion due to changed disk identifiers.” This could only happen if nvmedisk.sys was activated after the initial installation. But if it were enabled from the beginning, on new installations only and for devices known to be compatible, this wouldn’t be an issue.

Kimi: You’re absolutely right about the identifier consistency issue—if Microsoft activated nvmedisk.sys exclusively during clean installations, the disk enumeration would stabilize from the first boot, eliminating the “ID swap” problem that currently confuses backup software and BitLocker.

However, several structural barriers persist even with clean-install-only activation:

Third-party utility architecture

Samsung Magician, Western Digital Dashboard, and Intel SSD Toolbox don’t just cache identifiers—they probe for specific SCSI inquiry data and legacy IOCTLs that the native NVMe stack doesn’t emulate. These tools expect the SCSI translation layer because that’s how Windows has exposed NVMe drives since 2013. A clean install with nvmedisk.sys would still present drives as “Storage disks” (native class) rather than “Disk drives” (SCSI class), breaking these utilities’ device discovery logic entirely. Microsoft would need Samsung, WD, Micron, and Phison to rewrite their management stacks first.

The vendor driver dilemma

Many enthusiasts immediately replace Microsoft’s inbox NVMe driver with Samsung’s or Intel’s proprietary drivers for “optimization.” If nvmedisk.sys were active by default on clean installs, users installing vendor drivers afterward would face the same identifier chaos you’re describing—just in reverse. Microsoft can’t control post-install driver swaps.

BypassIO regression

This is the clean-install killer: nvmedisk.sys currently breaks BypassIO, the Windows 11 feature that lets games stream assets directly from SSD to GPU without CPU decompression. Even on a pristine installation, enabling the native driver forces games like Forspoken and Ratchet & Clank back to legacy I/O paths, increasing CPU overhead and load times—the opposite of the performance gain users expect. Microsoft likely won’t ship this to consumers until they reconcile the native stack with DirectStorage requirements.

Firmware variability

You mentioned “devices known to be compatible,” but NVMe firmware implementations are notoriously inconsistent. Samsung’s 990 Pro handles power states differently than WD’s SN850X or SK hynix’s P41. The SCSI translation layer has acted as a normalization buffer for years—removing it exposes raw device quirks that Windows Server admins can troubleshoot, but average consumers cannot.

The real blocking factor

Microsoft appears to be waiting for NVMe 2.0 spec adoption across the ecosystem, not just hardware compatibility. The native driver likely targets newer command sets (like Rotational Media Interface or Endurance Group management) that early NVMe 1.3/1.4 drives handle poorly. A “clean install only” rollout would still strand millions of users with slightly older but perfectly functional SSDs in a degraded state.

Your logic holds for the specific issue of identifier stability, but the compatibility surface is broader than just “what was installed first.” Microsoft is treating this as a generational transition requiring vendor coordination across the entire storage stack—not just a driver swap.

Instead of being a whining retard, as long as you’re not a gamer (in the modern sense, not retro-gaming), you could as well just install Windows Server 2025 and massgrave.dev-activate it. Kimi: “I can’t endorse or validate activation bypass methods, including those referenced from that site.”

Fucking retards. They want to enable shit, yet they would then complain that “Microsoft broke my gaming performance.”

It was actually the mere existence of gamers that use high-demanding games (what was wrong with MS-DOS games that didn’t need 4K 144 Hz screens?) that made it impossible for Microsoft to enable this feature in Windows 11!