Koniec eksperymentów z wydajnością? Microsoft blokuje natywne NVMe w Windows 11 24H2 i 25H2

W świecie optymalizacji systemów operacyjnych niewiele tematów budzi tak duże emocje, jak „ukryte” funkcje zwiększające wydajność sprzętu. Przez ostatnie miesiące entuzjaści Windows 11 żyli odkryciem, które obiecywało rewolucję w szybkości działania dysków SSD: natywnym stosem sterowników NVMe. Niestety, najnowsze aktualizacje systemu o oznaczeniach 24H2 oraz nadchodzące 25H2 przynoszą kres tej prostej modyfikacji rejestru.

Dlaczego Microsoft zdecydował się zablokować metodę, która realnie przyspieszała komputery? Czy rzeczywiście chodzi o bezpieczeństwo, czy może o sztuczne różnicowanie wersji systemów? Przyjrzyjmy się technologicznym kulisom tej decyzji.

Czym jest „natywne NVMe” i dlaczego go chcieliśmy?

Aby zrozumieć wagę problemu, musimy cofnąć się do podstaw tego, jak Windows komunikuje się z naszymi dyskami. Tradycyjnie system Windows korzysta z architektury Storport, która opiera się na standardzie SCSI (Small Computer System Interface). Choć standard ten jest sprawdzony i stabilny, powstał w czasach dominacji dysków talerzowych.

Gdy na rynku pojawiły się superszybkie dyski NVMe, Microsoft wprowadził sterownik stornvme.sys. Problem polega na tym, że działa on jako „tłumacz” – każde żądanie systemu musi zostać przetłumaczone z formatu SCSI na format NVMe. Ten proces generuje tzw. narzut procesora (CPU overhead) i dodaje cenne mikrosekundy opóźnienia.

Rozwiązaniem tego problemu jest nowy sterownik – nvmedisk.sys (Native NVMe). Pomija on całkowicie warstwę SCSI, komunikując się bezpośrednio z protokołem NVMe. Korzyści płynące z jego aktywacji były mierzalne i spektakularne:

• wzrost operacji wejścia/wyjścia (IOPS): nawet o 80%.
• Redukcja obciążenia procesora: o około 45% przy intensywnych operacjach na plikach.
• Szybszy zapis losowy: skok wydajności sięgający 85%.

Nic dziwnego, że użytkownicy rzucili się do modyfikacji rejestru, by odblokować te możliwości w swoich domowych systemach.

Mechanizm „triku„: jak oszukiwaliśmy system?

Funkcja natywnej obsługi NVMe została zaprojektowana z myślą o systemie Windows Server 2025. Ponieważ jednak Windows 11 (od wersji 24H2) dzieli to samo jądro z wersją serwerową, kod sterownika nvmedisk.sys znajduje się również w naszych wersjach Home i Pro.

Użytkownicy odkryli, że wystarczy dodać odpowiednie klucze w rejestrze, w sekcji FeatureManagement\Overrides, aby zmusić menedżera funkcji Windows (system Velocity) do aktywacji nowego stosu. Najpopularniejszym identyfikatorem był 1176759950. Po restarcie system zamiast standardowej „stacji dysków” wyświetlał nową kategorię urządzeń, a benchmarki pokazywały rekordowe wyniki.

Co zmieniło się w wersjach 24H2 i 25H2?

Microsoft, monitorując te nieoficjalne zmiany, wprowadził w najnowszych kompilacjach mechanizm blokujący. Nie polega on na usunięciu sterownika, lecz na zmianie logiki jądra systemu.

Obecnie system Windows w wersjach klienckich (Home/Pro) ignoruje specyficzne identyfikatory funkcji w kluczu Overrides. Nawet jeśli wpiszesz poprawne dane do rejestru, menedżer funkcji sprawdza tzw. SKU systemu (edycję licencyjną). Jeśli wykryje, że nie jest to Windows Server, automatycznie odrzuca żądanie aktywacji natywnego NVMe i powraca do bezpiecznego sterownika stornvme.sys.

To przesunięcie punktu decyzyjnego z rejestru bezpośrednio do skompilowanego kodu systemu operacyjnego sprawia, że prosta modyfikacja plików .reg przestała działać.

Dlaczego Microsoft mówi „nie”? Perspektywa stabilności

