-
Hardwareluxx führt derzeit die Hardware-Umfrage 2026 (mit Gewinnspiel) durch und bittet um eure Stimme. Unter allen Teilnehmern verlosen wir eine aktuelle Grafikkarte Eurer Wahl bis 1099 EUR.
Native NVMe Treiber für Win 11 nun erhältlich
- Ersteller ssj3rd
- Erstellt am
Erklärbär
Experte
- Mitglied seit
- 28.01.2025
- Beiträge
- 2.088
Das einzige was mich bei den neuen Treiber noch interessieren würde, ob der auch noch aktiv wäre, wenn man nun einen Storagepool erstellen würde und den vorher einspielt oder ob der komplett statt in Teilen von den MassStorage Treiber abgelöst wird. Müsste ich dafür nicht 6TB Daten"umschaufeln", hätte ich das schon lang getestet. ..aber so.. 
Holt
Legende
- Mitglied seit
- 05.07.2010
- Beiträge
- 33.132
Bei Heimanwendern sind schon mehr als 4 parallele Zugriffe im Alltag extrem selten, von daher ist es irrelevant wie es sich bei so vielen IOPS verhält, wie sie bei Servern, z.B. Datenbank Servern, vielleicht Alltag sind, aber nicht bei Heimanwendern und ich kann immer nur lachen, wenn ich lese wie manch sich freuen wenn ihre neue SSDs nun 1,5 Millionen statt 1 Millionen maximale IOPS hat, wenn sie selten viel mehr als 100.000 ausnutzen werden.
Nein, selbst CDM ist im NVMe Profile schon total over the top was die IOPS angeht, wenn man es auf die Nutzung eines Heimanwenders bezieht. Wie bei mehr als einer Millionen IOPS dann die 99 perzentiles sind und welche maximale Antwortzeit dabei auftreten kann, ich für Heimanwender egal und Consumer SSDs werden darauf auch nicht optimiert, Enterprise SSDs sollten dagegen schon darauf optimiert sein, sind dafür aber oft bei der Latenz bei nur einem Zugriffe oft schlechter und daher bei der Nutzung wie bei Heimanwendern oft langsamer. Beides gleichzeitig zu optimieren ist eben schwer, dies konnten meines Wissens nach nur die Intel Optane, weil diese eben kein NAND sondern 3D XPoint als Speichermedium verwenden, welches eine deutlich geringere Latenz hat und wahlfrei gelesen und beschrieben werden kann.
Nein, ich habe doch einen verlinkt und diesen Link gerade eben und auch direkt vor dem Posten getestet und er hat beide male funktioniert. Hier noch mal der Link alleine: https://download.orbmu2k.de/files/DriveControllerInfo.zip
Das bei einer schnellen NVMe SSD für private PCs die IOPS nicht limitieren, da stimme ich dir zu. Warum aber soll man sich nicht darüber freuen, dass der Windows Treiber IO-Commands nun nativ über NVMe verarbeiten kann, anstatt (weiterhin) über eine Übersetzungsschicht in ISCSI Commands zu gehen? Diese Überheblichkeit macht dich Unsymphatisch. Jedem einzelnen Hwlxxer mit einer PCIe 5.0 SSD ist klar, dass die Performance bei Gaming und normalen Apps keine Rolle spielt. Es ist halt ein Hobby.
Holt
Legende
- Mitglied seit
- 05.07.2010
- Beiträge
- 33.132
Wo habe ich das geschrieben? Oder auch nur etwas, was in die Richtung deuten würde? Im Gegenteil, Erklärbär hat geschrieben:
Dies wäre also ein Nachteil des neuen nativen NVMe Modus, aber ich habe darauf hingewiesen, dass dies für Heimanwender irrelevant ist.
Unsympathisch macht dich diese Trollverhalten, denn es ist typisch für Trolle Leute zu unterstellen etwas behauptet zu haben, was sie gar nicht behauptet haben um sich dann darüber aufzuregen.
Erklärbär
Experte
- Mitglied seit
- 28.01.2025
- Beiträge
- 2.088
Bin es doch mal angegangen, weil hat mir keine Ruhe gelassen - waren auch nur 3TB schieben, keine fünf.
Ergebnis:
Kurz & simpel erklärt lassen sich (hier die beiden FN955) treiberseitig auf nvme.sys umstellen, egal ob schon im Pool eingebunden oder nicht - das spielt keine Rolle.
Der Msft Speicherpool Treiber lässt sich nicht dazu überreden disk.sys durch nvme.sys via Treiber aktualisieren zu ersetzen. Es wird zwar eine Treiberaktualisierung angezeigt und das diese erst nach Neustart gültig ist, dem ist aber nicht so. Alle Treiber bleiben bei der gleichen Dateiversion wie vor Neustart:
ps: Auch hier sieht man in der Datenträgerverwaltung, dass Storage im Pool ist der einzige Datenträger welcher nicht diesen kuriosen 1MB (bei 2TB) bzw. 2MB (bei 4TB) unpartitionierten Bereich angehangen bekommt, da hier nicht der nvme.sys sondern (vermutlich übergeordnet) disk.sys Treiber aktiv ist. Man bekommt diesen Bereich auch zum Erbrechen nicht weg, da selbst zum anhängen/erweitern an bestehender Partition gesperrt und auslöschen kann dazu führen, dass die komplette SSD ratzfatz leer geputzt wird. Da sollte man verdammt vorsichtig sein! Ich weiß auch nicht, wofür dieser Bereich automatisch bei nvme.sys angehangen wird bzw. was der Sinn dahinter sein soll oder ob das schlicht ein Bug ist.
Zuletzt bearbeitet:
Fernando 1
Neuling
- Mitglied seit
- 11.03.2026
- Beiträge
- 1
Nur zur Info: Einen MS-Treiber namens nvme.sys gibt es nicht!
Vermutlich meinst Du den neuen MS-Treiber, der NVMe SSDs nativ unterstützt. Der heißt aber nvmedisk.sys.
Hast recht, aber die korrekte Bezeichnung sieht man ja auf den Bildern von @Erklärbär deutlich, also kein Grund zur Aufregung. Sowas passiert im Eifer des Gefechts....
Ich hole den Thread mal aus den Tiefen, weil ich nun mit dem NVMe Treiber schwerwiegende Probleme hatte. Der Windows Boot hat extrem lange gedauert und meine Startup Skripts sind nicht mehr richtig gelaufen. Im Task Manager habe ich dann gesehen, dass die SSD permanent auf 100% Auslastung war, obwohl die Datenrate nur wenige Megabyte pro Sekunde betragen hat. Gestern hat Steam für ein Update eines Spiels 30 Minuten gebraucht, wegen der lokalen Disk. In CrystalDiskMark war alles in Ordnung und die Werte waren gut, aber ich konnte kaum mehr meinen Desktop verwenden.
Ich habe die Registry Hacks für den native NVMe Treiber wieder entfernt und die Probleme waren sofort weg. Ich kann nicht genau sagen, was die Probleme im Detail sind, würde aber aktuell davon abraten, den Treiber zu verwenden. In den ersten Monaten war alles in Ordnung, aber nach einem halben Jahr war die SSD Performance de facto defekt.
Kein Vorwurf an irgendwen, ich habe bewusst die inoffiziellen Hacks gesetzt und bin selbst für die Änderung verantwortlich. Dies ist nur als Feedback für weitere mutige, die das neue Feature ausprobiert haben.
Ich habe die Registry Hacks für den native NVMe Treiber wieder entfernt und die Probleme waren sofort weg. Ich kann nicht genau sagen, was die Probleme im Detail sind, würde aber aktuell davon abraten, den Treiber zu verwenden. In den ersten Monaten war alles in Ordnung, aber nach einem halben Jahr war die SSD Performance de facto defekt.
Kein Vorwurf an irgendwen, ich habe bewusst die inoffiziellen Hacks gesetzt und bin selbst für die Änderung verantwortlich. Dies ist nur als Feedback für weitere mutige, die das neue Feature ausprobiert haben.
Erklärbär
Experte
- Mitglied seit
- 28.01.2025
- Beiträge
- 2.088
Wundert mich, dass der bei dir überhaupt die ganze Zeit bugfree lief und erst in letzter Zeit anfing zu "mucken".
ps: Hattest du in der letzten Zeit, also ab aufspielen des nativen Treibers, ein paar Funktionsupdates via WU aufspielen lassen? Denn ich meine, mal iwo gelesenen zu haben, dass MS das nicht so gerne gesehen hat, dass dieser native Treiber im I-Netz so seine Runden gedreht hat und das unterbinden wollte (weil halt nicht offziell für diese Editionen frei gegeben). Könnte also gut möglich sein, dass dort das Problem zu suchen ist.
ps: Hattest du in der letzten Zeit, also ab aufspielen des nativen Treibers, ein paar Funktionsupdates via WU aufspielen lassen? Denn ich meine, mal iwo gelesenen zu haben, dass MS das nicht so gerne gesehen hat, dass dieser native Treiber im I-Netz so seine Runden gedreht hat und das unterbinden wollte (weil halt nicht offziell für diese Editionen frei gegeben). Könnte also gut möglich sein, dass dort das Problem zu suchen ist.
Zuletzt bearbeitet:
@Erklärbär
Das Fehlerbild war schwer zu identifizieren, weil ja die Benchmarks gute/normale Werte geliefert haben. Erst als meine Startup PowerShell Skripts nicht mehr funktioniert haben, bin ich ins Debugging und habe festgestellt, dass die NVMe vollausgelastet ist bei 5MB/s. Bis vor rund zwei Wochen liefen meine Skripts fehlerfrei, das Fehlerbild ist also in dieser Form neu. Möglicherweise hat es sich aber mehrstufig verschlechtert, sodass es mir erstmal nicht aufgefallen ist.
Das Fehlerbild war schwer zu identifizieren, weil ja die Benchmarks gute/normale Werte geliefert haben. Erst als meine Startup PowerShell Skripts nicht mehr funktioniert haben, bin ich ins Debugging und habe festgestellt, dass die NVMe vollausgelastet ist bei 5MB/s. Bis vor rund zwei Wochen liefen meine Skripts fehlerfrei, das Fehlerbild ist also in dieser Form neu. Möglicherweise hat es sich aber mehrstufig verschlechtert, sodass es mir erstmal nicht aufgefallen ist.
Erklärbär
Experte
- Mitglied seit
- 28.01.2025
- Beiträge
- 2.088
Ok, offiziell hatte MS den ja seit 03/26 wieder geblockt (via z.b. Featureupdate), inoffziell kannst du den danach halt nur via ViVe weiterhin nutzen.
Das der bugt und für diese Windows Editionen nicht taugt, dass hatte MS ja schon kommuniziert. Darum hat es mich ja gewundert, dass der bei dir nach März noch bugfree lief.
Kann auch sein, dass MS vieleicht mit einen weiteren Update noch einmal "nachgebessert" hat (wegen ViVe). Wer weiß das schon. MS ist da ja nicht besonders kommunikativ.
Aber alleine das von dir geschilderte Problem reiht sich ja dann nur nahtlos an all die anderen Bugs mit diesen Treiber an, die ich hier ja schon damals aufgezeigt habe.
ps: außerdem hatte ja die Benchsession im Dezember via MSDiskspd (für so etwas schlicht geeigneter als dieses CDM) schon glasklar gezeigt, dass der Treiber teils wiedersprüchliche Werte generiert.
Einerseits liefert der bessere Übertragungswerte nur im I/O_random mit Caching (hard-/soft Ebene) andererseits aber gehen die CPU-Lasten (getestet über maximum 20Thread) mit Caching gegen Faktor 0 herunter.
Wiederholt man das nun im I/O_random ohne Caching liefert der Standardtreiber bessere Übertragungswerte aber die CPU Lasten gehen mit den neuen Treiber um Faktor 5 herunter.
Das hatte mich dann schon sehr gewundert und klingt für mich alles andere als "sauber": Nur im cachen läuft der neue Treiber besser, bei gleichzeitig quasi null weniger CPU-Lasten - ohne cachen hält der MS-Standardtreiber weiterhin das Zepter in der Hand aber only die CPU-Lasten gehen via neuen Treiber drastisch herunter. Why? ..da hakts doch wo enorm.
Im Netz findest du so etwas nicht, die meisten kennen eh nur CDM, vieleicht noch AS-SSD dazu, dass wars!
..und haben auch keine Lust, über variablere Befehlszeilen Commands, da mal genauer zu schauen und so Sessions 20~30x in verschiedenen Konstellationen zu testen.
Da sind die Online-Breakingnews schon vorerfasst, Tool wird kurz angeschmissen -> Passt! ..und ab damit ins Netz -> clickbait Hausaufgabe erfüllt.
Das der bugt und für diese Windows Editionen nicht taugt, dass hatte MS ja schon kommuniziert. Darum hat es mich ja gewundert, dass der bei dir nach März noch bugfree lief.
Kann auch sein, dass MS vieleicht mit einen weiteren Update noch einmal "nachgebessert" hat (wegen ViVe). Wer weiß das schon. MS ist da ja nicht besonders kommunikativ.
Aber alleine das von dir geschilderte Problem reiht sich ja dann nur nahtlos an all die anderen Bugs mit diesen Treiber an, die ich hier ja schon damals aufgezeigt habe.
ps: außerdem hatte ja die Benchsession im Dezember via MSDiskspd (für so etwas schlicht geeigneter als dieses CDM) schon glasklar gezeigt, dass der Treiber teils wiedersprüchliche Werte generiert.
Einerseits liefert der bessere Übertragungswerte nur im I/O_random mit Caching (hard-/soft Ebene) andererseits aber gehen die CPU-Lasten (getestet über maximum 20Thread) mit Caching gegen Faktor 0 herunter.
Wiederholt man das nun im I/O_random ohne Caching liefert der Standardtreiber bessere Übertragungswerte aber die CPU Lasten gehen mit den neuen Treiber um Faktor 5 herunter.
Das hatte mich dann schon sehr gewundert und klingt für mich alles andere als "sauber": Nur im cachen läuft der neue Treiber besser, bei gleichzeitig quasi null weniger CPU-Lasten - ohne cachen hält der MS-Standardtreiber weiterhin das Zepter in der Hand aber only die CPU-Lasten gehen via neuen Treiber drastisch herunter. Why? ..da hakts doch wo enorm.
Im Netz findest du so etwas nicht, die meisten kennen eh nur CDM, vieleicht noch AS-SSD dazu, dass wars!
..und haben auch keine Lust, über variablere Befehlszeilen Commands, da mal genauer zu schauen und so Sessions 20~30x in verschiedenen Konstellationen zu testen.
Da sind die Online-Breakingnews schon vorerfasst, Tool wird kurz angeschmissen -> Passt! ..und ab damit ins Netz -> clickbait Hausaufgabe erfüllt.
Zuletzt bearbeitet:
@Erklärbär
bei jedem Boot meines Gaming PCs läuft ein DIY PowerShell Skript, dass Hardwareparameter auf Richtigkeit prüft und im Fehlerfall (z.B. 1Gbit/s anstatt 2.5Gbit/s LAN) ein Info-Fenster bringt. Die Ausführung des Skripts dauert normalerweise ca. 1 Sekunde, ich sehe also mit der Anmeldung ganz kurz das schwarze PowerShell Fenster auf- und zu- gehen. Seit Mitte/Ende Juni ist mir aufgefallen, dass das PowerShell Fenster ohne Aktion stehen bleibt und schwarz bleibt. Die Windows Updates für Juni 2026 wurden am 10.06.2026 installiert, das passt zeitlich also perfekt zu dem Fehlerbild.
Die Werte in CDM waren auch mit dem native NVMe Driver gut, d.h. die SSD funktioniert fehlerfrei. Nachdem ich jetzt die Registry Hacks wieder entfernt habe, ist die Leistung unverändert zu früher, aber die Treiberversion hat sich trotzdem geändert. Jetzt hat der Treiber 10.0.26100.8521 und 12/25 hatte er 10.0.26100.6725. In jedem Fall werde ich den neuen NVMe Treiber erst dann noch einmal versuchen, wenn er offiziell in Windows 11 nutzbar ist ohne inoffizielle Tools oder Hacks.
bei jedem Boot meines Gaming PCs läuft ein DIY PowerShell Skript, dass Hardwareparameter auf Richtigkeit prüft und im Fehlerfall (z.B. 1Gbit/s anstatt 2.5Gbit/s LAN) ein Info-Fenster bringt. Die Ausführung des Skripts dauert normalerweise ca. 1 Sekunde, ich sehe also mit der Anmeldung ganz kurz das schwarze PowerShell Fenster auf- und zu- gehen. Seit Mitte/Ende Juni ist mir aufgefallen, dass das PowerShell Fenster ohne Aktion stehen bleibt und schwarz bleibt. Die Windows Updates für Juni 2026 wurden am 10.06.2026 installiert, das passt zeitlich also perfekt zu dem Fehlerbild.
Die Werte in CDM waren auch mit dem native NVMe Driver gut, d.h. die SSD funktioniert fehlerfrei. Nachdem ich jetzt die Registry Hacks wieder entfernt habe, ist die Leistung unverändert zu früher, aber die Treiberversion hat sich trotzdem geändert. Jetzt hat der Treiber 10.0.26100.8521 und 12/25 hatte er 10.0.26100.6725. In jedem Fall werde ich den neuen NVMe Treiber erst dann noch einmal versuchen, wenn er offiziell in Windows 11 nutzbar ist ohne inoffizielle Tools oder Hacks.
Erklärbär
Experte
- Mitglied seit
- 28.01.2025
- Beiträge
- 2.088
Welche PS Version nutzt du? Bzw. ist installiert?
Ich bin WU seitig uptodate, seit Build .8655 (09.06.) ist es aber so, dass die PS ISE 5.x Version nicht mehr funktionieren möchte.
In der Log zum Build sehe ich da bei MS aber keinerlei Infos dazu. Frage nur wegen:
Ich bin WU seitig uptodate, seit Build .8655 (09.06.) ist es aber so, dass die PS ISE 5.x Version nicht mehr funktionieren möchte.
In der Log zum Build sehe ich da bei MS aber keinerlei Infos dazu. Frage nur wegen:
..würde halt wie die sprichtwörtliche "Faust aufs Auge" zu meinen PS ISE Problem passen.
Ja, absolut korrekt, glaube seit April Update .8328 ist das die aktuelle Treiberversion bis dato (26xxx.8737 vom 23.06.).
Zuletzt bearbeitet:
@Erklärbär
Mein Fehler hat nichts mit PS zu tun. Der SSD "Treiberdefekt" ist mir bei einem Game Update für Witchfire aufgefallen, das plötzlich nur noch mit 5MB/s durchgeführt wurde und dann fast eine Stunde gedauert hat. Dann habe ich neu gestartet und gemerkt, dass die Apps der Taskleiste viel zu langsam öffnen, z.B. Logitech G Hub erst nach rund einer Minute. Einfach nur den PC neu zu starten hat die SSD Auslastung im Task Manager für Minuten nach dem Neustart auf 100% festgesetzt. Der PS Fehler war eine weiteres dieser Sympthome. Ich hatte erst Sorge vor einem Defekt der SSD, der CDM Benchmark hat mir aber gezeigt, dass die SSD einwandfrei funktioniert. Damit war die Fehlerursache in meinen Augen klar.
Nach dem Entfernen der Registry Einträge für den native NVMe Driver haben die PS Startskripts wieder sofort wie gewohnt funktioniert. Die ISE nutze ich fürs Skripte schreiben, die fertigen Skripte lass ich dann über powershell.exe (v5, ohne ISE) über einen scheduled Task im Userkontext automatisch ausführen.
Für die restlichen Mitleser tl;dr: Der native NVMe Treiber hat meinen PC seit den Juni Updates mehr oder weniger unbenutzbar gemacht und ein Entfernen der Registry-Hacks gefolgt von einem Neustart hat den Fehler behoben. Ich rate vom neuen NVMe Treiber aufgrund eigener Erfahrungen daher ab.
Mein Fehler hat nichts mit PS zu tun. Der SSD "Treiberdefekt" ist mir bei einem Game Update für Witchfire aufgefallen, das plötzlich nur noch mit 5MB/s durchgeführt wurde und dann fast eine Stunde gedauert hat. Dann habe ich neu gestartet und gemerkt, dass die Apps der Taskleiste viel zu langsam öffnen, z.B. Logitech G Hub erst nach rund einer Minute. Einfach nur den PC neu zu starten hat die SSD Auslastung im Task Manager für Minuten nach dem Neustart auf 100% festgesetzt. Der PS Fehler war eine weiteres dieser Sympthome. Ich hatte erst Sorge vor einem Defekt der SSD, der CDM Benchmark hat mir aber gezeigt, dass die SSD einwandfrei funktioniert. Damit war die Fehlerursache in meinen Augen klar.
Nach dem Entfernen der Registry Einträge für den native NVMe Driver haben die PS Startskripts wieder sofort wie gewohnt funktioniert. Die ISE nutze ich fürs Skripte schreiben, die fertigen Skripte lass ich dann über powershell.exe (v5, ohne ISE) über einen scheduled Task im Userkontext automatisch ausführen.
Für die restlichen Mitleser tl;dr: Der native NVMe Treiber hat meinen PC seit den Juni Updates mehr oder weniger unbenutzbar gemacht und ein Entfernen der Registry-Hacks gefolgt von einem Neustart hat den Fehler behoben. Ich rate vom neuen NVMe Treiber aufgrund eigener Erfahrungen daher ab.
Ähnliche Themen