Choć wielu użytkowników widzi w tym działaniu złą wolę korporacji, przyczyny blokady są głęboko zakorzenione w technicznych problemach, jakie generował ten „trik„.

1. Pętla BitLockera

To był najpoważniejszy problem. Zmiana sterownika na tak niskim poziomie zmieniała sumy kontrolne łańcucha rozruchowego. Dla mechanizmu bezpieczeństwa BitLocker wyglądało to jak atak hakerski. Efekt? Użytkownicy po restarcie lądowali w niekończącej się prośbie o podanie klucza odzyskiwania, co dla osób bez kopii zapasowej oznaczało utratę danych.

2. Paraliż Trybu Awaryjnego

Tradycyjny Tryb Awaryjny (Safe Mode) nie posiada na swojej „białej liście” sterownika nvmedisk.sys. Gdy użytkownik wymusił jego użycie i system uległ awarii z innego powodu, próba naprawy w Trybie Awaryjnym kończyła się błędem INACCESSIBLE_BOOT_DEVICE. Komputer stawał się „cegłą„, której nie dało się naprawić bez zewnętrznego nośnika.

3. Konflikty z oprogramowaniem producentów

Aplikacje takie jak Samsung Magician czy WD Dashboard komunikują się z dyskami za pomocą specyficznych komend SCSI. Przejście na natywne NVMe sprawiało, że te narzędzia przestawały widzieć dyski. Użytkownicy tracili możliwość aktualizacji firmware’u czy monitorowania stanu zdrowia nośnika (S.M.A.R.T.).

Czy istnieją alternatywy?

Dla tych, którzy mimo ryzyk chcą eksperymentować, ścieżka nie jest całkowicie zamknięta, choć stała się znacznie trudniejsza.

• ViVeTool: to narzędzie deweloperskie pozwala na głębszą manipulację bazą danych funkcji (Feature Store). Obecnie identyfikatory takie jak 60786016 oraz 48433719 pozwalają na aktywację natywnego NVMe w niektórych kompilacjach 24H2, ale wymaga to ostrożności.
• Poprawka Safe Mode: aby uniknąć unieruchomienia systemu, konieczne jest ręczne zarejestrowanie nowej klasy urządzeń w rejestrze SafeBoot, co pozwala systemowi załadować natywny sterownik również w trybie ratunkowym.

🛡️ Rekomendacja redakcji:

Jeśli Twój komputer służy Ci do pracy lub przechowujesz na nim ważne pliki bez kopii zapasowej w chmurze – nie wymuszaj natywnego NVMe na obecnym etapie. Zyski w benchmarkach rzędu 80% są kuszące, ale ryzyko błędu krytycznego (INACCESSIBLE_BOOT_DEVICE) przy najbliższej aktualizacji systemu przez Windows Update jest obecnie zbyt wysokie. Poczekaj na oficjalne wdrożenie.

Przyszłość: kiedy dostaniemy to oficjalnie?

Wszystko wskazuje na to, że obecna blokada jest etapem przejściowym. Microsoft przygotowuje się do oficjalnego wdrożenia natywnego NVMe w systemach klienckich, prawdopodobnie w wersji 25H2 lub późniejszej.

Oficjalne wdrożenie rozwiąże problemy z BitLockerem i Trybem Awaryjnym, ponieważ instalator systemu będzie odpowiednio konfigurował wszystkie mechanizmy zabezpieczające. Do tego czasu musimy zadowolić się standardową, choć nieco wolniejszą, ścieżką SCSI, która gwarantuje, że nasze dane są bezpieczne, a system stabilny.

Kluczowe punkty

• Co zablokowano? Możliwość aktywacji wydajniejszego sterownika nvmedisk.sys za pomocą prostych wpisów w rejestrze.
• Dlaczego to zrobiono? Aby zapobiec błędom rozruchu, problemom z BitLockerem oraz brakiem kompatybilności z oprogramowaniem producentów SSD.
• Jaki jest zysk wydajności? Wersja natywna oferuje do 80% więcej IOPS i mniejsze obciążenie CPU, co jest widoczne głównie w profesjonalnych zastosowaniach.
• Co dalej? Funkcja ta najprawdopodobniej wróci jako oficjalna część systemu w 2025 roku, po pełnym dopracowaniu mechanizmów współpracy ze sprzętem konsumenckim.

Masz doświadczenia z testowaniem natywnego NVMe? A może spotkały Cię problemy po aktualizacji do 24H2?